Orbit Bundle Layout

The Problem

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.

Consumption

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.

Bundle Layout

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.

plugin@com.ibm.icu,3.4.5=GET,http://download.eclipse.org/tools/orbit/committers/drops/I200706271834/bundles/com.ibm.icu_3.4.5.jar