[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] Integrating with an external build system (Ant, Maven, etc.)
- From: "Alex Blewitt" <alex.blewitt@xxxxxxxxx>
- Date: Sat, 10 Jun 2006 13:08:46 +0100
- Delivered-to: email@example.com
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FNlbP4oBK/7Mqke2rR+IY+v7FYzmDxd3wTwKEJh1o/YkMmhuwk4dbUeEQu4l6Nxk7ooOQ0DiZEdq0oYqApNyPbj1FqDOnWQ1Qw6qSSQckvTKbIX3mj9pdPgMAujnObrDTNN39F1OexmZXczrW8E+1yAoxHRsAJ9l57hn7BS4OvA=
- It is not an incremental build - it builds everything every time.
True. Maven can build everything, or individual modules. One of the
differences is that the PDE build builds everything from a 'clean'
state, whereas Maven can at least keep the previous build output and
thus just compile any changed code.
- PDE build is tightly coupled with CVS by default. It assumes that
the code is supposed to be checked out of CVS and then compiled.
That's okay for some situations, but if you want (say) a pre-commit
validation build, or if you use Subversion, then you have to do some
True. But it's not that difficult to get a SVN build; all you need to
do is skip the fetch from CVS (skipFetch=true) and then checkout/copy
the source where the build would expect it to be.
- In general I feel PDE Build is difficult to setup and overly
complicated, making it hard to diagnose when something goes wrong. By
overly complicated, I mean that you run an ANT build which runs a
headless Eclipse application which calls another ANT build which calls
a series of (generated!) ANT build files, which then make calls back
into the ANT build which called them... you get the picture.
It is pretty complicated ... and works when everything is OK. It's
easy to get the map files wrong, though. One of the other downsides is
that each build is a suite of plugins which are (potentially) built
each time. So if you download the Eclipse platform, and then download
the Eclipse SDK, the two plugins contained are potentially different
versions; either because they're mapped to different versions, or
they've been compiled by two separate build processes and potentially
different command line options (e.g. stripping debug symbols). It's
probably one of the reasons why there's no OSGi plugin repository like
a Maven repo, because the plugins are recompiled for every feature
that they're included in.
I would like to investigate Maven or Ivy, but I have some concerns
about those as well, maybe somebody else on the list can clarify
something for me. When building a bundle, can Maven or Ivy validate
that only the imported packages specified in the
Import-Package/Require-Bundle manifest headers are referenced from the
code of that plugin? How do they resolve those dependencies at compile
time, and how can I be confident that a bundle which cleanly compiled
will not throw CNFEs at runtime?
Can't speak for Ivy, but with Maven, you have your own list of
dependencies in the maven project file, so it ignores any manifest
files and you have to build your own. Worse, Maven 1 doesn't handle
transitive dependencies, so if you're building a plugin that depends
on JFace, you have to depend on SWT and others. Maven 2 does handle
transitive dependencies, so this should be less of a problem (but I
only investigated Maven 1).
Since Maven just uses the ant Javac task internally, I don't think it
can be parameterised to specify which package(s) to use, so you can
have a build that potentially violates the import packages. If you're
just using import-package, you still have to specify in the Maven
build what projects to depend on, so it doesn't really matter if it's
require-bundle or package-import. There's nothing in Maven2 that is
plugin aware; so you'll have to sync the project dependencies with the
manifest yourself. (You can get Maven to generate a Manifest.MF on its
own, but you'd then need to ensure that your development environment
is synced with the build environment.
Don't know if any of that helps. I put together a maven build of
plugins (as well as the PDE build) for the presentation @EclipseCon;
the maven build you can checkout from the directions at
http://www.rcpapps.org/EclipseCon2006/ -- but as I said, it's Maven 1.