If we were going to do this then I'd suggest removing the blueprint: namespace from the uber bundle, and making it just a "JNDI spec" bundle.
Tim Ward ------------------- Apache Aries PMC member & Enterprise OSGi advocate Enterprise OSGi in Action (http://www.manning.com/cummins) ------------------- > From: [email protected] > Date: Mon, 16 Jan 2012 09:57:16 +0000 > Subject: Re: Aries JNDI dependencies > To: [email protected] > > Hi Tim, > > I think we need to find the balance between 'super modular' and 'user > friendly'. To me, the jndi-uber bundle seems like the right level of > modularity for many cases. It provides the JNDI functionality in a > single bundle with a number of dependencies. > > I can understand the need for aries-util and aries-proxy (the > OSGi/JNDI spec specifies that references need to be proxied). On the > aries-blueprint dependency, my suggestion is to make it optional so > that the aries jndi-bundle (the uber bundle) can resolve without > aries-blueprint being there. It should function as long as you don't > use the blueprint-specific features... > > Cheers, > > David > > On 16 January 2012 09:36, Timothy Ward <[email protected]> wrote: > > > > Hi everyone, > > > > There seems to be a misunderstanding here. The JNDI core bundle does not > > depend on the proxy or blueprint APIs. > > > > The bundle David is talking about is the JNDI uber bundle, which by > > definition depends on everything because it *is* everything. The proxy API > > is used by the JNDI URL bundle to implement the osgi:service URL scheme. > > This spec requires damping, which is exactly the sort of thing that the > > proxy bundle is for. The blueprint API is used to implement the blueprint: > > URL scheme, which is designed to integrate with blueprint, and so > > absolutely needs the blueprint API. > > > > I would like to ask people not to be so hasty in assuming that dependencies > > are unnecessary. If you want minimal dependencies then you should be > > consuming the individual bundles and looking at what they pull in. > > > > In this case we could look at avoiding slf4j, although it seems to be > > popular and other Aries bundles use it. I would be a -1 for removing util, > > proxy or blueprint dependencies from the JNDI project. The first two > > because they are a good reuse of existing function, the last because it's > > part of a really useful feature. If you want to run in an environment that > > doesn't provide those packages then you can always cut back to the JNDI API > > and core bundles. > > > > Regards > > > > Tim Ward > > ------------------- > > Apache Aries PMC member & Enterprise OSGi advocate > > Enterprise OSGi in Action (http://www.manning.com/cummins) > > ------------------- > > > > > >> Date: Mon, 16 Jan 2012 10:08:18 +0100 > >> Subject: Re: Aries JNDI dependencies > >> From: [email protected] > >> To: [email protected] > >> > >> Well, the point is that it removes a dependency as it's always > >> provided by the JRE. > >> I'm far from being a fan of JUL myself, the only way I'm using it is > >> when redirecting everything to a nicer backend in pax-logging ;-) > >> > >> On Mon, Jan 16, 2012 at 10:05, Felix Meschberger <[email protected]> > >> wrote: > >> > Hi, > >> > > >> > Am 16.01.2012 um 10:01 schrieb Guillaume Nodet: > >> > > >> >> On Mon, Jan 16, 2012 at 09:57, Felix Meschberger <[email protected]> > >> >> wrote: > >> >>> > >> >>>> * The SLF4J dependency always drags in at least 2 slf4j bundles. Would > >> >>>> it not be better to have the logging go through the OSGi log service? > >> >>> > >> >> > >> >> Or java.util.logging if the capabiilities of the log service are seen > >> >> too limited. > >> > > >> > Oh, please, not ;-) > >> > > >> > Then rather stick with SLF4J. Thanks. > >> > > >> > Regards > >> > Felix > >> > > >> > >> > >> > >> -- > >> ------------------------ > >> Guillaume Nodet > >> ------------------------ > >> Blog: http://gnodet.blogspot.com/ > >> ------------------------ > >> FuseSource, Integration everywhere > >> http://fusesource.com > >
