You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by mv...@comcast.net on 2010/08/25 19:40:19 UTC

Including non-bundle .jars in issue


Gents, 



Per Justin's suggestion, I have removed all of the bundles from my <Export-Package> directive in the maven-bundle-plugin.  



However, our developers use some packages which do not have bundle implementations.  Putting these packages along with thier transitive dependencies (dependencies on other dependencies not used in the original bundle) in the <Export-Package> area would appear to be the appropriate way of handling these.  Unfortunately, the result is that the maven-bundle-plugin gives a "Superfluous Package" warning, listing the transitive dependencies after the warning.  Upon installing the bundle into Karaf, "Unresolved Constraint Violation" warnings occur, identifying the transitive dependencies as unresolved. 



Again, I am only putting the packages which have no bundle implementations, and therefore don't export anything into the OSGi framework. Two possible ways around this could be: 

1) Make a bundle out of them using the BND command line utility, or 

2) Include the non-bundled .jar files in the <Export> directive. 



The first solution is unacceptable because it would result in two .jar files with the same name and version, but different implementations (one bundled, the other not) floating around, which makes configuration management a headache. The second approach as I identified above doesn't work. 



So, now that I think I'm doing things the OSGi-way, how can I overcome the issue of development using non-bundled packages with transitive dependencies (especially on other non-bundled packages)? 



v/r, 



Mike Van 





Re: Including non-bundle .jars in issue

Posted by Justin Edelson <ju...@gmail.com>.
If I understand this correctly, you want to create an OSGi bundle which:

1) Contains some of your code
2) Contains some code from a 3rd party library
3) Exports some of your packages
4) Exports some packages from the 3rd party library

Best thing I can do it to point you to a working example:
http://svn.apache.org/repos/asf/sling/trunk/bundles/jcr/jackrabbit-server/pom.xml

Basically, you should do the following:
* Use <Embed-Dependency>/<Embed-Transitive> to add the dependencies to
the bundle
* Use <Import-Package> to tune the imports
* Use <Export-Package> to declare the exported packages

All that said, it would also be good to push your library providers to
give you OSGi bundles instead of having to jump through these hoops. If
they're open source projects, submit patches to add the right manifest
headers. If they're closed source projects, yell at the vendor.

Justin


On 8/25/10 1:40 PM, mvangeertruy@comcast.net wrote:
> 
> 
> Gents, 
> 
> 
> 
> Per Justin's suggestion, I have removed all of the bundles from my <Export-Package> directive in the maven-bundle-plugin.  
> 
> 
> 
> However, our developers use some packages which do not have bundle implementations.  Putting these packages along with thier transitive dependencies (dependencies on other dependencies not used in the original bundle) in the <Export-Package> area would appear to be the appropriate way of handling these.  Unfortunately, the result is that the maven-bundle-plugin gives a "Superfluous Package" warning, listing the transitive dependencies after the warning.  Upon installing the bundle into Karaf, "Unresolved Constraint Violation" warnings occur, identifying the transitive dependencies as unresolved. 
> 
> 
> 
> Again, I am only putting the packages which have no bundle implementations, and therefore don't export anything into the OSGi framework. Two possible ways around this could be: 
> 
> 1) Make a bundle out of them using the BND command line utility, or 
> 
> 2) Include the non-bundled .jar files in the <Export> directive. 
> 
> 
> 
> The first solution is unacceptable because it would result in two .jar files with the same name and version, but different implementations (one bundled, the other not) floating around, which makes configuration management a headache. The second approach as I identified above doesn't work. 
> 
> 
> 
> So, now that I think I'm doing things the OSGi-way, how can I overcome the issue of development using non-bundled packages with transitive dependencies (especially on other non-bundled packages)? 
> 
> 
> 
> v/r, 
> 
> 
> 
> Mike Van 
> 
> 
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org