Just as an FYI to everyone, http://www.aqute.biz/Bnd/Bnd
has been replaced by http://bnd.bndtools.org/ You will notice: - much more detail - modernized explanations - source code reference where docs never existed - active updates - accepting pull requests for updates ( https://github.com/bndtools/bnd.manual) I spoke with Peter about the old site this past week. He's going to do something to point people at the new reference as soon as he finds some time. - Ray On Sat, Nov 15, 2014 at 7:59 AM, Benson Margulies <ben...@basistech.com> wrote: > On Sat, Nov 15, 2014 at 10:12 AM, Stuart McCulloch <mccu...@gmail.com> > wrote: > > > > 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. > > > Thanks! These instructions: > > <instructions> > > <Export-Package>!*,com.basistech.rosette.dm</Export-Package> > > <Embed-Dependency>adm-model;guava;inline=true</Embed-Dependency> > > <Private-Package>sun.misc,com.google.*</Private-Package> > <Embed-Transitive>true</Embed-Transitive> > </instructions> > > produced: > > Export-Package: com.basistech.rosette.dm;uses:="com.basistech.rosette,co > m.basistech.util";version="0.0.1" > Import-Package: com.basistech.rosette;version="[0.0,1)",com.basistech.ut > il;version="[0.0,1)",javax.annotation,sun.misc > > So far, so good. > > I think that a stumbling block for me is that all my actual code is in > a Maven dependency, none of it's local. Until I added > Embed-Transitive, even 'direct' dependencies kept creeping into the > import list. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
