Hi Am 05.06.2013 um 13:19 schrieb Martin Lichtin:
Ok, understood. I followed thread http://mail-archives.apache.org/mod_mbox/karaf-user/201210.mbox/%[email protected]%3E in which JB explains where the "org.osgi.service.jdbc" package comes from. Is there another bundle offering it? I will search. Not an Aries Blueprint issue per se. One last comment about the compendium. It offers version 1.0.2: org.osgi.service.blueprint.container;uses:="org.osgi.service.blueprint.reflect,org.osgi.framework";version="1.0.2" whereas the Blueprint API bundle offers a lower version 1.0.1: org.osgi.service.blueprint.container;uses:="org.osgi.service.blueprint.reflect,org.osgi.framework";version="1.0.1" If the latter bundle would offer a higher version, wouldn't this solve the issue? Yes, but there should be a reason to have a higher version. Just setting the version number to a higher numeric value is not the correct thing to do, as you may assume. Anyway, just an idea. I will try to find a solution without the use of the compendium bundle. Martin PS: I wild guess, and as a last resort, a Require-Bundle could be used to solve the BlueprintContainer class-loading ambiguity (more than one bundle offering the same package). Well, Require-Bundle is probably not something that you want to consider using, even if it might solve your problem in the short run. Over time it will byte you. So, I suggest to just forget that Requre-Bundle exists at all. One reason for this is that Require-Bundle creates tight coupling, which is not what. Regards Felix On 05/06/2013 18:35, Felix Meschberger wrote: Hi Yes, the idea is always the same: don't deploy the compendium API bundle. This will break your deployment sooner or later. The compeniumd bundle exposes API versions which may not reflect the actual API versions provided and/or used in your setup. Regards Felix Am 05.06.2013 um 05:52 schrieb Martin Lichtin: Hi Ariès I am wondering what the preferred way is to avoid the "not compatible with this blueprint extender" issue. But two steps back first: The issue started popping up after using org.osgi.compendium/4.3.1 (as deemed appropriate for Karaf 2.3.1). (compendium bundle is needed because of the H2 bundle recently starting to require "org.osgi.service.jdbc"). -> both org.osgi.compendium/4.3.1 and org.apache.aries.blueprint.api/1.0.0 export the BlueprintContainer interface. When Aries scans a bundle for BP, it checks that the bundle classloader picks up the Aries BlueprintContainer class. If not, it spits out above mentioned "is not compatible" info message. So far, so good. However, I have some bundles that need "DynamicImport-Package=*". Their classloader unfortunately loads the BlueprintContainer interface from org.osgi.compendium. Any ideas how I can configure my bundle so it prefers the Aries bundle for loading "BlueprintContainer.class"? Martin
