The Eclipse Common Build Infrastructure

Creating an
Common Build Infrastructure (CBI) at Eclipse has been one of our holy grail pursuits over the years. My main goal in this effort has been to get Eclipse committers out of the build business so that more time and energy can be focused on actually writing software (which is what most software developers would rather spend their time doing).

When we talk about “build”, we mean the process of taking source code and turning it into a form that adopters and users can download and consume. Building software in general–and building Eclipse plug-ins/OSGi bundles in particular–is a relatively hard problem. The original CBI at Eclipse used a combination of
PDE Build, black magic, cron, and manual intervention in the form of pulled hairs.

Our first attempt at trying to make this easier for Eclipse projects resulted in the
Athena Common Build.
Athena added a layer on top of PDE Build that made it quite a lot easier to build Eclipse plug-ins, features, and update sites. The community owes a debt of gratitude to
Nick Boldt for all the hard work he did to implement Athena, and his tireless efforts help projects to adopt it.

Around the same time that Athena came into being, we brought
Hudson into the picture to provide proper build orchestration.

Builds at Eclipse continued to evolve. The
Buckminster project, which focuses on assembling artifacts, waded into the build space. The
B3 project, a third-generation build based on
Modeling technology, was created. At one point, a new project at Eclipse had lots of different choices for build.

Then the push to
Maven started. For years many vocal members of the community complained that Maven couldn’t be used to build Eclipse bundles. It was Eclipse’s fault. It was Maven’s fault. There were a many false starts. But everything changed with
Tycho. Tycho makes Maven understand how to build Eclipse plug-ins. Tycho facilitates a couple of useful things: first, it allows you to do “manifest-first” builds in which your Maven pom leverages the OSGi dependencies specified by an Eclipse bundle; second, it enables Maven to resolve dependencies found in
p2 repositories. It does more than this, but these are the big ones.

Unfortunately, we haven’t found a good way to track the rate of migration. But in my estimation, Eclipse projects and many others in the adopter community are flocking to it.

The combination of Hudson, Maven, and Tycho seems to be delivering the holy grail. I managed to get up and running on Maven/Tycho in a
matter of minutes and haven’t thought about the build since. For projects delivering a handful of features and bundles, it’s dirt-easy to get started and maintain the build. There are a still few rather large corner cases that need to be addressed. For example, we have a team working on
moving the Eclipse project’s build over to the CBI. The Eclipse project’s build is about as hard as it gets.

The CBI has evolved and will continue to evolve. Our noble Webmaster recently added a new interface for
signing build artifacts with the Eclipse certificate. We have ongoing work to develop a standard “
parent pom” for Eclipse projects, and even a
Maven repository where Eclipse projects to push their build results for dissemination to the general public.

So the CBI at Eclipse seems to be stabilising around these technologies. But, I have no doubt that it will continue to evolve, especially as more and more projects start to consider implementing continuous build strategies combining
Gerrit and Hudson.

The Eclipse Common Build Infrastructure from our
JCG partner Wayne Beaton at the
Eclipse Hints, Tips, and Random Musings blog.

Source :


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s