As far as I’m concerned, these little bundles are there to make it easier for implementers of a particular spec to include that spec’s api in their implementation bundle. It doesn’t do you any good to include the api without an implementation at runtime. Thus, I think the quote below is highly misleading.
david jencks > On Feb 29, 2016, at 9:20 AM, Markus Rathgeb <[email protected]> wrote: > > FYI > > "But what if you want to use the APIs at runtime? To support using the > APIs at runtime, OSGi has now made the companion code for individual > specifications available as individual companion code bundles." > http://blog.osgi.org/2015/08/more-jars-on-maven-central-and-jcenter.html > > 2016-02-29 8:40 GMT+01:00 Achim Nierbeck <[email protected]>: >> Hi >> >> it's a bad practice to provide the compendium or core osgi bundles, as those >> contain far more packages then required. >> Usually the services implementing those apis should provide the implemented >> services. As can be seen for eventadmin, >> configuration admin service and the http service in karaf. >> >> regards, Achim >> >> >> 2016-02-28 22:15 GMT+01:00 Daniel McGreal <[email protected]>: >>> >>> Hi Karaf users! >>> >>> Installing the Compendium in a feature, e.g. with the following primitive >>> example, restarts the console, because dependent bundles refresh to wire >>> against it. >>> >>> <?xml version="1.0" encoding="UTF-8" standalone="yes"?> >>> <features xmlns="http://karaf.apache.org/xmlns/features/v1.3.0"; >>> name="cmpn"> >>> <feature name="cmpn" description="cmpn" >>> version="2.5.0.BUILD-SNAPSHOT"> >>> <bundle>mvn:org.osgi/org.osgi.compendium/5.0.0</bundle> >>> </feature> >>> </features> >>> >>> This is causing me some problems, for example, after the shell restart >>> feature:(un)install commands result in an NPE. >>> >>> java.lang.NullPointerException >>> at >>> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:216)[9:org.apache.karaf.features.core:4.0.4] >>> at >>> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:263)[9:org.apache.karaf.features.core:4.0.4] >>> at >>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1089)[9:org.apache.karaf.features.core:4.0.4] >>> at >>> org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:985)[9:org.apache.karaf.features.core:4.0.4] >>> at >>> java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_60] >>> at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_60] >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_60] >>> at java.lang.Thread.run(Thread.java:745)[:1.8.0_60] >>> >>> Is there a way to prevent this from happening? >>> >>> Best, Dan. >> >> >> >> >> -- >> >> 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 >>
