Friday, March 26, 2010

AJDT-PDE builds Redux

AspectJ-aware PDE builds in AJDT have always been a bit of a kludge. So, I'm happy to say that as of Eclipse 3.6 (Helios), things will be changing for the better and AJDT will rely on a different mechanism to perform PDE builds.

PDE, or the Plugin Development Environment, is the tool set that helps developers build plugins for the Eclipse platform itself. In Eclipse 3.5 and earlier, AJDT shipped with its own version of the PDE tools (AJDT-PDE) that were largely a copy of Eclipse's PDE, but with a few key changes so that a different compiler could be plugged in. It is an understatement to say that this was inefficient. The AJDT-PDE had to be re-created for each point release of Eclipse so that it could be re-based off of the new version of PDE. This process was fallible and inevitably, some features of PDE were missing or broken in AJDT-PDE.

I have been working with the PDE team to create a more sustainable solution to AspectJ-aware PDE builds. From AJDT for Eclipse 3.6 and onwards, the AJDT-PDE will be removed. The AspectJ-aware export wizards will be deprecated and the plugin will be redundant. Instead, users can use the standard PDE build, with the following changes to the file of your plugin project:

# required
sourceFileExtensions=*.java, *.aj

# optional
compilerArg=-aspectpath other.jar

The first line specifies that the AspectJ compiler should be used instead of the Java compiler. The second line specifies what file types should be considered source files. And optionally, you can specify a number of command line arguments using the compilerArg property. Only AspectJ-specific arguments like inpath and aspectpath need to be specified here. For all standard Java options, like source and target you can use the standard PDE-Java options javacSource and javacTarget.

From here, you can use the standard PDE export wizards or PDE headless build scripts to build your project. That's it. There is now nothing special needed for AspectJ-aware PDE builds.

Furthermore, it is possible to create your own compiler adapter so that you can use your own custom compiler for your own JVM language (and avoid using javac). You need to do the following:

  1. Implement and delegate to the compiler of your choice

  2. Ensure that this new compiler adapter is on the ant classpath. I recommend using a org.eclipse.ant.core.extraClasspathEntries extension point so that your plugin automatically contributes the classpath to Eclipse's ant runtime. But, you could also specify it in your global ant classpath properties page.

  3. In your file, fill in the proper values for the compilerAdapter, the sourceFileExtensions, and the compilerArg properties.

That's really all there is to it. For all the gory details on how this works see Bug 303960.


  1. This is great! It's nice when relatively simple changes have such a large affect downstream.

  2. I have tried this, moving from the approach. But it does not work, not sure why. I posted to the Equinox Eclipse forum, but no one there answers the query. Not sure what I am missing. But get:

    [java] Starting Groovy-Eclipse compiler resolver. Specified compiler level: 2.0
    [java] Unknown target: *.aj

    So clearly the arguments are not being picked up?

    1. What's the link to the forum post? Also, what do your config files look like?

    2. is the link

    3. I tried your answer already, it had not worked, I specified the error in my reply.

  3. Is there professional support available for debugging AJDT_AjcCompilerAdapter? Because I am not getting help on the forum and we are crippled by it not working for us.

  4. Sorry to hear that things aren't working out for you. I am not actually working on this project any more and don't have any spare time to put into this. But you can contact the aspectj-users mailing list and describe what is going wrong. Please link to the forum post and this discussion. The current maintainers of the aspectj compiler and tools will be able to respond there.