I'm afraid that this is where we disagree about uber-bundles. In my view they are a covenience for pulling in everything, usually for testing. If you are building a server you pull in the bundles for the function you need and dependencies you have.
Currently, as far as the JNDI uber bundle is concerned, proxy and blueprint are not optional. The uber bundle will throw errors if you don't have those packages, and I don't think we should be adding function to the regular bundles to support their non-optional dependencies being absent. IMO it makes the whole thing too complex to maintain and too hard to understand. I'm not really looking to start a debate about the role of uber bundles here, as a group we've flogged that particular horse far beyond the grave, and I don't think that we'll get much use out of another one. Hopefully I have clarified why the dependencies are there in the current uber bundle. If people want to make changes then so be it. 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:50:54 +0100 > Subject: Re: Aries JNDI dependencies > From: [email protected] > To: [email protected] > > For uber-bundles, optional parts should have ... optional imports. So > if blueprint is not a core part, even if very valuable, I'd suggest > having its imports flagged as optional in the big bundle (if that's > not already the case). > > On Mon, Jan 16, 2012 at 10: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 > > > > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > FuseSource, Integration everywhere > http://fusesource.com
