felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <brett.por...@gmail.com>
Subject Re: Mavenization
Date Sun, 28 Aug 2005 03:01:12 GMT
On 8/28/05, Jeff McAffer <Jeff_McAffer@ca.ibm.com> wrote:
> In general I think this is going to be a challenge.  For example, in OSGi
> Require-Bundle (and other places) you can specify version ranges and other
> directives/attributes.  

Likewise in Maven 2. As luck would have it, it seems we both used set
notation so it is going to be very familiar and easy to map. It'd be
great to get a look at the details of how this is handled (how
ordering of versions is defined, how conflicts are managed) so that we
can ensure they are as close as possible, or at least that there are
ways to do everything in both.

> OSGi developers understand these and likely want
> to express their dependencies in those terms.  Seems that with the Maven
> approach developers have to craft POM files using a syntax that is
> unfamiliar and may not match the capabilities of the underlying (to be
> generated) metadata.  Also, as the world bundlizes, there will be many
> bundles with manifest.mf data.  Who is going to write the POM files?  Is
> there a way of generating POM data from OSGi manifest.mf data.

It would certainly be possible as a starting point. That should be
enough to deploy to the repository and have the dependency mechanism
work. For those building with Maven, they will maintain the POM and
generate the OSGi data.

It should be understood that Maven is no longer a Java-centric tool
and aims to do more than just build jars and manage dependencies.

> FWIW, the Eclipse approach is to supplement the manifest.mf with
> build-specific metadata (build.properties) that maps development time
> structures onto runtime structures.  PDE Build (our builder) then uses
> this and generates build scripts (Ant in our case) and then run them to do
> a build.  Perhaps one approach is to generate POM data instead?

That sounds like the right approach. From flicking through
build.properties that I've seen so far, there are compartive fields in
the POM for these.

> I'll have to read up on the scope stuff.  More generally though I am
> intrigued by Maven resolving the dependencies.  How does it know about the
> OSGi dependency model?  For example, Import-Package and Fragments.  The
> resolution of those dependencies is really quite complex.

It doesn't right now. I don't know how Import-Package and Fragment
work exactly (some digging around only led me to basic tutorials, I
probably need to have a look at the specification). I'm still learning

If these dependencies need to be resolved at build time, I have some
ideas about how it could be handled, but I'd need to learn more before
I think more about it, but...

> Again FWIW, PDE uses the actual OSGi resolver to determine the
> compile-time classpath based on the available bundles.  In this way the
> compile time setup looks exactly like the runtime setup.

We can plug in other resolvers, so this might be an option too.

> Question:  How well do Maven's dependency management algorithms scale? For
> example, what are typical repository sizes and dependency depths or graph
> sizes?  This has bearing here as some people build systems of several
> thousand bundles.

I don't see any limitations on the scale as long as the data and
versioning is set up correctly.

> Great.  I posted a starter topic there for Eclipse/PDE specific
> discussion.

I'll introduce myself. Thanks for the information.


View raw message