Skip to main content
Jump to: navigation, search

Developer's guide to driving the AJDT build process

Revision as of 11:50, 16 January 2007 by (Talk | contribs)

The AJDT automated build process generates various artifacts not created by running an eclipse build, and now provides additional functionality such as packing JARs with the pack200 command, to produce a faster udpate site. However, getting the build working on your own machine has various gotchas, which this page hopes to help you through.

*** This is work in progress, currently being updated from draft version on another machine - please don't attempt to follow this guide until this comment is removed :-) ***

This guide assumes, for now, that your starting point is that you have followed all the steps in the standard developer's guide here:

AJDT Developer's Guide

It is certainly a good idea to familiarise yourself with the Eclipse environment prior to attempting a command line build, but by no means essential. It is also assumed that you are building on Windows XP, or failing that, that you will understand the changes required in order to build on, say, Linux.

The first thing to do is create a root build directory, e.g.


and inside it two directories containing Eclipse installs (including AJDT) versions 3.2 and 3.3, e.g.:


NB The naming of these directories is important so use these names, unless you want to change config files (clue: you don't). Both these versions of Eclipse are required, as the build runs using 3.2 but needs 3.3 to build the latest versions of AJDT. So, the simplest thing to do is run up a couple of versions of Eclipse, install AJDT in each, then copy the file sets to your build directory.

Next you need to patch the two Eclipse installs to use the AJDT version of a file called "pdebuild-ant.jar". You'll find that target version under the two respective eclipse3x directories, e.g.:


or something silmilar, depending on the versions of the plugin you have. Replace this file with the AJDT version from:


again, allowing for the version of AJDT you have. This patching results in the AspectJ compiler being used instead of the Java one, so is important, as it saves you wasting a lot of time staring at lots of compilation errors :-)

You now need the AJDT build file for the version of AJDT that you want to build. This is not currently available in CVS, so has been added here as a separate document here on the wiki for now AJDT 1.5 build file

Save this to your root build directory. You now need to set up some environment variables. Add the ant binaries directory to your path and set the ant home variable. If you don't have ant, go get it from Apache Ant Downloads. E.g.:

set PATH=%PATH%;C:\ant\bin
set ANT_HOME=C:\ant

You will also need to have a CVS executable on your PATH (e.g. TortoiseCVS, as the ant CVS task requires it.

Before running the build script, you need to override the default setting for your JDK 1.5. You can either edit the java15-home property at the top of the build script, or override it on the command line with the option (e.g.)


when you run the ant script (where C:\jdk1.5.0_08 is obviously the location of your JDK). The other properties should be fine with the defaults, unless the location of the CVS repository/package or the update site URL have changed.

You should now be able to run a PDE build, using the following command:

ant -buildfile build-ajdt1.5.xml pdebuild -D-Djava15-home=C:\jdk1.5.0_08 

Or for more debugging information from ant:

ant -buildfile build-ajdt1.5.xml pdebuild -D-Djava15-home=C:\jdk1.5.0_08 -verbose

Assuming you are not using the verbose switch, the first message from ant will be:

[taskdef] Could not load definitions from resource com/ibm/lakeba/ant/ It could not be found.

This is to be expected and can be ignored. However, you should be wary of the ant "Build successful" message once the task has compelted; it's a good idea to check the output for any obvious stack traces, or earlier instances of "Build failed". Assuming all is well, you should now be able to see the built artifacts in (e.g.):


Look under the 'updateSite' subdirectory to see the built 'features' and 'plugins' subdirectories, and the contents therein.

Back to the top