Kofno

Eclipse: What Doesn’t Work About PDE Builds

August 28, 2006 · 1 Comment

Twice I’ve tried to use the PDE to generate headless builds for my Eclipse plug-ins, and twice I’ve given up in disgust. This is frustrating because there is a lot of promise in the PDE environment.

Here’s my current hit list for PDE build scripts:

Hard coded paths to the Eclipse plug-in jars.
One of my plug-ins generated a build script with about twenty paths that started like this:

..\..\..\..\..\..\eclipse_3.1\target\eclipse\plugins

Holy crap! That is a big pain. I can’t run that build from a different branch on my machine, much less on the build portal, without regenerating the build script. Eclipse has provided ant tasks for doing just that, but, if you want to use them, you need to use the Eclipse antRunner. This segues nicely with my next gripe.

antRunner! WTF?
To run Eclipse builds headless, you need to use the Eclipse antRunner application. This breaks the Ant interface, plain and simple. Just typing ‘ant’ should get some sort of reasonable result. Failing that, typing ‘ant -p’ should provide some usage information*. Instead, you get to type something like this:

%JAVAEXE% -cp %STARTUPJAR% org.eclipse.core.launcher.Main -noupdate -application
org.eclipse.ant.core.antRunner -data %WORKSPACE% -buildfile %BUILDFILE% <taskname>

There’s another problem. If you’re building an RCP application with the antRunner, you’re required to have the Eclipse IDE installed on every machine that might make that build. One of the benefits of using Ant is that it allows you to create a build script without IDE dependencies.

I suppose I’m just being a tad pedantic. Either way, I still think the right thing for me to do was to write my own scripts.

Rolling your own
Rolling your own build scripts has it’s share of pitfalls. You need to manage your dependencies in two places, which you’re probably doing already if you’re using Eclipse for development and Ant for builds**. The real hassle is keeping your plug-in version numbers synchronized. I set all of the versions to 0.0.0 in the PDE and I set a version property in the build scripts. Then I replace all those 0.0.0’s with the version property during the build. The obvious shortcoming with this technique is that all of your features and plugins will have the same version number. I found this to be acceptable, if not ideal. Your mileage may vary.

Improving the PDE Build Scripts
Three things that could be done to improve headless PDE builds:

  1. Store the path to plugins as a property. Then at least the paths could be replaced on the command line. This doesn’t work very well if plugins are stored in several places. Those people are probably still stuck with custom scripts.
  2. Don’t use Ant tasks that can only be run from within Eclipse. Also, taskdef, if you don’t mind…
  3. Support generating a MANIFEST.MF from a build script for use in the IDE.

*That is why you use the description attribute on your main Ant targets.
** Maven has a pretty elegant solution for this; use the build to generate .projects files.

Categories: Uncategorized
Tagged: , , ,

1 response so far ↓

  • Roro // January 6, 2007 at 4:23 pm

    Join the club, eclipse didn’t do much to ease the PDE devolpers on the package things. BUT I must say that it IS possible to build (and complete) a build cycle with a little bit of patient…

Leave a Comment