Re: [equinox-dev] Good support for PDE in build systems anyone?

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

Niclas Hedhman wrote on 06/04/2006 11:52:33 PM:

> So, would making the Maven OSGi plugin generating the Manifest for
PDE make 
> any sense?? I mean that is pretty trivial...

Sure. You might want to merge with any existing manifest...

> Another interesting thing to note, would be that
one could probably create a 
> new life cycle phase in Maven when doing OSGi bundles, which just
after the 
> POM has been read, reads the MEAT-INF/Manifest.MF and parse it for
classpath 
> entries and what-else needed from there and adds it to the Maven model.
> Such approach would somewhat let the Manifest be the master, but I
> guess it is 
> somewhat fragile as Maven savvy people would never conceive that to
be a 
> master file.

We have been talking about this for some months now
and it makes alot of sense to me.  In the limit then the POM could
just contain the build time information and the manifest the dependency
info.  This is analogous to how PDE puts the build time in for in
build.properties.  I don't know how the maven osgi plugin works but
perhaps it can just be configured to either have all the dependency info
in it XML markup or in a manifest.

> Also, how does PDE know what classpath to use
for "unit testing" vs normal 
> runs?? I also suspect that the developer is responsible for knowing
the 
> transitive dependencies, e.g. hibernate.jar needs jta.jar (among others).
How 
> about projects within the PDE workspace? Does it figure out that Project
C 
> needs hibernate, therefor Project F that depends on Project C will
need it 
> too? And in that case, how would it know whether Project C only needs
> hibernate during testing, and therefor Project F should not include
it in its 
> classpath?

PDE's construction of the classpath for a given project
is entirely based on an OSGi state model.  That is, PDE takes all
the bundles selected from the "target", and those in the workspace,
resolves them using the same resolver used by the framework. This results
in a "state" which accurately and completely represents the wirings
as they will be a runtime.  From this PDE traverses the state from
the point of view of the project being built and creates the complete classpath
(including all transitive dependencies).  The generated classpath
includes filters which exclude packages from prereq bundles (i.e., JARs)
that are actualy not visible to the project.

This is vitally important when using import package.
 Consider a case where bundle B imports foo and bar with version ranges.
 The set of bundles available may include two bundles (C and D) which
export both foo and bar but with different versions.  It is possible
for B to be wired to C for foo and D for bar.  Since classpaths are
on JAR basis, either C or D comes first on B's compile time classpath.
 This means that B will see the wrong version of one or the other
at build time.  PDE addresses this by adding both C and D to B's classpath
but putting access filters on the entries to prevent B seeing things it
should not.  

This is possible because PDE has a complete view of
the dependency information.  Certainly Maven can (and should) be updated
to do something similar in the way it handles Import-Package.  Actually,
what do Maven/Ivy do today for Import-Package? 

> These are the main reasons why I like to stick
with Maven as the primary tool.

Enjoy.

Jeff