The uses should list the blueprint API packages. On 5 December 2011 15:24, David Jencks <[email protected]> wrote:
> 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 > >>> > >> > > > > -- Alasdair Nottingham [email protected]
