Working in OSS projects means that much of the time the only chance you get to meet co-developers and other community members is when conferences like EclipseWorld happen. Usually, you get to meet brand-new people and have interesting conversations with them. At the Wednesday night Tailgate Party at EclipseWorld I was introduced to Chris Aniszczyk and - I don’t know how we got into it - we had a little conversation about the PDE. My major gripe relating to the PDE is the headless facilities for automating build, test and coverage - after I compared it to something like chewing ground glass, Chris informed me with a grin that he worked on the PDE UI. The PDE UI you will agree is in good shape. You just have to take a look at the new and noteworthy for 3.3 M1 to see that the team haven’t been sitting on their keisters since Callisto. It’s great to use, but from my perspective it’s only part of the equation of shipping software on the Eclipse platform. Back to the PDE headless build. The PDE build works - right now every Eclipse project uses it as far as I know. But it’s got a steep learning curve, and it’s brittle. I know this from experience :-) So let’s fast forward to now: in STP we got the PDE build to work well under the expert guidance of Naci Dai, who is the JST lead and buildmeister extraordinaire. Adrian carries on the torch and maintains the STP build for us. I’ve probably timed this badly, but we would like some more people to help us with build mastery. Send email to the usual address - stp-dev@eclipse.org :-) Update: looks like Felix is heading out of incubation! Update: a sudden conversation on Bug 154251 - Maven2 Integration shows some relevant work in progress.
Unfortunately we - the Eclipse developers - are not in a position to make much of a choice in the matter of building our projects. The PDE build will build Eclipse for us, but nothing else can really engage with the way Eclipse wants to be constructed. Of all the build system approaches available for Java, there’s probably only two that are front runners as an alternative to the PDE build.
The first one is Buckminster - but the technology product named for the inventor of the geodesic dome appears to be closely aligned with the existing build approach and has as a goal the ability to materialize component dependencies from other, non-Eclipse, worlds. I confess I don’t fully understand how Buckminster really operates, however, so I’m looking forward to meeting up with some of the guys behind it at the Eclipse Summit in Esslingen in October and asking them to explain in easy words what it is all about.
The second one is Maven. Most new java open source projects seem to use maven as their buildsystem. The maven software is itself open source and uses a plugin architecture to permit the addition of new capabilities. The pluggable nature of the software is the basis for a flourishing ecosystem of open source extensions, which is a really good thing.
By the way guys, it would be cool if someone could put together a PlanetMaven tracker (see PlanetEclipse for example) or something like that so we could have a single go-to place for plugins and plugin doco.
So, maven and eclipse don’t play well together because both of them are trying to do the dependency tracking. But there seems to be a genuine interest in moving towards some kind of resolution here. My colleague Conrad (who’s doing a talk at OSCON in Brussels - I’ve seen the drafts and heard the conversations and I recommend you go see it) tells me that the Geronimo guys are making some good progress in this area as part of their Development Tools subproject. Download the source for the details. I’ve also had a look at the OSGi plugin for maven that is part of the Felix project at Apache, which generates OSGi plugins in a hassle-free manner, but still needs a small amount of work to give it the ability to include Eclipse-specific manifest entries and offer some options on being able to fine-tune the content of the Classpath: manifest entry.
Also, the fact that Simula Labs has joined the Eclipse Foundation as a strategic developer makes me think that we’ll see more going on in this area. SimulaLabs are of course the parent of Mergere - a source of all things to do with Java build processes in general and maven in particular.
Of course, just because the PDE build is difficult to grok, sketchily documented and somewhat brittle doesn’t mean it should be replaced. Ideally more love here from the Eclipse development community would reduce the burden of the buildsystem maintenance and close off many of the issues.
As usual, the community will decide in it’s own way what to do here. Whatever the route taken, any action will lead to an improvement of the status quo.