You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Nick Baker <nb...@pentaho.com> on 2016/02/11 18:55:14 UTC
Strategies for wrapping dependencies
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
Re: Strategies for wrapping dependencies
Posted by Nick Baker <nb...@pentaho.com>.
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 <bc...@googlemail.com>>
Reply-To: "user@karaf.apache.org<ma...@karaf.apache.org>" <us...@karaf.apache.org>>
Date: Thursday, February 11, 2016 at 3:56 PM
To: "user@karaf.apache.org<ma...@karaf.apache.org>" <us...@karaf.apache.org>>
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 <nb...@pentaho.com>>:
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
Re: Strategies for wrapping dependencies
Posted by Achim Nierbeck <bc...@googlemail.com>.
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 <nb...@pentaho.com>:
>
>
> 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