felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stuart McCulloch" <stuart.mccull...@jayway.net>
Subject Re: Maven Bundle Plugin
Date Sun, 22 Jul 2007 02:50:05 GMT
On 22/07/07, Niclas Hedhman <niclas@hedhman.org> wrote:
> On Sunday 22 July 2007 01:13, Stuart McCulloch wrote:
> > to sum up:
> >
> > imho passing a single classpath is OK, perhaps we could do better wrt.
> > default BND instructions
> I disagree. BND needs to understand which jar files are internal to THIS
> bundle and what are provided bundles, otherwise it can never get it right.
> Example;
> packageA.ClassA uses packageB.ClassB
> packageB.ClassB uses packageC.ClassC
> packageA is in JarA
> packageB is in JarB
> packageC is in JarC
> AFAICT, the R4 spec does not prevent me to put a bundle jar into another
> bundle as an ordinary Jar file, although the jars internal to that bundle
> won't be reachable, but that could be Ok in some cases.
> Now, how is BND going to determine if
> Import-Package: packageB
> or
> Import-Package: packageC

that's why BND takes a classpath *and* a set of instructions

these instructions provide a more granular way to define the
contents of a bundle, because they list packages rather than
dividing by jars.

is the correct one? In fact, just by taking the classpath, without knowing
> the
> jar files at all, BND is definately lost, as it wouldn't know when to stop
> traversing the class network.
> AND, if the BND is robbed of the "jarB" in the above example, it knows
> "Aha,
> packageB is not available, therefor it needs to be imported.". That sounds
> like a simple solution (although there may be catchas I can't see right
> now).

check out the augmentImports method - it uses details from the imported
to add further metadata relating to version ranges and adds mandatory

So, now, again, why should BND be given the "provided" scope?? And not only
> the "compile" scope?

1) consistency - this is the expected behaviour compared to other BND
plugins, and what I would expect to see

2) flexibility - I may want to take a package from a provided dependency and
include it in my bundle (I can't see any reason why this should be
disallowed - and changing the dependency to compiled could have unforseen

> Niclas

Cheers, Stuart

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message