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 <mccu...@gmail.com> wrote:
> 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
>
--
Aaron Zeckoski (aar...@vt.edu)
Senior Research Engineer - CARET - Cambridge University
[http://bugs.sakaiproject.org/confluence/display/~aaronz/]
Sakai Fellow - [http://aaronz-sakai.blogspot.com/]
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";>
<modelVersion>4.0.0</modelVersion>
<name>EntityBroker OSGi Services</name>
<groupId>org.sakaiproject.osgi.eb</groupId>
<artifactId>eb-services</artifactId>
<packaging>bundle</packaging>
<parent>
<groupId>org.sakaiproject.osgi</groupId>
<artifactId>eb</artifactId>
<version>0.9-SNAPSHOT</version><!--eb-osgi.version-->
</parent>
<dependencies>
<!-- internal deps -->
<dependency>
<groupId>org.sakaiproject.entitybus</groupId>
<artifactId>entitybus-api</artifactId>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.sakaiproject.entitybus</groupId>
<artifactId>entitybus-impl</artifactId>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.sakaiproject.entitybus</groupId>
<artifactId>entitybus-utils</artifactId>
<scope>compile</scope>
</dependency>
<!-- Common -->
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<scope>compile</scope>
</dependency>
<!-- OSGi -->
<dependency>
<groupId>org.osgi</groupId>
<artifactId>osgi_R4_core</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.osgi</groupId>
<artifactId>osgi_R4_compendium</artifactId>
<scope>provided</scope>
</dependency>
<!-- logging -->
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<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.*,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>
</instructions>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<inherited>true</inherited>
<configuration>
<useFile>false</useFile>
<redirectTestOutputToFile>false</redirectTestOutputToFile>
<trimStackTrace>false</trimStackTrace>
</configuration>
</plugin>
</plugins>
</build>
</project>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
