It's a bit of a hack at the moment ({{bug|252774}}), 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.

+

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:

* 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, org.eclipse.gef.tree, you might might specify it in build.properties like this:

+

* 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 build.properties like this:

Set Up Locally

In Eclipse

Commandline / Server

To set up to build commandline outside Eclipse, eg., as a server like build.eclipse.org, 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.

Requirements

Ant-Contrib is required to run the build. You can put this jar in one of 4 different places, at your discretion:

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

R

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`).

S

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`

I

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.

M

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`

N

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.

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.

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.

If using the shared Hudson instance on build.eclipse.org, use the following path in your myproject.releng/build.properties file:

writableBuildRoot="${WORKSPACE}/build"

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:

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 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.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: