Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: for the plan.

Jump to: navigation, search

Common Build Infrastructure/Getting Started

Draft Content
This page is currently under construction. Community members are encouraged to maintain the page, and make sure the information is accurate.

This information is preliminary and subject to change. If you see an error or omission, please feel free to edit it.

Create Configuration Project

The first step is to create a simple project (often called a .releng project) to house your configuration settings.

At its simplest, this is:

  • -- settings for the build
  • maps/ -- where to fetch sources (you can have as many .map files as you need)

You will likely also want to run automated tests as part of your build. For this you'll need:

  • -- properties specific to running tests

Finally, to control how your build is published, you'll need another properties file:

  • -- properties specific to publishing builds

Advanced Usage

Set Up Locally

In Eclipse

To set up to build locally in Eclipse, see Common_Build_Infrastructure/Getting_Started/Build_In_Eclipse.

Commandline / Server

To set up to build commandline outside Eclipse, eg., as a server like, see bootstrapping.

Run A Build

What Can I Do?

  • You can build in Eclipse using Ant.
  • You can build outside Eclipse using Ant (or a shell script).
  • You can [Common Build Infrastructure/Getting Started/Build in Hudson|build in Hudson] with Ant (or a shell script).
  • You can run tests headlessly on linux (using Xvnc or Xvfb) or on Windows/Mac (visually).
  • You can have requirements in your workspace (o.e.releng.basebuilder, o.e.d.common.releng, o.e.myproject.releng), or in /opt/public/cbi/build/, or in /tmp/build/. As long as they're on disk or you specify where to put them, they'll be used or checked out then used. We've also provided a Team Project Set File to more easily fetch basebuilder and common.releng into your workspace.


  • Ant-Contrib is required to run the build. You can put this jar in one of 4 different places, at your discretion:
<taskdef resource="net/sf/antcontrib/antlib.xml">
    <pathelement path="${classpath}" />
    <pathelement location="${relengCommonBuilderDir}/lib/ant-contrib.jar" />
    <pathelement location="${relengBuilderDir}/lib/ant-contrib.jar" />
    <pathelement location="${thirdPartyJarsDir}/ant-contrib.jar" />
    <pathelement location="/usr/share/java/ant-contrib.jar" />
  • The SVN PDE plugin will be automatically downloaded and unpacked into o.e.releng.basebuilder if the thirdPartyDownloadLicenseAcceptance flag is properly set in the project's; this is a bit of a legal hack for making people accept that they need some non-EPL stuff to build from SVN sources. Alternatively, you can download this plugin yourself and add it to basebuilder by hand.
  • While most of the system is Eclipse- and Ant-based, a few small scripts are still shell script based, and thus will only run on a Linux box. The most prominent example of this is the script that runs the tests because it's intended to be platform-specific so that a build could run tests on multiple platforms.

As such, if you run on a Mac or Windows box (with or without Cygwin), your mileage will vary. Builds have been tested and run on Linux using the following Eclipse platform versions: ppc, x86, and x86_64.

If you have test hardware or are willing to contribute translations of shell scripts (to Ant, to Java, or to .cmd/.bat), please don't hesitate to drop us a line.

Build Types


Releases are builds that have been declared major releases by the development team - for example "R1.0". Releases are the right builds for people who want to be on a stable, tested release, and don't need the latest greatest features and improvements. Non-release builds are named according to the date of the build - for example 200904061234 is the build from 6 April 2009 @ 12:34pm; release builds are named for the release (eg., using `-buildAlias 2.0.0`).


Stable builds are integration builds that have been found to be stable enough for most people to use. They are promoted from integration build to stable build by the development team after they have been used for a few days and deemed reasonably stable. The latest stable build is the right build for people who want to stay up to date with what is going on in the latest development stream and don't mind putting up with a few problems in order to get the latest greatest features and bug fixes. The latest stable build is the one the development team likes people to be using, because of the valuable and timely feedback. Stable builds include Milestones and Release Candidates, and are identified using `-buildAlias 2.0.0M7` or `-buildAlias 0.7.0RC2`


Periodically, component teams version off their work in what they believe is a stable, consistent state, and they update the build configuration to indicate that the next integration build should take this version of the component. Integration builds are built from these stable component versions that have been specified by each component team as the best version available. Integration builds may be promoted to stable builds after a few days of testing. Integration builds are built whenever new stable component versions are released into the build. Healthy, agile teams should be producing an I build weekly or bi-weekly.


