On Dec 4, 2011, at 12:27 AM, David Jencks wrote: > I believe at the moment the blueprint api bundle is exporting > org.osgi.service.blueprint, and the core bundle is also exporting it at > version 1.0.0. (the all-in-one bundle is too, but I'm less worried about it) > > I think the relevant part of the spec is 121.13.5: > > 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. > > I think this means > > 1. the api bundle should not export this package > > 2. the core bundle should have a big uses clause. I'm not sure what should > be in the uses clause. All the exports from the core bundle? > > Obviously fixing this is trivial once we figure out what to do :-)
On the karaf list Guillaume asked why using the little bundles is better than the all-in-one bundle, since if you refresh the blueprint core bundle which exports org.osgi.service.blueprint you're going to force a refresh of all the "application" blueprint bundles that are using aries blueprint core. At the moment I don't have a good answer, so I wonder if it would be better to put the extender itself in a separate bundle (not expected to be refreshed) and thus allow the rest of core to be refreshed. I guess this would mean the core functionality would be exposed through a service the extender uses. (I'm not sure how it works today). thoughts? thanks david jencks > > thanks > david jencks >
