Re: [equinox-dev] Integrating with an external build system (Ant, Maven,

[Andrew Niefer <aniefer@xxxxxxxxxx>]

Some comments inline.
-Andrew

"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