Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Orbit Bundle Layout"
| (3 intermediate revisions by the same user not shown) | |||
| Line 24: | Line 24: | ||
/orbit/downloads/drops/R200706192011/ | /orbit/downloads/drops/R200706192011/ | ||
/orbit/downloads/drops/R200706131308/ | /orbit/downloads/drops/R200706131308/ | ||
| + | ... | ||
</pre> | </pre> | ||
| + | |||
| + | As a result, the URLs in the produced map file have the build id embedded in them. e.g. | ||
| + | <pre> | ||
| + | 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 | ||
| + | </pre> | ||
| + | |||
| + | * What is an Orbit build? | ||
| + | * Do people actually download the zip file of all the Orbit bundles? | ||
| + | * Maybe this is just a packaging problem? | ||
===Garbage Collection=== | ===Garbage Collection=== | ||
| + | Once an Orbit build is promoted to be "Recommended" then we can remove old builds from the site. With the builds/bundles organized by folder by build id, removing the old build is a simple process. | ||
| − | [[Category:Orbit]] | + | [[Category:Orbit|Bundle Layout]] |
Revision as of 10:27, 23 July 2007
Contents
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
- What is an Orbit build?
- Do people actually download the zip file of all the Orbit bundles?
- Maybe this is just a packaging problem?
Garbage Collection
Once an Orbit build is promoted to be "Recommended" then we can remove old builds from the site. With the builds/bundles organized by folder by build id, removing the old build is a simple process.