Well, the ticket does still exist. But it is not "welcomed" "OPS4J artifacts never include org.osgi.* sources. Please revert."
Benjamin On 03.10.2014 18:47, Jean-Baptiste Onofré wrote: > Hi Benjamin, > > We had problem with org.osgi.service.jdbc in the past because, > depending of the OSGi version, the package moved. > > Previously, org.osgi.service.jdbc was in osgi-compendium, now it moved > to osgi-enterprise. > > I would create the Jira at OPS4j as it could be exported there. > > Regards > JB > > On 10/03/2014 06:35 PM, Benjamin Graf wrote: >> Well, I need org.osgi.service.jdbc for pax-jdbc because I was pleased to >> revert adding it to pax-jdbc itself. >> (https://ops4j1.jira.com/browse/PAXJDBC-37) Actually my patch for karaf >> jdbc pooling is not working anymore :( >> >> By the way the pax-cdi karaf feature is using enterprise jar as well. >> >> Best >> Benjamin >> >> On 03.10.2014 11:18, Guillaume Nodet wrote: >>> Definitely, the compendium and enterprise jars should never be >>> deployed. >>> Usually, each implementation of it comes with its own copy of the api, >>> and that's quite fine imho. >>> Which package do you need ? >>> >>> 2014-10-03 10:54 GMT+02:00 Benjamin Graf <[email protected] >>> <mailto:[email protected]>>: >>> >>> Hi, >>> >>> I'm actually struggling how to use the API from the >>> org.osgi.enterprise >>> bundle. I actually know that deploying via felix fileinstall >>> fails and >>> causes karaf dying (KARAF-2006). Installing via feature or install >>> command is successful. But in my opinion it's not a good >>> solution to >>> deploy a bundle which in some circumstances is causing issues and >>> by the >>> way do I ever really need the whole set of APIs? Mostly not. And of >>> cause if using feature files you have to face to version question >>> to use >>> (4.2/4.3/4.3.1/5.0/...) The answer... it depends! >>> >>> I think there is a bunch of solutions. >>> >>> - Add bundle into libs folder and import specific packages via >>> properties file. But this solution is quite hard coded, bad to >>> maintain >>> and doesn't allow dynamic installation via features. >>> - Build separate API bundle which only does include needed API >>> (split >>> enterprise bundle to its defined services). This solution is >>> reimplementation official API twice. >>> - ... >>> >>> Maybe anyone knows the panacea. :-) >>> >>> Best >>> Benjamin >>> >>> >> >
signature.asc
Description: OpenPGP digital signature
