That won't work are blueprint bundles are supposed to import the org.osgi.service.blueprint package which is exported by the extender implementation. My concern is about splitting the api from the core which could cause a second extender to wire against the same api, leading to the inability to use the class-space to split the blueprint bundles between the extenders (and avoid multiple extenders to extend the same bundle).
On Mon, Dec 5, 2011 at 14:50, Timothy Ward <[email protected]> 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 >> > >> > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
