You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Benson Margulies <be...@basistech.com> on 2014/11/15 15:30:39 UTC
dependencies
I'm new. I bet that this is all written up somewhere; if not, I will be
happy to write up a wiki page.
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>
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?
Re: dependencies
Posted by Raymond Auge <ra...@liferay.com>.
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 <be...@basistech.com>
wrote:
> On Sat, Nov 15, 2014 at 10:12 AM, Stuart McCulloch <mc...@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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect
*Liferay, Inc.* <http://www.liferay.com> (@Liferay)
Re: dependencies
Posted by Benson Margulies <be...@basistech.com>.
On Sat, Nov 15, 2014 at 10:12 AM, Stuart McCulloch <mc...@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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: dependencies
Posted by Stuart McCulloch <mc...@gmail.com>.
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.