so... 1. That is explicitly contrary to the spec which says the _extender_ bundle should export org.osgi.service.blueprint, not the api bundle.
2. As Guillaume has been telling me for a long time now, having the api bundle export this package completely subverts the purpose of having this package, of preventing two extenders from recognizing the same blueprint (using) bundle. The only way I can see to get the advantage of being able to update the blueprint-core bundle without reloading all the client blueprint bundle classes would be to put the extender code in a separate bundle from blueprint-core and including enough aries api in the extender bundle so the (currently missing) uses clauses won't always force reloading client blueprint bundles. IIUC refreshing blueprint core will still end up destroying and recreating all the blueprint containers. I also still want to know more about what the uses clause on the org.osgi.service.blueprint export should look like. thanks david jencks On Dec 5, 2011, at 5:50 AM, Timothy Ward wrote: > > 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 >>> >> >
