The Eclipse Common Build Infrastructure (CBI) is an initiative combining technologies and practices for building Eclipse Software.
- 1 What is CBI
- 2 Initiative Goals
- 3 Who is using it?
- 4 Preferred Build Technologies
- 5 Deliverables
- 6 Related Topics and Links
- 7 Resources
- 8 Meetings
What is CBI
The core of CBI today is Maven with the Tycho plugins. The Tycho plugins teach Maven how to build (and consume) Eclipse plugins and OSGi bundles. This enables building Eclipse projects with "maven clean install" just as one would build other Maven projects.
Common services such as the Jar signing facility, MacOS signing facility, and Windows signing facility are also included with CBI. Other tools and services may be included in the future as the need arises.
Over time mature templates and common pom.xml files will be provided that set common values finely honed with experience.
One might go so far as to include Git, Hudson/Jenkins, the build slaves, and Nexus (aka. the artifact repository & server side of Maven) as part of CBI since they are also common and crucial to builds.
Gerrit, Bugzilla, and the Downloads site are closely related. Some might consider them part of CBI as well.
Primary goals are:
- Make it really easy to contribute Eclipse projects
- Make it really easy to copy & modify source
- Make it really easy to build
- Make it really easy to test
- Make it really easy to post a change for review
- Make it really easy to sign software
Secondary goals are:
- Get all Eclipse projects building their software on Eclipse Foundation hardware.
- Enable the Long Term Support Program.
- Make it easy for people to build custom Eclipse distributions.
There is a strong link between CBI and the Long Term Support Program which enables a marketplace of companies providing maintenance and support for Eclipse technologies for durations far beyond typical community support. Please NOTE: CBI features will be available to community.
It is our hope that this project develops an offering that is compelling so that many projects will move to use it.
Who is using it?
There's a list of projects building with CBI available.
Preferred Build Technologies
Maven 3.0 drives the builds. Projects are expected to provide standard Maven 3.0 POM files for their builds. The builds should be built in such a way that they can be run on the local workstation, or on the Eclipse build server. Note that builds can only be signed on the Eclipse build server.
- Parent Maven POM for Eclipse projects;
- Signing Builds using Maven; and
- Maven repository support at Eclipse.
Tycho is focused on a Maven-centric, manifest-first approach to building Eclipse plug-ins, features, update sites, RCP applications and OSGi bundles.
- Tycho project information, including demo projects; and
- Building Woolsey with Maven and Tycho
- Reference Card
- Packaging Types
p2 Repo checks
It's highly recommended that any Eclipse.org project runs frequently, and maybe even systematically, the p2 repo analyzer to make sure it conforms to some requirements of being a nice citizen in the Eclipse.org world.
Additionally to recommendation and infrastructure, the CBI also produces pieces of software that are meant to be commonly used by all Eclipse.org projects.
CBI License bundle
We offer a P2 repository containing the org.eclipse.license bundle which is located at:
This URL is a composite P2 repo containing the license bundle.
If you are using Tycho you can add the p2 repo to the <repositories> section of your pom.xml file. Something similar to this:
<repository> <id>license-feature</id> <url>http://download.eclipse.org/cbi/updates/license/</url> <layout>p2</layout> </repository>
In any particular feature which you need the license you can use the usual feature.xml section:
<?xml version="1.0" encoding="UTF-8"?> <feature id="org.eclipse.help" label="%featureName" version="2.0.0.qualifier" provider-name="%providerName" plugin="org.eclipse.help.base" license-feature="org.eclipse.license" license-feature-version="1.0.0.qualifier"/> ....
p2 repo checks
A set of "tests" which create reports or can be ran as unit tests that check to correctness of p2 repositories. That is partially just "correctness" in general (such as, that jars are signed, etc.) but more so that repositories conform to the requirements of the Eclipse Simultaneous release (such as, that jars have correct "Provider names", licenses, etc.). For more information, see See CBI/p2repoAnalyzers/Repo Reports.
p2 repo aggregator
A tool to combine several p2 repositories. Among other things, it makes sure they all have consistent constraints (that is, can be "installed together") unlike a raw p2 mirror task. For more information see CBI/aggregator/manual.
Related Topics and Links
- See your Frequently Asked Question list
Tutorials, News, and other resources
- Tycho tutorial by Lars Vogel
- Video discussing JBoss tools use of Tycho
- Workshops being developed
- Building Eclipse SDK locally with Maven
- Sonar at Eclipse.org !
- Tycho and CBI Adoption: Feedback from the trenches
- Eclipse Scout builds with CBI
See the conference bridge details. Contact andrew dot ross at eclipse dot org if you would like to be added to the Calendar reminder. The dates the upcoming calls are as follows:
- November 15th, 9am EST