You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Aaron Zeckoski <aa...@vt.edu> on 2009/04/10 17:15:18 UTC
maven-bundle-plugin: how to control import/export-packages from
dependencies
I am having trouble getting my Import-Package down to a reasonable
size. It currently pulls in a huge number of things (based on bytecode
scanning from what I understand). I think there may be 3 things I am
doing wrong here but I cannot seem to find the answers so I am asking
here instead. I attached the pom and the generated manifest for
reference:
1) Somehow I am getting duplicates of my exported packages in my
imports. I am exporting this stuff (org.sakaiproject.entitybus.*)
For Example:
Import-Package: javax.crypto,javax.crypto.spec,javax.net,javax.net.ssl
,javax.xml.parsers,org.apache.avalon.framework.logger,org.apache.comm
ons.beanutils,org.apache.log,org.apache.log4j,org.osgi.framework;vers
ion="1.3",org.osgi.util.tracker;version="1.3",org.sakaiproject.entity
bus,org.sakaiproject.entitybus.access,org.sakaiproject.entitybus.coll
... (snip) ...
Embed-Transitive: true
Bnd-LastModified: 1239373356766
Export-Package: org.sakaiproject.entitybus.entityprovider.annotations,
org.sakaiproject.entitybus.entityprovider.capabilities;uses:="org.sak
aiproject.entitybus.entityprovider.extension,org.sakaiproject.entityb
us.entityprovider,org.sakaiproject.entitybus,org.sakaiproject.entityb
us.entityprovider.search,org.sakaiproject.entitybus.access",org.sakai
... (snip) ...
Here is the relelvant section of the pom:
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<instructions>
<Bundle-Activator>org.sakaiproject.eb.osgi.EBActivator</Bundle-Activator>
<Export-Package>!org.sakaiproject.entitybus.impl.*,!org.sakaiproject.entitybus.util.*,org.sakaiproject.entitybus.*</Export-Package>
<Embed-Dependency>*;scope=compile|runtime;inline=false</Embed-Dependency>
<Embed-Transitive>true</Embed-Transitive>
</instructions>
</configuration>
2) I am getting a bunch of javax.*, org.apache.*, and org.xml.*
dependencies in the import of the manifest. Most of these are because
I need httputils and the servlet api (which are the only actual
dependencies I have that are not my own stuff) but I am not sure why
the relelvant stuff is not being included since these are transitive
dependencies and I have embed-transitive set to true. I am hoping
someone has pulled in the servlet api or commons-httpclient before and
knows how to deal with this.
(see the attached pom/manifest)
3) Is there way to correctly handle the servlet stuff? I know about
http.service but I don't really want to pack the servlet api into my
bundle because that does not work, but removing it causes the bundle
to fail so I am guessing I need to somehow fix my dependencies in the
pom so that it correctly creates the imports. Using provided seems to
correct the build failure issue but then it fails to resolve at
runtime so I am stuck.
4) Is there a reference somewhere that explains how the changes in the
dependencies affect the import/export/private values in the manifest?
I figured out that excluding packages can keep them from ending up in
the import and priivate area but this only works if they are actual
transitive dependencies somewhere in the chain. For things which I am
not quite sure where they are coming from (like the org.xml.sax one) I
don't know how to control it. A RTFM with a link would be totally
great here.
Thanks for any help
-AZ
--
Aaron Zeckoski (aaronz@vt.edu)
Senior Research Engineer - CARET - Cambridge University
[http://bugs.sakaiproject.org/confluence/display/~aaronz/]
Sakai Fellow - [http://aaronz-sakai.blogspot.com/]
Re: maven-bundle-plugin: how to control import/export-packages from
dependencies
Posted by Aaron Zeckoski <aa...@vt.edu>.
After playing around a bit (the note about importing your exports
helped a ton) I have semi-resolved this by using lots of filtering in
the import and export statements:
<Export-Package>!org.sakaiproject.entitybus.impl.*,!org.sakaiproject.entitybus.util.*,org.sakaiproject.entitybus.*,org.sakaiproject.eb.osgi.util.*,org.apache.commons.logging,org.apache.log4j,</Export-Package>
<Embed-Dependency>*;scope=compile|runtime;inline=false</Embed-Dependency>
<Embed-Transitive>true</Embed-Transitive>
<!-- logging adds
!org.apache.log,!org.apache.avalon.*,!com.sun.*,!org.w3c.dom, -->
<Import-Package>!org.apache.commons.beanutils.*,!javax.*,!org.xml.*,!org.apache.log,!org.apache.avalon.*,!com.sun.*,!org.w3c.dom,org.apache.commons.logging,org.apache.log4j,*</Import-Package>
I'm not sure if this is correct or not but it seems to at least reduce
the imports down tot he ones I know I need. There is probably a better
option than simply marking these ignored (which is what it ends up
doing). I think optional may be better but I am not sure how to handle
that yet.
I have more questions about logging and servlets but I will put those
in a new thread.
I attached my pom so I hope this helps someone else.
-AZ
On Fri, Apr 10, 2009 at 4:59 PM, Stuart McCulloch <mc...@gmail.com> wrote:
> 2009/4/10 Aaron Zeckoski <aa...@vt.edu>
>
>> I am having trouble getting my Import-Package down to a reasonable
>> size. It currently pulls in a huge number of things (based on bytecode
>> scanning from what I understand). I think there may be 3 things I am
>> doing wrong here but I cannot seem to find the answers so I am asking
>> here instead. I attached the pom and the generated manifest for
>> reference:
>>
>
> it's very late over here so I'll keep my reply brief - others can fill in
> the details :)
>
> one thing to point out upfront - if your import list is big it's because you
> are either
> exporting a lot of packages (see below) or using a lot of packages from
> 'outside'
>
> so... breaking your code into smaller modules and reducing what you export
> would make it more manageable and make your imports much, much smaller
>
> the plugin is just being upfront, rather than hiding these issues away from
> you
>
> 1) Somehow I am getting duplicates of my exported packages in my
>> imports. I am exporting this stuff (org.sakaiproject.entitybus.*)
>
>
> this is by design:
>
>
> http://felix.apache.org/site/apache-felix-osgi-faq.html#ApacheFelixOSGiFAQ-Shouldabundleimportitsownexportedpackages%3F
>
> http://www.osgi.org/blog/2007/04/importance-of-exporting-nd-importing.html
>
> if you really want to turn this off, look here:
>
> http://aqute.biz/Code/Bnd#export-package
>
> or manually set your Import-Package (not really advisable)
>
> For Example:
>> Import-Package: javax.crypto,javax.crypto.spec,javax.net,javax.net.ssl
>> ,javax.xml.parsers,org.apache.avalon.framework.logger,org.apache.comm
>> ons.beanutils,org.apache.log,org.apache.log4j,org.osgi.framework;vers
>> ion="1.3",org.osgi.util.tracker;version="1.3",org.sakaiproject.entity
>> bus,org.sakaiproject.entitybus.access,org.sakaiproject.entitybus.coll
>> ... (snip) ...
>> Embed-Transitive: true
>> Bnd-LastModified: 1239373356766
>> Export-Package: org.sakaiproject.entitybus.entityprovider.annotations,
>> org.sakaiproject.entitybus.entityprovider.capabilities;uses:="org.sak
>> aiproject.entitybus.entityprovider.extension,org.sakaiproject.entityb
>> us.entityprovider,org.sakaiproject.entitybus,org.sakaiproject.entityb
>> us.entityprovider.search,org.sakaiproject.entitybus.access",org.sakai
>> ... (snip) ...
>>
>> Here is the relelvant section of the pom:
>> <groupId>org.apache.felix</groupId>
>> <artifactId>maven-bundle-plugin</artifactId>
>> <extensions>true</extensions>
>> <configuration>
>> <instructions>
>>
>> <Bundle-Activator>org.sakaiproject.eb.osgi.EBActivator</Bundle-Activator>
>>
>>
>> <Export-Package>!org.sakaiproject.entitybus.impl.*,!org.sakaiproject.entitybus.util.*,org.sakaiproject.entitybus.*</Export-Package>
>>
>> <Embed-Dependency>*;scope=compile|runtime;inline=false</Embed-Dependency>
>> <Embed-Transitive>true</Embed-Transitive>
>> </instructions>
>> </configuration>
>>
>> 2) I am getting a bunch of javax.*, org.apache.*, and org.xml.*
>> dependencies in the import of the manifest. Most of these are because
>> I need httputils and the servlet api (which are the only actual
>> dependencies I have that are not my own stuff) but I am not sure why
>> the relelvant stuff is not being included since these are transitive
>> dependencies and I have embed-transitive set to true. I am hoping
>> someone has pulled in the servlet api or commons-httpclient before and
>> knows how to deal with this.
>> (see the attached pom/manifest)
>>
>
> depends what version of the bundleplugin you're using, because until
> version 2.0.0 we weren't processing the dependency graph - but even
> then if your dependencies have optional/provided dependencies then
> these might not appear in the graph due to how the Maven resolver
> works (provided deps are not transitive)
>
>
> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
>
> and if they're not in the resolved graph provided by Maven then we
> won't know to embed them - optional dependencies (ie. where a pom
> depends optionally on various different logging impls) is so you can
> decide which logging impl you want to use
>
> if you use 2.0.0 you can do "mvn clean install -X" and you'll get all
> sorts of debug information about what the bundleplugin is doing
>
> also note some packages will come from the JVM runtime via the
> system bundle exports (like javax.* and org.xml.*) this is because
> only java.* packages are automatically exposed from the runtime
> - this is to allow javax.* packages to be replaced as necessary
>
> also do a "jar tvf" on your bundle to see what's being pulled in
> because if you're pulling in everything then it probably includes
> a lot of dependencies to javax packages that may not really be
> required at runtime (again there's no way for the bundleplugin
> to know this because Java doesn't have modularity built in!)
>
> in fact you may not need to embed all this stuff to begin with
> as there may be existing bundles you could install instead...
>
> http://www.springsource.com/repository/app/
>
> 3) Is there way to correctly handle the servlet stuff? I know about
>> http.service but I don't really want to pack the servlet api into my
>> bundle because that does not work, but removing it causes the bundle
>> to fail so I am guessing I need to somehow fix my dependencies in the
>> pom so that it correctly creates the imports. Using provided seems to
>> correct the build failure issue but then it fails to resolve at
>> runtime so I am stuck.
>>
>
> if you don't pack the servlet api in your bundle then you'll need
> to install a bundle that does provide it - or put the servlet jar on
> the main classpath and either expose it via the system bundle or
> bootdelegation
>
>
>> 4) Is there a reference somewhere that explains how the changes in the
>> dependencies affect the import/export/private values in the manifest?
>> I figured out that excluding packages can keep them from ending up in
>> the import and priivate area but this only works if they are actual
>> transitive dependencies somewhere in the chain. For things which I am
>> not quite sure where they are coming from (like the org.xml.sax one) I
>> don't know how to control it. A RTFM with a link would be totally
>> great here.
>>
>
> the main docs are:
>
> http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
> http://felix.apache.org/site/apache-felix-bundle-plugin-faq.html
> http://aqute.biz/Code/Bnd
>
> basically, the bundleplugin asks Maven for the resolved dependencies
> (either direct/transitive) and applies the given filter to decided what to
> embed - matching dependencies are embedded using Include-Resource
> instructions (see the Bnd docs), which you can see when you use the
> Maven -X option to turn on debugging
>
> the Bnd tool pulls in the content according to the given instructions and
> creates export/import headers based on what is exported, and what is
> referenced (but not contained) inside the bundle.
>
> actually the underlying logic is rather mundane - it just exposes how
> tangled existing libraries and applications are, which is why you end
> up with large manifests packed with all sorts of exports and imports
>
> HTH - I'm sure others will add more and hopefully check your pom ;)
>
> Thanks for any help
>> -AZ
>>
>> --
>> Aaron Zeckoski (aaronz@vt.edu)
>> Senior Research Engineer - CARET - Cambridge University
>> [http://bugs.sakaiproject.org/confluence/display/~aaronz/<http://bugs.sakaiproject.org/confluence/display/%7Eaaronz/>
>> ]
>> Sakai Fellow - [http://aaronz-sakai.blogspot.com/]
>>
>
> --
> Cheers, Stuart
>
--
Aaron Zeckoski (aaronz@vt.edu)
Senior Research Engineer - CARET - Cambridge University
[http://bugs.sakaiproject.org/confluence/display/~aaronz/]
Sakai Fellow - [http://aaronz-sakai.blogspot.com/]
Re: maven-bundle-plugin: how to control import/export-packages from
dependencies
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/4/10 Stuart McCulloch <mc...@gmail.com>
> 2009/4/10 Aaron Zeckoski <aa...@vt.edu>
>
>> I am having trouble getting my Import-Package down to a reasonable
>> size. It currently pulls in a huge number of things (based on bytecode
>> scanning from what I understand). I think there may be 3 things I am
>> doing wrong here but I cannot seem to find the answers so I am asking
>> here instead. I attached the pom and the generated manifest for
>> reference:
>>
>
quick (shameless) plug...
chapter 6 of the book I'm writing with Richard and Karl covers moving JARs
and complete applications to OSGi and is now available through Manning's
early access program:
http://manning.com/hall/
unfortunately you do have to pay for MEAP, whereas advice here is free ;)
--
Cheers, Stuart
Re: maven-bundle-plugin: how to control import/export-packages from
dependencies
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/4/10 Aaron Zeckoski <aa...@vt.edu>
> I am having trouble getting my Import-Package down to a reasonable
> size. It currently pulls in a huge number of things (based on bytecode
> scanning from what I understand). I think there may be 3 things I am
> doing wrong here but I cannot seem to find the answers so I am asking
> here instead. I attached the pom and the generated manifest for
> reference:
>
it's very late over here so I'll keep my reply brief - others can fill in
the details :)
one thing to point out upfront - if your import list is big it's because you
are either
exporting a lot of packages (see below) or using a lot of packages from
'outside'
so... breaking your code into smaller modules and reducing what you export
would make it more manageable and make your imports much, much smaller
the plugin is just being upfront, rather than hiding these issues away from
you
1) Somehow I am getting duplicates of my exported packages in my
> imports. I am exporting this stuff (org.sakaiproject.entitybus.*)
this is by design:
http://felix.apache.org/site/apache-felix-osgi-faq.html#ApacheFelixOSGiFAQ-Shouldabundleimportitsownexportedpackages%3F
http://www.osgi.org/blog/2007/04/importance-of-exporting-nd-importing.html
if you really want to turn this off, look here:
http://aqute.biz/Code/Bnd#export-package
or manually set your Import-Package (not really advisable)
For Example:
> Import-Package: javax.crypto,javax.crypto.spec,javax.net,javax.net.ssl
> ,javax.xml.parsers,org.apache.avalon.framework.logger,org.apache.comm
> ons.beanutils,org.apache.log,org.apache.log4j,org.osgi.framework;vers
> ion="1.3",org.osgi.util.tracker;version="1.3",org.sakaiproject.entity
> bus,org.sakaiproject.entitybus.access,org.sakaiproject.entitybus.coll
> ... (snip) ...
> Embed-Transitive: true
> Bnd-LastModified: 1239373356766
> Export-Package: org.sakaiproject.entitybus.entityprovider.annotations,
> org.sakaiproject.entitybus.entityprovider.capabilities;uses:="org.sak
> aiproject.entitybus.entityprovider.extension,org.sakaiproject.entityb
> us.entityprovider,org.sakaiproject.entitybus,org.sakaiproject.entityb
> us.entityprovider.search,org.sakaiproject.entitybus.access",org.sakai
> ... (snip) ...
>
> Here is the relelvant section of the pom:
> <groupId>org.apache.felix</groupId>
> <artifactId>maven-bundle-plugin</artifactId>
> <extensions>true</extensions>
> <configuration>
> <instructions>
>
> <Bundle-Activator>org.sakaiproject.eb.osgi.EBActivator</Bundle-Activator>
>
>
> <Export-Package>!org.sakaiproject.entitybus.impl.*,!org.sakaiproject.entitybus.util.*,org.sakaiproject.entitybus.*</Export-Package>
>
> <Embed-Dependency>*;scope=compile|runtime;inline=false</Embed-Dependency>
> <Embed-Transitive>true</Embed-Transitive>
> </instructions>
> </configuration>
>
> 2) I am getting a bunch of javax.*, org.apache.*, and org.xml.*
> dependencies in the import of the manifest. Most of these are because
> I need httputils and the servlet api (which are the only actual
> dependencies I have that are not my own stuff) but I am not sure why
> the relelvant stuff is not being included since these are transitive
> dependencies and I have embed-transitive set to true. I am hoping
> someone has pulled in the servlet api or commons-httpclient before and
> knows how to deal with this.
> (see the attached pom/manifest)
>
depends what version of the bundleplugin you're using, because until
version 2.0.0 we weren't processing the dependency graph - but even
then if your dependencies have optional/provided dependencies then
these might not appear in the graph due to how the Maven resolver
works (provided deps are not transitive)
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
and if they're not in the resolved graph provided by Maven then we
won't know to embed them - optional dependencies (ie. where a pom
depends optionally on various different logging impls) is so you can
decide which logging impl you want to use
if you use 2.0.0 you can do "mvn clean install -X" and you'll get all
sorts of debug information about what the bundleplugin is doing
also note some packages will come from the JVM runtime via the
system bundle exports (like javax.* and org.xml.*) this is because
only java.* packages are automatically exposed from the runtime
- this is to allow javax.* packages to be replaced as necessary
also do a "jar tvf" on your bundle to see what's being pulled in
because if you're pulling in everything then it probably includes
a lot of dependencies to javax packages that may not really be
required at runtime (again there's no way for the bundleplugin
to know this because Java doesn't have modularity built in!)
in fact you may not need to embed all this stuff to begin with
as there may be existing bundles you could install instead...
http://www.springsource.com/repository/app/
3) Is there way to correctly handle the servlet stuff? I know about
> http.service but I don't really want to pack the servlet api into my
> bundle because that does not work, but removing it causes the bundle
> to fail so I am guessing I need to somehow fix my dependencies in the
> pom so that it correctly creates the imports. Using provided seems to
> correct the build failure issue but then it fails to resolve at
> runtime so I am stuck.
>
if you don't pack the servlet api in your bundle then you'll need
to install a bundle that does provide it - or put the servlet jar on
the main classpath and either expose it via the system bundle or
bootdelegation
> 4) Is there a reference somewhere that explains how the changes in the
> dependencies affect the import/export/private values in the manifest?
> I figured out that excluding packages can keep them from ending up in
> the import and priivate area but this only works if they are actual
> transitive dependencies somewhere in the chain. For things which I am
> not quite sure where they are coming from (like the org.xml.sax one) I
> don't know how to control it. A RTFM with a link would be totally
> great here.
>
the main docs are:
http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
http://felix.apache.org/site/apache-felix-bundle-plugin-faq.html
http://aqute.biz/Code/Bnd
basically, the bundleplugin asks Maven for the resolved dependencies
(either direct/transitive) and applies the given filter to decided what to
embed - matching dependencies are embedded using Include-Resource
instructions (see the Bnd docs), which you can see when you use the
Maven -X option to turn on debugging
the Bnd tool pulls in the content according to the given instructions and
creates export/import headers based on what is exported, and what is
referenced (but not contained) inside the bundle.
actually the underlying logic is rather mundane - it just exposes how
tangled existing libraries and applications are, which is why you end
up with large manifests packed with all sorts of exports and imports
HTH - I'm sure others will add more and hopefully check your pom ;)
Thanks for any help
> -AZ
>
> --
> Aaron Zeckoski (aaronz@vt.edu)
> Senior Research Engineer - CARET - Cambridge University
> [http://bugs.sakaiproject.org/confluence/display/~aaronz/<http://bugs.sakaiproject.org/confluence/display/%7Eaaronz/>
> ]
> Sakai Fellow - [http://aaronz-sakai.blogspot.com/]
>
--
Cheers, Stuart