28 August 2006

Eclipse PDE == Ass

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\targete\clipse\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%

There's another problem. If your 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.


5 comments:

tormp said...

where's the funny video? this doesn't seem like a funny video.

tormp said...

have you tried writing an ant task that assembles a classpath out of all the jars under the eclipse workspace subtree (the ant-contrib tasks are particularly good for scripting that kind of thing)? would that do away with the need to use eclipse's donkeybutt antrunner class?

kofno said...

Well, the classpath problem is pretty solvable. The real hang up is manging the versions of all the plugins and features. The OSGi spec is pretty asstastic in that it sticks those versions everywhere (in the plug-in manifest, in the feature manifest, in the update site descriptor, in the goddamned jar file name...). Eclipse has an ant task that manages that for you, but it requires the Eclipse plugin repository to work.

kofno said...

BTW - I posted this from writely. I don't recommend that you do that, because it looks like it boned up my layout and lost my title.

tormp said...

ahhh right versioning. this is something that seems to come up again and again. you mention maven. are you using it at all? it seems nearly impossible to adapt it to a build environment that wasn't founded on maven to start with. please comment if you have had other experiences.

i spent some time looking at Ivy as a version-managing build system for a while. there's a fairly extensible (by plugin programming) versioned-dependency-management scheme in there. looks like it might do the trick, but ESL issues in the docco create a barrier to entry, at least if you want to do some customization.

i'll have to give that writely thing a shot.