Skip to main content
Jump to: navigation, search

JWT Automatic Build

Automatic build of JWT Features and Plugins

Helpful resources

The following link includes an Eclipse Tycho tutorial that would serve as a very useful resource demonstrating how to build Eclipse plug-ins, features and how to create Eclipse p2 update sites with Maven Tycho.

Building JWT on Hudson using Maven Tycho

This section presents information concerning the JWT 1.3.0 build for eclipse Kepler on Hudson and would be considered as a very useful resource for JWT's future release engineers (starting with Eclipse Luna scheduled for release in 2014). Some of the information/steps that follow might be not necessary for future JWT builds using Maven Tycho since they have already been done but we illustrate them anyway so that we would have a comprehensive and complete documentation of the whole building process.

Master project for the build

The current master project for the JWT build is a project of type Generalmvn-jwt-builder found at This project contains the master pom.xml for building the plug-ins. This pom.xml file contains all modules that are related to the build. Modules are the features and plugins to be built in addition to the p2update site of the project. The master pom.xml file also contains general information about the build like the project's repositories in addition to links to any external plugin dependencies the build might need.

Add new Features/plugins to the build

Future release engineers should add the paths to any new features/plugins in the master pom.xml file. In addition, they should also add any new plugins to one of the features and include any new features needed in the p2update site to the category definition of the p2update site project found at [[Future release engineers should add the paths to any new features/plugins in this file. In addition, they should also add any new plugins to one of the features and include any new features needed in the p2update site to the category definition of the p2update site project found at]]. Please, note that any new features or plugins have to have their own pom.xml files as well as described in the tutorial recommended above.

P2 update Site project

The p2 update site project includes jars generated from the build and that are required for installing JWT. The current p2 update site project is a project of type Generalcalled org.eclipse.jwt.p2updatesite and can be found at This project also has it's own pom.xml file and it includes a profile that signs the JWT jars using the eclipse signature. This is prerequisite for eclipse projects and the details of signing the jars will be explained in the following section.

Signing the JWT jars using the eclipse signature

First, the proper repository was added to the master pom.xml. 


After that, a profile was added to do the signing. To sign the jars, the following has to be done:

  1. Pack the p2 repository
  2. Sign the p2 repository
  3. Repack the p2 repository
  4. Fix checksums because signing and packing alters them.

The following profile performs the mentioned steps.



Handle automated testing

Another main point was to have the ability to run unit test on the just build JWT plugins, to avoid silent regressions. Our steps to do so were:

  • Copied an example tester (we used GEF and Platform ones as examples)
  • Same strategy as for the builder: externalize strings from the test.xml to the builder file, and then adapt values to JWT
  • Added the automated fetching of the test feature in the customTargets.xml
  • Added test plugins and features to the map file
  • In the master test plugin, copied a test.xml from another test plugin (not a test.xml from a tester)
  • In the tester's test.xml, adapt the creation of the runtime we'll use for testing
    • The test runtime is created dynamically as a copy of the build base
    • And we add the JWT plugins and JWT tests plugins in it (expanding zips into the test runtime directory)
  • Update the createUpdateSite.xml so that it copies test results into the update site


We encountered a problem with p2 file generation: Indeed, setting the generate.p2.metadata to true made metadate generated also for the test feature, whereas we do not expect to deliver them.

Then the solution was to set generate.p2.metadata to false, and then to run the p2 generator on the generated update site. The p2.generate ant task does not seem to support the site attribute, thus we simply used an Ant exec task calling the eclipse p2 generator application as we would have done with command-line.

What can still be done

  • Try to use a build/continuous integration server
  • Try to have nightly build
  • Merge builder and tester: Move the test.xml from tester to builder, test and replace references to tester by builder.

What we have

JWT build minimal Eclipse base

