Jump to: navigation, search

Difference between revisions of "Common Build Infrastructure/Getting Started"

(Initial content from modeling/downloads/build-types.php)
(Build Types)
Line 101: Line 101:
Releases are builds that have been declared major releases by the development
'''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
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
to be on a stable, tested release, and don't need the latest greatest features
Line 110: Line 110:
Stable builds are integration builds that have been
'''Stable builds''' are integration builds that have been
found to be stable enough for most people to use.  They are promoted from
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
integration build to stable build by the development team after they have been

Revision as of 11:41, 6 April 2009

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 project (often called a .releng project) to house your configuration settings. Here are some sample projects to get you started.

At its simplest, this is:

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

However, you will likely need to feed in extra dependencies to the build, if it requires more than just the Eclipse "Classic" SDK to build (ie, JDT, PDE, CVS).

  • buildExtra.xml -- extra inputs and packaging steps

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

  • testing.properties -- properties specific to running tests

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

  • promote.properties -- properties specific to publishing builds

Check all these files into CVS or SVN.

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 build.eclipse.org, read on:

To set up the local bootstrapping required to run a build, you can run this script:

Note that this script is currently only supported on Fedora 10. We're looking for testers to try it out on other linuxes and on Windows via cygwin. If you can't get it working, use it as a checklist for the manual steps required to get your local machine set up to build.

Once you've set up your environment, you should have something like this:

3rdPartyJars/ [libraries and 3rd party jars, including ant-contrib.jar]
downloads/    [dependencies, cached and reused]

scripts/      [build system scripts & tools]

org.eclipse.dash.common.releng_HEAD/ [a specific version of o.e.d.c.releng]
org.eclipse.dash.common.releng/      [a symlink to the above]

org.eclipse.releng.basebuilder_R35_M5/ [a specific version of o.e.r.bb]
org.eclipse.releng.basebuilder/        [a symlink to the above]

org.eclipse.pde.build.svn-1.0.1RC2.zip [required for making PDE understand SVN map files]

Run A Build

What Can I Do?

  • You can build in Eclipse using Ant and a build.xml script, or headlessly via commandline using start.sh (which in turn launches Eclipse's AntRunner too).
  • 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 few sample .pcf files to help you share this configuration with your team.
  • You can build in, for example, /opt/public/cbi/build/tools/gef/downloads/drops/3.4.0/N200902260105/, or in /tmp/build/tools/gef/downloads/drops/3.4.0/N200902260105/ or in /tmp/build/N200902260105 - whatever you want you can do.
  • You can build with Hudson - there are sample wrapper scripts for start.sh to pass though Hudson parameters. You can either copy the whole script into the hudson config field, or if the script is elsewhere on the disk, you can simply point at it like this:
. /opt/public/cbi/build/org.eclipse.dash.common.releng/hudson/gef-3.4.x-nightly.sh


  • 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 build.properties; 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. Release builds always have an "R" at the beginning of the name i.e. R1.0, R2.0 etc. Non-release builds are named according to the date of the build - for example 20090406 is the build from 6 April 2009.


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.


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.


Maintenance Builds - Periodically builds for maintenance of the current release will be performed. They will not necessarily be stable builds. When the maintenace is finalized and released, it will be moved up to a Release build. If the build name starts with an "M" i.e. M20031110, then it has not been tested for stability. If it is a release candidate, i.e., then it is a stable maintenance build.


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.

Commandline Headless Build

Builds are run though start.sh, which sets up configuration variables and invokes Eclipse's AntRunner to run the build. Testing is done by having this ant thread call into the shell to start a new Eclipse thread on a different display (or one day, a remote machine). As such, there is still some dependency on bash scripting for the build system to work. We plan to remove this dependency over time.

Here's a sample invokation of start.sh -- run the script without any commandline options for other examples, or check out the README.txt files in the other sample projects:

cd /opt/public/cbi/build/org.eclipse.dash.common.releng; \
cvs up -Pd; cd tools/scripts; ./start.sh -projectid tools.gef -version 3.4.0 \
 -projRelengRoot ':pserver:anonymous@dev.eclipse.org:/cvsroot/technology' \
 -projRelengPath 'org.eclipse.dash/athena/org.eclipse.dash.commonbuilder/org.eclipse.gef.releng'
  2>&1 | tee /opt/public/cbi/logs/buildlog_`date +%H%M%S`.txt

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 basically 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. Here's a sample.

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

In Hudson

The quickest way to get started w/ Hudson is to copy an existing configuration, because not everything in Hudson can be scripted and stored in VCS.

In the above configs, a pre-checked-out cache of basebuilder and common.releng are available in build.eclipse.org:/opt/public/cbi/build/ 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.

Build From Local Sources

It's a bit of a hack at the moment, but 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.

Here's how:

  • Symlink org.eclipse.test and org.eclipse.ant.optional.junit into your own project's repo so that a .psf fetch or other cvs/svn checkout will get them:
cd /cvsroot/tools/org.eclipse.gef/test; \
ln -s /cvsroot/eclipse/org.eclipse.test/; \
ln -s /cvsroot/eclipse/org.eclipse.ant.optional.junit/


  org.eclipse.test -> /cvsroot/eclipse/org.eclipse.test/
  org.eclipse.ant.optional.junit -> /cvsroot/eclipse/org.eclipse.ant.optional.junit/
  • Next, point the build at the folder in which the sources are located.

Hudson Configuration

  • For Hudson, first configure the build to check out the sources
  • Then, use this option when invoking start.sh:
-localSourceCheckoutDir /opt/users/hudsonbuild/.hudson/jobs/cbi-gef-3.5.x-nightly/workspace/org.eclipse.gef

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 as a single project in your workspace, you might might specify it in build.properties like this:
  • Then, to be able to properly edit & compile plugins in your workspace, you'll have to File > Import > Existing Projects > ~/workspace/org.eclipse.gef/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:
start.sh ... 2>&1 | tee /opt/public/cbi/logs/buildlog_`date +%H%M%S`.txt
  • You can also use this, which will dump a log in your build's folder for you:
  • 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 "*log.zip"
  • 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