[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Integrating with an external build system (Ant, Maven, etc.)

Some comments inline.

"Alex Blewitt" <alex.blewitt@xxxxxxxxx>  wrote on 06/10/2006 08:08:46 AM:

> > - 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
> > hacking.
> 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.

Eclipse 3.2 has new support for plugging in support for different repositories in PDE Build.  I'm not sure if there is an SVN extension yet, but its likely at the top of someone's list.

> > - 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.

Just to be clear, plugins for Eclipse are built only once.  The Eclipse SDK contains the exact same plugins as the Eclipse platform.  Plugins are only contained in one feature and the difference between the SDK and platform is which features are included.  The build is driven by one master feature which is a superset of everything, then afterwards everything is repackaged into the different zip distributions.

> > 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?
> 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.

It is unclear to me whether or not the maven-compiler-plugin lets you specify which compiler to use.  It does support passing additional arguments to the compiler.  This is how we did support for package access rules in PDE Build.  We generate a file containing the rules in a format that the JDTCompilerAdapter understands and pass this file over to the compiler through the javac task using a compilerArgument.    

To do access rules in maven, you likely need a compiler plugin which will generate the access rules (a non-trivial step in itself) and then pass them to the JDT compiler.

> 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.
> Alex.
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev