On Saturday, 15 November 2014 at 14:30, Benson Margulies wrote: > I'm new. I bet that this is all written up somewhere; if not, I will be > happy to write up a wiki page. > >
Most questions should already be covered by these links (the last two are referenced from the first): http://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html http://felix.apache.org/site/apache-felix-bundle-plugin-faq.html http://www.aqute.biz/Bnd/Format Since the plugin basically acts like a wrapper around bnd (providing default instructions for maven projects, as well as translating maven conventions into bnd instructions) it’s often useful to read about how bnd works first: http://www.aqute.biz/Bnd/Bnd. Especially as bnd works differently to other packaging plugins by pulling classes/resources/jars into the bundle according to the given instructions rather than just taking the entire content of “target/classes”. > > I'm packaging up a few items as OSGi bundles, and I'm perplexed by how the > maven-bundle-plugin related Maven dependencies to OSGi dependencies. > > Here are some very simple instructions: > > <instructions> > <Embed-Dependency>*;scope=compile|runtime;inline=true</Embed-Dependency> > <Export-Package>com.basistech.rosette.dm</Export-Package> > </instructions> These instructions say to embed all direct dependencies that have compile or runtime scope by inlining them (ie. unpack them into the final bundle). Note that dependencies are just matched according to the specified filters, it doesn’t make any difference whether they’re already OSGi bundles or not. Transitive dependencies won’t be embedded because you didn’t add <Embed-Transitive>true</Embed-Transitive>. The instructions also say to pull in all classes/resources under the com.basistech.rosette.dm package from the build classpath and mark them as exported. The bundle plugin will also include any local classes/resources from the current project in the bundle unless you override this by specifying an explicit Private-Package. Once bnd has added the above classes/resources it will analyse their bytecode (and any blueprint XML) to find out what packages are referenced, what packages are contained in the bundle, and therefore what packages need to be imported from outside. > > The POM's dependency section lists two artifacts. One (a) is an OSGi > bundle built 'right next door', the other (b) isn't OSGI'd at all, its the > thing I'm trying to wrap. (b) in turn depends on Guava. My local copy of > Nexus is not configured at all for OBR. > > When I build, I end up with (a) embedded, the body of (b) embedded, and > Guava declared as a dependency! I suppose that i can get (b) disembedded by > making the Embed-Dependency more subtle, but how is a guava OSGi bundle > getting into the picture? This is what you told bnd to do via the bundle plugin - it embedded both a) and b) because they are direct dependencies that match the Embed-Dependency filter. Since b) depends on Guava and b)’s bytecode ends up embedded in the final bundle, bnd will detect that it needs Guava (but doesn’t contain it) and therefore add the necessary “com.google.common” packages to the Import-Package header. Unless you have a large number of dependencies and want to create an uber-bundle, I’d suggest explicitly listing the specific dependencies you want embedded using something like <Embed-Dependency>some-artifact|another-artifact;inline=true</Embed-Dependency> - otherwise you might end up embedding more than you expect.
