Difference between revisions of "Orbit Bundle Layout"
|Line 24:||Line 24:|
Revision as of 13:38, 28 June 2007
The problem is that every time there is a new Orbit build, consumers must update their build (map files, scripts, etc) to consume the new bundles. Since Orbit bundles are generally supposed to be stable some of this work is unnecessary since the bundles aren't supposed to change. In practice, the bundles in Orbit don't change and even have the same qualifier (we use the CVS tag) after they become stable.
Producing Map Files
One of the outputs of the Orbit build (along with the bundles), is a map file that consumers are able to use. This map file contains entries in the form of HTTP GET requests that allow consumers to directly get the pre-built Orbit bundles and include them in their build.
There are 2 ways to consume bundles from Orbit.
Include Orbit Map File
The whole produced Orbit map file can be included as part of the build process. In this case, when a new Orbit build is produced, the release engineering team of the consuming product replace the old Orbit map file with the new one.
Update Own Map File
Some products like to have their own map files which means when there is a new Orbit build, the team must update each individual entry for the bundles which they consume from Orbit. For instance, the Eclipse Platform team has an
orbit.map file in the releng project and this file contains all the URLs for the Orbit bundles.
Currently on disc the contents of each build are located in a different folder with the name of the build id. e.g.
/orbit/downloads/drops/R200706192011/ /orbit/downloads/drops/R200706131308/ ...
As a result, the URLs in the produced map file have the build id embedded in them. e.g.