2009/4/10 Aaron Zeckoski <aar...@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 (aar...@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