In order for the build and automated testing to be working as fast as possible, it is necessary to maintain a build base (in /shared/technology/jwt/base on, that contains only the projects that are necessary to build and test JWT, and to ensure that these project are built for for the build server you are using.

Creating the base with from repositories (recommended)

P2 is the recommended way to install feature since it checks dependencies and avoids to forget some bundles that are necessary at runtime for testing.

  • Download a platform that is OK with you build host architecture => ~/downloads/eclipse/downloads/[buildId]/eclipse-SDK-[version]-linux-gtk-ppc.tar.gz from
  • Transfer to the /base directory on (e.g. with SCP) and expand
  • Go into the new eclipse folder, then type
    • export LAUNCHER="java -jar plugins/org.eclipse.equinox.launcher_*.jar -application org.eclipse.equinox.p2.director"
    • $LAUNCHER -metadataRepository -artifactRepository -installIU -installIU -installIU -installIU org.eclipse.gef -installIU (dependency list to be updated following JWT deps)

In case you want to install a feature from a repository that is not p2-ready, you can use

  • java -jar plugins/org.eclipse.equinox.launcher_*.jar -application org.eclipse.update.core.standaloneUpdate -command install -featureId [FEATURE_ID] -from [SITE_URL] -version [VERSION]

Creating the base using drops (not fair)

To create a build base, you'll need to expand the following project in the directory you want to use ase the eclipse base:

  • Eclipse platform linux/ppc/gtk => ~/downloads/eclipse/downloads/[buildId]/eclipse-platform-[version]-linux-gtk-ppc.tar.gz
  • Eclipse PDE => ~/downloads/eclipse/downloads/[buildId]/eclipse-PDE-[version].zip
  • Eclipse JDT => ~/downloads/eclipse/downloads/[buildId]/eclipse-JDT-[version].zip
  • EMF Runtime => ~/downloads/modeling/emf/emf/downloads/drops/[version]/[buildId]/emf-runtime-[buildId].zip
  • GEF Runtime => ~/downloads/tools/gef/downloads/drops/[version]/[buildId]/GEF-runtime-[buildId].zip
  • ATL Runtime (for transformations) => ~/downloads/modeling/m2m/atl/downloads/drops/[version]/[buildId]/m2m-atl-runtime-[version].zip

Choosing the version of each project:

  • Currently, JWT build on Eclipse server uses the latest version that contains a Maintenance or Release build (ie buildId starting with R or M)
  • However, we could discuss about trying to build usng stable or milestone builds, to ensure the compatibility with the latest versions of projects. But this would require much more work until we succeed to automate the creation of the base with the latest drops...

Check an existing base

There are 2 ways to check that an eclipse installation matches your machine platform:

  • Try to run the eclipse launcher program (./eclipse). If eclipse starts, it is OK
  • From the eclipse directory, try command ls plugins/ | grep org.eclipse.swt, then you should get a list of plugins, and one of them specifies a os/ws/arch 3-uplet in its name. It must be match your server platform.

If you don't have the same eclipse target and server platforms, then you might be able to build, but testing will be impossible for you.

How to use it

Update sites organisation

First, as it is the case in most of "one feature" projects (such as GEF), JWT now has 3 update sites:

Building on


Since testing requires the ability to start the eclipse UI, an X server must be started and the DISPLAY environment variable must be correctly set on the build server. See EMF advices about X configuration for more details.

On, you can use the Xvfb server started by root on localhost:1.0 (DISPLAY is automatically set to this value when running

If you there is a problem with X server, you'll have the bahavior described above:

  • In the build trace, the Java Result: 13 tells you that eclipse could not start
     [echo] Running org.eclipse.jwt.we.tests.AllTests. Result file: /shared/technology/jwt/tester/results//org.eclipse.jwt.we.tests.AllTests.xml.
     [java] Java Result: 13
  • In the result file, you see a desperately empty test result
<?xml version="1.0" encoding="UTF-8" ?>
<testsuites />
  • In the eclipse log (tester/results/org.eclipse.jwt.we.tests.AllTests.txt), you can see a message telling you that a problems occurs with display:
org.eclipse.swt.SWTError: No more handles [gtk_init_check() failed]
        at org.eclipse.swt.SWT.error(

Start a build

Anyone who has access to can now start a build of cvs HEAD by browsing to JWT home folder (/shared/technology/jwt), going into the builder folder and typing ./ [buildType] where build type is I (default), S or R, respectively for integration, stable or release build.

This script will start the whole build process and update the update-site for the specified build type.

Follow your build on Hudson.

Start a build on your local machine

If you want to build locally JWT, simply checkout the org.eclipse.jwt/releng CVS module and write a script that starts the build with your local configuration (please do not modify or, that are files). See for example.

Continuous integration

TODO Note that the PDE build process supports unit testing. I've read about several Eclipse projects that used a continuous integration tool (such as cruise, continuum or hudson) to monitor their builds and test results. I'll try to choose if one of these solutions is fine for JWT.

Releasing Policy

When releasing JWT, here are the steps to follow:

  1. Tag the feature and all plugins included into the release with tag R{releaseVersion} (for example R0.5.0)
  2. Build on the feature to release (./ R). The update site is automatically updated.
  3. Increment the feature version number (See Version Numbering)
  4. Increment all plugins versions that will be modified in next release)
  5. Create a buzz about this release!

Adding new plugins to the JWT release

This section describes the steps to follow to add a new plugin to JWT release and get the build working with this add-ons. We'll use an example to facilitate the explanations.

Assume that jwt-we (plugin) now depends on a new plugin (jwt.we.conf.model) that was not part of the automated build before. In such case, some things needs to be updated to build the jwt-we automatically, else you'll get a "missing bundle" error telling you that the build cannot find the jwt.we.conf.model.

  • Ensure it conforms to legal and technical requirements
    • Plugin version must endswith .qualifier (see Version Numbering)
    • Message strings must be externalized and messaging must be based on NLS (See Message Bundle Conversion Tool and related docs)
    • More generally, it must conform with Eclipse requirements (See list on Galileo Simultaneous Release)
    • Ensure it conforms to legal Eclipse requirements
      • Provider must be
      • Plugin must include license and about files
      • License headers are necessary on all source files
      • More generally, see [2]
  • Add those plugins to the top-level feature (currently releng/jwt-feature) with version 0.0.0 (automatically chosen at build time)
  • Add those plugins CVS path to the builder map file (currently releng/builder/maps/
  • If your new plugin depends on other plugins (eg EMFT or M2M projects) that are not included in the build base, add its dependencies to the build base
  • Add the test plugins as dependencies to the top-level test plugin (currently jwt-tests-plugin)
    • Add them as dependencies to the MANIFEST.MF
    • Add them into the AllTests testSuite of the plugin
    • Add them to the top-level test feature (so that they will be fetched from CVS at build time, currently jwt-tests-feature, edit the feature.xml)
    • Add those plugins CVS path to the builder map file (currently releng/maps/

Back to the top