[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Good support for PDE in build systems anyone?

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.