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

MoDisco/Releng/Athena/How to Use

< MoDisco‎ | Releng
Revision as of 03:55, 21 July 2010 by (Talk | contribs) (New page: {{Warning|This page explains how MoDisco was built using Athena. MoDisco is now built with Buckminster}} The MoDisco project is built using [[Athena Common B...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
This page explains how MoDisco was built using Athena. MoDisco is now built with Buckminster

The MoDisco project is built using Athena Common Build, with this releng project.

For more explanation about how the build process works, see also How it Works?.

What is built?

In the file of the releng project, the "mainFeatureToBuildID" property defines the feature that must be built. This feature must include all other features that must be built.

The releng project contains map files, which specify how to get the plugins and features that are to be built. For each plugin or feature, the map defines its location on a version control system (CVS and SVN are supported), and the version that must be used. Nightlies ignore the version information, and always build from head, whereas other types of builds checkout the tag or branch specified in the map.

How to start a build?


  • Nightly builds are run every 6 hours everyday, at 02:10, 08:10, 14:10 and 20:10 EST, if the MoDisco SVN changed since the last build.
  • Integration builds are started every Tuesday at 06:36 EST (11:36 or 12:36 GMT), if the releng project changed since the last integration build. That is, a new integration build will only be triggered when a map file changed.



  • In Hudson, click on Build Now, change the build parameters as needed (see #Build parameters), and click on Build.
  • You can then click on the job name in the Build History section in the left column, and then on Console Output, to follow build progress in real time.

How to publish a build?


Successful Nightly and Integration builds are automatically published to For example, a nightly build for version 0.8.0, created on October 6 2009 at 11:54 EST would be published to:

These builds can then be seen and downloaded from, where additional information is available (test results, build log, build configuration, build dependencies).


Stable, Maintenance and Release builds are not automatically published. They should be first tested internally before publishing. For example, to publish the 0.8.0M2 milestone build:

  • First, fetch the build archive to test:
scp -r <commiterid>* .
  • Then, test the build locally
  • Then, publish it:
ssh <commiterid>
cd /opt/users/hudsonbuild/.hudson/jobs/cbi-modisco-integration/lastSuccessful/archive/build/
cp -r S200910061155 /home/data/httpd/
  • Finally, for a release, update the update site with the new build:
rm -rf /home/data/httpd/*
unzip S200910061155/ -d /home/data/httpd/
  • You can enable download stats on the repository by running addDownloadStats.shon the update site
  • Check that the new build appears on
  • Update the archive site with the new build:
    • copy the drop folder (eg. "S200910061155") into /home/data/httpd/
    • update /home/data/httpd/ with a link to the newly added update zip

Simultaneous Release

If the build must be part of the simultaneous release, there are a few more steps to follow:

Build parameters

Hudson builds expect these parameters:

  • PROJECTID : modeling.gmt.modisco : no reason to change this
  • VERSION : the version being built, must also be set in the releng project's and
  • BUILDTYPE : the kind of build, represented by a code letter (see this page):
    • N: Nightly
    • I: Integration
    • M: Maintenance (NOT milestone)
    • S: Stable (for Milestones and Release Candidate builds)
    • R: Release
  • EXTRAFLAGS : flags that are passed to the build start script (see Useful flags are:
    • -buildAlias : for release, maintenance and stable builds, use this option to give a more meaningful name to the build. For example, add -buildAlias 0.8.0M2 to get "" instead of "".
    • -forceContextQualifier : force the ".qualifier" part of a plugin version number to a specific string.
    • -fetchTag : Force a specific tag to be used when pulling sources from the VCS. For example, use -fetchTag HEAD to build from HEAD instead of from the versions specified in the releng project's map files (doesn't seem to work with SVN maps).
    • -localSourceCheckoutDir : get the sources from a local directory instead of from the VCS. The nightly build job script is configured to checkout sources from the head of the trunk, instead of using what's indicated in the maps. This option is then used to indicate the checked out sources directory.

Building locally

First, checkout these projects into your workspace (you can import this team project set):

Then, setup the file in the MoDisco releng project with correct information for your system:

  • Set all the JAVA*_HOME properties to the location of your JDK 6 install (eg: /usr/lib/jvm/java-1.6.0-openjdk or C:/Program Files/Java/jdk1.6.0_16)
  • Set the downloadsDir property to a writable directory (eg: /tmp/build/downloads or C:/temp/build/downloads)
  • change the dependencyURLs with the Eclipse SDK zip specific to your platform

Additionally, you should change all the dependencyURLs to point to one of your local Eclipse mirrors, to avoid saturating the main Eclipse download server, and getting extremely slow downloads.

Alternatively, you can download the dependencies manually and put them in your downloadsDir. The build will then use the files you provided instead of downloading them itself.

Finally, start the build by right-clicking the build.xml file in the releng project inside Eclipse and choosing Run as > Ant Build.

Building on Windows

On Windows, the build is a little trickier, but it should work if you do this:

  • Add the workspaceDir property to the, with the location of your Eclipse workspace (for example: D:/workspaces/MoDisco)
  • Install Cygwin into C:\cygwin (a directory without spaces is recommended)
  • Prepend C:\cygwin\bin to the %Path variable (open System properties, click on Environment Variables..., and change the Path variable so that it reads something like:
  • Build from local sources instead of fetching from maps (see #Building from local sources)
  • If the build complains it can't find some tool, then install it into Cygwin by re-running Cygwin's setup.exe
  • Spaces in the path of the JDK cause problems. There are several possible solutions:
    • Use the "8.1" form of the path: (eg: "c:/progra~1/Java/jdk1.6.0_16"). You can find it by "dir /x" (thanks to Nick Boldt for this tip!).
    • (Re-)install your JDK in a path not containing spaces
    • Make a directory junction like this (on Windows Vista or 7):
C:\>mklink /J Java "C:\Program Files\Java\jdk1.6.0_16"
Junction created for Java <<===>> C:\Program Files\Java\jdk1.6.0_16

And then set the JAVA*_HOME variables to C:/Java in the

  • If tests seem to cause problems, you can disable them by removing buildTests and test from build.steps (and launch tests manually).

Building from local sources

You can set the localSourceCheckoutDir in the to a directory where you already have all the MoDisco sources. This directory should contain a "plugins/" and a "features/" directory.

You can build it by doing this:

mkdir MoDiscoTree && cd MoDiscoTree
svn export features
svn export plugins
svn export plugins --force
svn export
org.eclipse.gmt.modisco.tests.feature features/org.eclipse.gmt.modisco.tests.feature --force


To avoid having to do a manual svn export before each build, you can use links on Linux or directory junctions on Windows to link both "plugins" and "features" to the root of your workspace:

on Linux
mkdir /home/work/MoDiscoTree
ln -s /home/work/workspaces/MoDisco /home/work/MoDiscoTree/plugins
ln -s /home/work/workspaces/MoDisco /home/work/MoDiscoTree/features

And then set localSourceCheckoutDir=/home/work/MoDiscoTree in the

on Windows
C:\Users\Travail>mkdir MoDiscoTree
C:\Users\Travail>cd MoDiscoTree
C:\Users\Travail\MoDiscoTree>mklink /J plugins C:\Users\Travail\workspaces\MoDiscoAll
Junction created for plugins <<===>> C:\Users\Travail\workspaces\MoDiscoAll
C:\Users\Travail\MoDiscoTree>mklink /J features C:\Users\Travail\workspaces\MoDiscoAll
Junction created for features <<===>> C:\Users\Travail\workspaces\MoDiscoAll

And then set localSourceCheckoutDir=C:/Users/Travail/MoDiscoTree in the


To tag a release, use this script:
Releases should have a tag like R0_7_1, and milestones should have a tag like S0_8_M5.

Tag names
Since the tag name is used as a bundle qualifier by PDE Build, it should not contain periods. For example, use R0_7_1 instead of v0.7.1

Checking bundles

Check that each bundle contains an about.html file:

for f in $( ls *.jar ); do unzip -t $f | grep -q about.html || echo $f; done

Back to the top