On 22/07/07, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
On Saturday 21 July 2007 21:12, Stuart McCulloch wrote: > the classpath passed to BND is fine in that the service target/classes > folder appears > before the dependencies (so the right activator is found first). Please explain to me why BND need to look at dependencies that are part of other bundles, that will get imported?
( this is all MHO... ps. copying discussion to felix, as others may be interested ) for the moment, ignore the maven plugin - the basic BND tool takes a vanilla classpath and a set of instructions, and generates a bundle + metadata. This means you can take the *same* classpath (ie. project) and split it into several bundles by using different sets of instructions. the instructions given to BND effectively tell it which part of the classpath comprises the bundle code, and which part the dependencies (ie. imports). This approach makes it very flexible, but can be confusing - eg. if you use Export-Package:* you'd end up with all the classes in the bundle (even the dependency classes!) btw, apart from the putResource issue, I don't see any problem with basic BND processing. the use of declarative instructions (ie. import / export / private / ignore...) makes it easy to integrate with various build systems, some of which only provide a plain classpath the tricky issue is wrt. the maven-bundle-plugin... at the moment it simply passes the maven compilation classpath (ie. the project classpath) onto the BND tool, in much the same way as the BND ant task does. it provides some basic default instructions that attempt to divide up the project into core bundle classes (ie. package name based on groupId+artifactId) and dependencies, but it isn't perfect as it's next to impossible to say which classes are public and which private. the current goal is to do as little as possible, while making it easy as possible for maven projects to migrate to OSGi (hence the defaults are tuned according to maven defaults) it would be possible to do more analysis in the bundle plugin to provide better defaults for missing instructions (obviously we'd always like to allow people complete control over BND, and that means passing the complete classpath) however, the danger of adding more heuristics is that it can confuse people even more and make migration from maven more difficult - whereas if you used BND instructions you could move to ant almost immediately. to sum up: imho passing a single classpath is OK, perhaps we could do better wrt. default BND instructions As I see it, the bundle plugin must first establish what are the bundle
classes, before trying to analyze what is required to be imported. So, IMHO, the classpath passed to BND must exclude <scope>provided</scope> and <scope>test</scope>, one way or the other.
test scope is excluded - only compile, system and provided scopes are on the classpath passed to BND Cheers
Niclas _______________________________________________ general mailing list [EMAIL PROTECTED] http://lists.ops4j.org/mailman/listinfo/general
-- Cheers, Stuart
