When I write an application in C that will run on a POSIX system, I import header files (APIs) into my code with #include; I don't import the implementation from glibc or whatever. If I or anyone else wants to run the code, they need to have the libraries installed but they don't need the headers. I have worked this way for more than 30 years because it is the only sane way to program in C, but for some reason Java developers still seem to find it a strange concept.
Compile against the interface. Run against an implementation. You know it makes sense. > Personally, I implement my own BundleInfo to represent bundles installed > in a distributed system. > >> On 29 Feb 2016, at 17:57, David Jencks <[email protected]> wrote: >> >> Sure, but I canât imagine any such use case. I can imagine using the >> little bundles at compile time to make sure you know which specs you >> depend on, but Iâm mystified how this could be useful at runtime. >> >> david jencks >> >>> On Feb 29, 2016, at 9:51 AM, Daniel McGreal <[email protected]> >>> wrote: >>> >>> I think he means (which is actually aligned with my use case) that I >>> can use the classes from the spec this way, when I donât need an >>> implementation. >>> >>>> On 29 Feb 2016, at 17:49, David Jencks <[email protected]> >>>> wrote: >>>> >>>> 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 >>>>>> >>>> >>> >> > >
