On May 7, 2013, at 11:44 AM, David Jencks <[email protected]> wrote:
> 121.13.5 > Type Compatibility > > Two bundles are type compatible for a given class if they both load the same > class object, or if either bundle cannot load the given class. > > To mitigate type incompatibility problems, a Blueprint extender must export > the org.osgi.service.blueprint package. In the uses: directive, it should > list any packages of classes that can be shared between the Blueprint > extender and the Blueprint bundle. Blueprint bundles should import this > package. > > confuses a lot of people :-) Well, Gemini doesn't seem to export it anywhere (at least in Virgo). Thus, bundles that import it cannot deploy into Virgo. :-( Dan > > david jencks > > On May 7, 2013, at 8:37 AM, Daniel Kulp <[email protected]> wrote: > >> >> Can anyone tell me why blueprint-core is exporting an >> org.osgi.service.blueprint package? First off, I don't think it should be >> exporting any org.osgi packages at all as those should be in the api bundle. >> Second, that package isn't even part of the spec. There should be >> blueprint/container and blu[eprint/reflect (both from the api bundle). >> >> Anyway, it's causing issues cause if I have blueprint-core on the classpath >> (to create namespace handlers), the bundle-plugin is adding an import to >> org.osgi.service.blueprint which doesn't exist if using Gemini. >> >> I'd like to remove it from the exports, but I have a feeling that will >> trigger a "major version" bump. :-( >> >> -- >> Daniel Kulp >> [email protected] - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> > -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
