Eclipse: What Doesn’t Work About PDE Builds

28 08 2006

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.

Advertisements

Actions

Information

One response

6 01 2007
Roro

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 Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




%d bloggers like this: