Thanks Achim, Ideally we would like to continue using the standard Maven GAV until Feature.xml creation time. This was we benefit from the dependency management of Maven, transitive dependencies, conflict resolution, etc.
The scenario which really troubles me is pointing our projects to a wrapped version of a dependency then having the standard non-bundle version come in transitively from somewhere else. I guess I’ll think about it more, but seems like we might have to build some special tooling to help this. I’ve got the following in mind: 1. Bind custom plugin to “verify” phase 2. Build Feature.xml based on plain maven dependencies, some bundles, some plain jars 3. Analyze resulting feature to identify “wrap:” bundles 4. Run BND on plain jars and deploy as new GAV (org.pentaho.[GROUP]) 5. Re-write feature.xml to point to new wrapped versions 6. Deploy feature.xml If we do go this route I’ll be sure to let everyone know in case the plugin is useful to others. -Nick From: Achim Nierbeck <[email protected]<mailto:[email protected]>> Reply-To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Thursday, February 11, 2016 at 3:56 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: Strategies for wrapping dependencies Hi Nick, afaik there is no "easy" path of handling this. Strategies are most likely the ones used by either ServiceMix or the Pax Tipi project [1] or if you have "good" connections to the originators of such libraries maybe convince those of providing osgi ready bundles. regards, Achim [1] - https://github.com/ops4j/org.ops4j.pax.tipi 2016-02-11 18:55 GMT+01:00 Nick Baker <[email protected]<mailto:[email protected]>>: Hey Everyone, We’re presently embedding Karaf in other applications which contain an large amount of existing functionality comprising some 350 jars. Some of those are imported into the OSGI system today with system.packages.extras, but most remain unavailable to OSGI. I’m in the process of investigating an architectural “flip” in which what is today outside of OSGI will be moved inside as a series of features. Karaf would then be the main application. So far I’m making good progress. However, the resulting feature definitions contain hundreds of wrapped bundle entries as the libraries aren’t OSGI bundles. The overhead in wrapping these upon startup of a new instance is enormous! My options as I see it are: 1. Create some wrapper bundles replacing some of the features which utiliizes Bundle-Classpath: to embed dependent libraries and atomize functionality. Downside being potential duplication of libraries and ClassCastExceptions if those leak out of the bundles. 2. Run BND on these libraries and check them into our Maven repository under a different GAV. This is the route the Springsource and Servicemix teams went. My question to you all is have any of you come up with an automated way of handling this? What strategies and advice can you give? Thanks, Nick -- Apache Member Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead blog <http://notizblog.nierbeck.de/> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> Software Architect / Project Manager / Scrum Master
