This page is the starting point for information on Orbit builds.
Orbit builds are a bit different from others, in that nothing is really "built" in the traditional since of determining dependencies and compiling. The builds are more of a "copy and assemble" operation. One reason the builds are still very important, though, is that the resulting jars are "conditioned" for packing. These means that as others use the bundles, they are assured of getting the exact same bits, whether those bits come from a downloaded bundle, some assembled zip file, or some update site.
Orbit Builds for Consumers
The place to get bundles that are considered "released" is from http://download.eclipse.org/tools/orbit/downloads/
But, the preliminary versions are available from http://download.eclipse.org/tools/orbit/committers/
Once committers are happy with the bundles produced, they will be moved to the downloads area.
Orbit Builds for Orbit Committers
Principles and Concepts
In orbit, our goal is to produce bundles for consumption, and consumers can mix-and-match what ever they need in their own features. But, we'd still like to use the PDE build process, as much as possible, so some build-features are still needed just to drive the build process. These should have pretty neutral names, such as "set1", to emphasize there is no particular conceptual organization. There are several reasons we can not use just one big feature set:
- There can be bundles with identical symbolic names, but different versions (such as org.junit, versions 3.8.1 and 188.8.131.52). These can not be built in "one pass" of PDE builder. So, ideally, the first version of a bundle would go in "set 1", and subsequent versions would go in "set 2".
- Sometimes, PDE "thinks" there are dependencies between bundles. Well, there are dependencies, but they do not really matter at build time, since we are not really compiling anything. This may eventually be improved, see bug 169991 but in the meantime, we do need to group bundles that depend on one another.
- Lastly, we want separate build-features, since at some point, some of them would be ready to release, but not necessarily all. So, we can "release" build-feature by build-feature and still leave all the "old" features in place, in case they ever need to be re-done.
There's probably several ways to do these steps, but I think of it just other Eclipse project builds I've seen, where projects are "released" to a build, via the platform's releng team's releng tool. In many of the following steps, if you are doing something for the first time, you can usually use what already exists as examples, and in most cases, this will suffice. Long term, we may detail (or point to) more of the details, if people need it.
- Once your bundle is ready to put into a build, make sure you have that version (that is, branch) loaded in your workspace, as you want it released ... this means, usually, all the most recent code in that branch.
- If not done already, be sure your bundle is included as one of the bundles ("plugins") in the feature.
- Be sure the unpack attribute is set as you desire. Also, set the the download/install sizes ... a rough estimate is fine, say rounded up to within 10% of actually size. In the feature, leave the version as a "0.0.0" and it will later be computed from the data in the bundle itself.
- Be sure the map 'branch' is loaded in your workspace that matches the name of the feature, set1, set2, etc.
- If not already done, be sure there is an entry in the map file that has your bundle info. Initially, you can use a "fake" cvs version number (or, just use "HEAD") as it will be corrected in the next step.
- Use Team, Release to release the bundle to the build. This tags the project with a CVS tag, updates the map file, and commits the map file to that map files branch.
- By convention, use CVS tags of the form vYYYYMMDDHHMM, where the date and time is in UTC time.
- The feature that has your bundle must also be released, similar to the above step. This only has to be done whenever the feature actually changes, which is likely to be just once, when you first add the bundle to the feature.
- Once released, the build system should notice this, and starts a new build. It will upload the results to the committers area.
Orbit Builds for Orbit Builds-masters
The build system uses CruiseControl to drive the build-loop.
There status is displayed via the web, and for those with the right "build-master" password, there is an agent that can control the builds. If either of these links are dead, it means the CruiseControl server is not running and needs to be restarted.
This system was created by using the WTP build as a starting point, and then simplifying and changing as needed. So, in some cases, there is likely old stuff left over from the WTP process that is not really needed in Orbit. Feel free to clean up as you find them.
All the build control scripts and templates are in CVS:
- 'org.eclipse.orbit.releng.builder': this project contains the heart of the build process.
- The 'components' directory codifies 'what' is built. As new build-feature sets are added, a new component (directory) needs to be added to build that feature.
- The 'distribution' directory codifies 'how' something is built, uploaded, prepared for the download site, etc.
- The 'scripts' directory holds various scripts used during the process.
- The 'build.xml' file in the root of the project is the main entry point, and is called from the releng.control project.
- 'org.eclipse.orbit.releng.control': this project holds the code that controls the build-loop, downloads fresh builders, etc.
- 'org.eclipse.orbit.releng.dropsite': this project holds the code that makes up the download site build pages.