(It would be nice to get finals taken off methods of the NOP implementation for this release)
On 2/21/07, Ceki Gülcü <[EMAIL PROTECTED]> wrote:
John, With the recent changes made by Sebastien [1, 2], we no longer have packages split across modules. Thus, slf4j-api exports packages: org.slf4j org.slf4j.spi org.slf4j.helpers imports packages: org.slf4j.impl slf4j-BINDING (where BINDING is one of nop, simple, log4j12, etc) exports packages: org.slf4j.impl imports packages: org.slf4j org.slf4j.spi org.slf4j.helpers As things stand currently, I believe that we are close to a release candidate. The remaining question is with respect to OSGi meta-data. Do we keep using maven-bundle-plugin or not? In particular, does that plug-in support Require-Bundle directives? (I think that Require-Bundle directives would be necessary.) Comments/thoughts? [1] http://www.slf4j.org/pipermail/dev/2007-February/000818.html [2] http://www.slf4j.org/pipermail/dev/2007-February/000874.html At 11:45 PM 2/20/2007, John E. Conlon wrote: >Ceki Gülcü wrote: > > John, > > > > Do you have a suggestion how we could avoid duplication of slf4j-api > > classes in the various bindings? Can this be done using > maven-bundle-plugin ? > > >At the moment I can think four approaches to removing the duplication of >classes in the bindings that sit on 'Sally's application's classpath. > >1. Keep the packages split across the api and binding projects, continue >to rely on single classloader joining at runtime, and move back to a >Require-Bundle approach for osgi support. We won't need the >maven-bundle-plugin in the binding projects for this. > >2. Remove the split packages by consolidating the packages into the api >and binding jars, and use a 'service implementation' discovery similar >that suggested by Eric in the "aufgeregt" thread :-) : > >http://www.qos.ch/pipermail/logback-user/2007-February/000129.html > >We should not depend on a sun impl for this so we would have to provide >our own implementation, Boris has provided an example at: > >http://marc.theaimsgroup.com/?l=slf4j-dev&m=117157566417290&w=2 > >While I have not experimented with his code, I do see one area that >would require a change for it to work in an OSGi environment. > > public Object obtainFactory(ClassLoader cl) { > ILoggerFactory ret = null; > InputStream is = cl.getResourceAsStream(SERVICE_ID); > >Note: couldn't use a context classloader as it would not find the >classes in an OSGi runtime. Sun's service api offers similar signatures. > >3. Keep split packages and retain current way of combining api and >bindings. Remove OSGi decorations and maven-bundle-plugin from the five >bindings projects. Create five additional OSGi 'pom' projects that >just wrap the api and bindings to create OSGi binding bundles. These >projects would only have a pom.xml (no code) and the artifacts they >create would be the same bundles as we are now producing in the binding >projects. All other projects producing native jar/osgi bundles (like >the adapters) would remain unchanged. >(In this case Sally would not use the osgi-xxx-binding bundles.) > >4. Convince Sally to run OSGi ;-) > > From an OSGi perspective I would rate them in order of functionality >from higher to lower - 4, 3, 2, 1. > >kind regards, >John > > > > > At 07:52 PM 2/19/2007, Ceki Gülcü wrote: > > > > > >> At 08:25 PM 2/18/2007, John E. Conlon wrote: > >> > >> > >>>> Assuming Maven 2 is used by all participants, without particular > >>>> action by Sally, slf4j-api would be packaged in the final > >>>> application along with a user-chosen binding, say slf4j-log4j12. In > >>>> that case, we would have the contents of slf4j-api project duplicated, > >>>> once in slf4j-api.jar and once in slf4j-log4j12.jar. It would most > >>>> probably work as expected, but I don't think it's good practice to > >>>> have class files duplicated. > >>>> > >>>> > >>> I don't like this class duplication either, but AFAIK given the same > >>> classloader this should not matter. The same classloader will load > >>> which ever it encounters first. (Maybe I will eat these words > latter?) ;-) > >>> > >> Hi John, > >> > >> The driving premise behind SLF4J is to reduce surprises. I think we > >> should do things by the book and avoid duplication. Since SLF4J > >> version 1.1, user's have been asked to have two jars, slfl4-api.jarin > >> addition to a binding. In SLF4J 1.3, the general arrangement remains > >> the same, except that slf4j-api is now self-sufficient as a > >> compile-time dependency. > >> > >> I quite like this user-story. Alice and Bob expose slf4j-api as a > >> transitive dependency, while Sally, the end-user, chooses to depend on > >> a binding of her own selection. We respond to Eric Crahen's initial > >> request [1] without fundamentally changing how SLF4J works. > >> > >> I do not wish to hide behind backward-compatibility excuses. We > >> finally have a nice and clear separation between slf4j-api and > >> slf4j-binding. Let's keep it clean and simple even if it costs an > >> extra jar on the class path. > >> > >> [1] > >> http://www.qos.ch/pipermail/logback-user/2007-February/000129.html > >> > >> > >> > >> > >>> a good weekend for you too, > >>> John > >>> > >> -- > >> Ceki Gülcü > >> Logback: The reliable, generic, fast and flexible logging framework > for Java. > >> http://logback.qos.ch > >> > >> _______________________________________________ > >> dev mailing list > >> [email protected] > >> http://www.slf4j.org/mailman/listinfo/dev > >> > > > > > >_______________________________________________ >dev mailing list >[email protected] >http://www.slf4j.org/mailman/listinfo/dev -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch _______________________________________________ dev mailing list [email protected] http://www.slf4j.org/mailman/listinfo/dev
-- - Eric
_______________________________________________ dev mailing list [email protected] http://www.slf4j.org/mailman/listinfo/dev
