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 Sat, 21 Jul 2007 17:13:09 GMT
On 22/07/07, Niclas Hedhman <niclas@hedhman.org> 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
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

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

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
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,
> 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

> Niclas
> _______________________________________________
> general mailing list
> general@lists.ops4j.org
> http://lists.ops4j.org/mailman/listinfo/general

Cheers, Stuart

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