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 >
