SVN-Rules
To ease the life of all people contributing to the Palladio Component Model, we try to stick to certain rules, project structures, integration into automated builds, and test cases. The rules apply to our common SVN code base https://[login]@svnserver.informatik.kit.edu/i43/svn/code.
General
- The svn code repository hosts Palladio as well as other projects.
- A short information about the top level projects can be found in the root of the repository as README.txt.
- More detailed information about the repository structure and dependencies can be found at: SVN Code Repository
- It is critical to respect the repository structure as well as the rules of creating branches and tags.
- For any questions or lack of clarity, please contact the SVN responsible group member sdqinternal:Rollen der Mitarbeiter
Checkin-Process
- There are a set of build processes for the Palladio Core, as well as for the other top level and PCM addon and incubation projects.
- Further information about the build structure is documented at SVN Code Repository.
- Every SVN commit in a code area assigned to a build triggers an automatic build process.(On demand, a manual execution is possible at Web-GUI)
- A build run takes about ~15 minutes.
- Available tests are executed as part of the build
- Every committer is responsible to check that the build succeeded after a commit: Buildprocess AND test cases
- Possible Build Results:
- Build failed: An email is automatically send to the palladio-dev mailing list. Please check those emails if there is a note about one of your own commits. In such a case,feel sad, and either fix it or roll back your changes.
- Build succeeded: A build result with a current timestamp can be found at http://sdqweb.ipd.kit.edu/eclipse/PCM_nightly/
External Libraries
There must be no external libraries (JARs) in regular plugin projects. Instead, those external libraries should be wrapped as individual exlipse plugins and a dependency to this wrapper plugins should be created. This is aligned to the standard eclipse development style.
- Remove all included external libraries from your Eclipse-Plugin-Project
- External libraries are encapsulated in "Wrapper Plugins" and centrally stored at [/ThirdPartyWrapper/trunk/].
- For every external library, a new sub directory is created containing the wrapper Eclipse-Plugin.
- Naming Convention for the Plugin-Directory: Fullqualified name of the library suffixed by an underscore and the version number of the library used (e.g., org.jfree.jfreechart_1.0.9) Note: Eclipse Plugins use the underscore character. Jar files use the minus character.
- The license files for the wrapped library must be provided in the root of every plugin project.
- In the file /ThirdPartyWrapper/trunk/Licenses.txt there must be an entry for the wrapper plugins and the license used (GPL, LGPL, etc.).
ORBIT Plugins: The eclipse.org includes a project named Orbit aiming to provide such wrapper plugins for external libraries. Obviously, this project does not provide wrappers for all existing library, but those available should be prefered over creating our own wrappter. The wrapper plugins provided by Orbit can be downloaded from the Orbit update sites into your development enviroment as well as into the build. How to add a new Orbit library download to the build is documented on the according wiki sites.
Test Cases
- Test cases must be provided as individual plugins to be taken into account by the automatic build process.
- How to develop Test projects, integrate them into the build and best practices can be found in this article: Plugin Test Projects