Maintenance Builds - Periodically builds for maintenance of the current release will be performed. They will not necessarily be stable builds. When the maintenance is finalized and released, it will be moved up to a Release build. If the build name starts with an "M" i.e. M20090405, then it has not been tested for stability. If it is a release candidate, i.e. 0.5.1RC, then it is a stable build, and should be of type S, not M. The final release build in a maintenance cycle should be of type R, and identified using `-buildAlias 0.5.1`


Nightly Builds are produced over night from whatever has been released into the HEAD stream of the SCM repository. They are only unit tested and will sometimes have problems. Some will not work at all. These drops are normally only useful to developers actually working on this project. Not all projects need publish N builds if they produce at least one or two monthly I builds.

Commandline Headless Build

Builds are run from your releng project's build.xml.

To run locally, check out your releng project, then run the build.xml script. Here's a sample project.

  • Via commandline: cd org.eclipse.myproject.releng; ant

In Eclipse With AntRunner

You can create a simple project.releng project, and use that to run a headless build from within your Eclipse workspace. The project consists of properties, build instuctions (beyond the defaults) and one or more map files to define where to get sources if not already cached locally.

For more information, see Common Build Infrastructure/Getting Started/Build In Eclipse.

  • To run the build in Eclipse: Run As > Ant Build

You can also run the same build outside Eclipse:

  • Via commandline: cd org.eclipse.myproject.releng; ant

In Hudson

If you want to build with Hudson on, see Getting Started - Build In Hudson.

Or, start your own local Hudson instance (on your vserver or home machine) and use that. To start Hudson, simply download the latest hudson.war, then run:

java -jar hudson.war &

Then, to get started, copy an existing configuration. Everything in Hudson can be scripted and stored in VCS for reference.

In the above configs, a pre-checked-out cache of basebuilder and common.releng are available in to speed up builds and to reduce CVS checkout churn.

  • As a developer working on the common.releng code, you will need to cvs up in there to ensure your checked in changes are pushed to the build system; however, bear in mind that your changes will be public immediately and anything you broke will be immediately obvious... so play nice (test locally first)!
  • As a user running builds using the common.releng code, you can choose to checkout or export from a given CVS tag for common.releng and basebuilder rather than using symlinks if you prefer to not live on the bleeding edge. When you want to move up to a new stable tag, you can clear your Hudson workspace and start fresh. In this case your startup script will need to be a little different.
  • If using the shared Hudson instance on, use the following path in your myproject.releng/ file:

Build From Local Sources

You can use locally cached sources (eg., in your Eclipse workspace, or in the Hudson workspace) from which to build. Why would you want this? So that you can build in Hudson from HEAD instead of from a mapfile (and tag AFTER the build), or so you can build from locally-edited files and try out a change w/o having to commit it into the repo and possibly break the build.

Hudson Configuration

  • For Hudson, first configure the build to check out the sources
  • Then, set these properties in build.xml; change paths to where your sources and releng project are located:
<property name="localSourceCheckoutDir" value="${WORKSPACE}/org.eclipse.gef" />
<property name="relengBuilderDir" value="${basedir}" />

Local Build In Eclipse Configuration

  • For a local Eclipse build, it depends on how/where you checked out sources. If you checked out the whole /cvsroot/tools/org.eclipse.gef folder tree as a single project in your workspace, org.eclipse.gef.tree, you might might specify it in like this:
<property name="localSourceCheckoutDir" value="${basedir}/../org.eclipse.gef.tree/" />
<property name="relengBuilderDir" value="${basedir}" />
  • Then, to be able to properly edit & compile plugins in your workspace, you'll have to File > Import > Existing Projects > ~/workspace/org.eclipse.gef.tree/plugins/ > select plugins to import. Do not copy them to the new project location - you want them to simply be a reference to the actual subfolder path (linked).
  • With everything imported from the local folder, you can edit them as projects, and spin a build to verify your changes haven't broken the build.
  • Next, close or delete the whole-tree project (do not delete from disk, only the workspace). This will prevent Eclipse getting the parent folder and its subfolders out of sync, and you won't see the same the same files listed twice in the Synchronize view.

Debug Build

Here are some general tips for finding log files and sifting the build's tea leaves:

  • Always log to a file, preferably a unique one. You can watch console output AND log to file (standard out and standard error) with this:
ant -f build.xml -debug 2>&1 | tee /tmp/buildlog_`date +%H%M%S`.txt
ant -f build.xml -verbose 2>&1 | tee /tmp/buildlog_`date +%H%M%S`.txt
  • Logs can be found in the build's folder like this:
find /path/to/build/folder -type f -name "*log" -o -name "*log*.txt" -o -name "*"
  • Search logs for keywords like "ERROR" and "FAIL" to see what went wrong
  • Chances are if something really bad happened, it occurred in the first or last 100 lines of the log.

See Also

Back to the top