[slf4j-dev] jcl-over-slf4j module not building

Wed Feb 21 23:35:44 CET 2007

(It would be nice to get finals taken off methods of the NOP implementation
for this release)

On 2/21/07, Ceki Gülcü <listid at qos.ch> 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
> > >> dev at slf4j.org
> > >> http://www.slf4j.org/mailman/listinfo/dev
> > >>
> > >
> > >
> >
> >_______________________________________________
> >dev mailing list
> >dev at slf4j.org
> >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
> dev at slf4j.org
> http://www.slf4j.org/mailman/listinfo/dev
>


-- 

- Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/slf4j-dev/attachments/20070221/93d1f55b/attachment.htm>