On 22/07/07, Niclas Hedhman <[EMAIL PROTECTED]> 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 classes to add further metadata relating to version ranges and adds mandatory attributes. 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 side-effects) Cheers
Niclas
-- Cheers, Stuart
