One reason is to avoid installing support for the blueprint cm namespace - the uber bundle always contains that. Another reason is to allow you to update blueprint core without having to refresh every blueprint application bundle. By leaving the API installed the applications can remain started, and their blueprint containers will be gracefully shut down, then brought up by the new core bundle.
Regards, Tim Ward ------------------- Apache Aries PMC member & Enterprise OSGi advocate Enterprise OSGi in Action (http://www.manning.com/cummins) ------------------- > Subject: Re: Blueprint org.osgi.service.blueprint export > From: [email protected] > Date: Sun, 4 Dec 2011 14:43:29 -0800 > To: [email protected] > > > 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 > > >
