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

[Ceki Gülcü]

Hi Jacob,

I intend to reply to your message when as soon as I get a chance.

Cheers,

At 02:03 AM 2/18/2007, Jacob Kjome wrote:

>Of course with the Service API that Eric Crahen
>is pushing, the NOP implementation could be used
>as the default fallback binding, packaged into
>the slf4j-api.jar, and chosen if no other binding
>is made available by the user.  This would have following benefits...
>
>1.  Remove the imposition of forcing a user to
>provide a separate SLF4J binding jar, since the
>default do-nothing binding would be used as a
>fallback if no other binding is provided.
>
>2.  Remove the imposition of logging when it is
>not desired, and without having to actively provide slf4j-nop.jar
>
>3.  Remove the necessity of generating
>slf4j-nop.jar, as it would already be part of slf4j-api.jar
>
>4.  Reduce user confusion.  Instructions now read:
>
>"To satisfy an SLF4J dependency, simply put
>slf4j-api.jar in the classpath.  Optionally, to
>get logging output, add an SLF4J implementation
>binding in the classpath alongside slf4j-api.jar."
>
>
>With this setup, a user can depend on
>slf4j-api.jar and be done.  Only if logging is
>desired would one need to add a binding that actually performs logging.
>
>
>Thoughts?
>
>Jake
>
>
>At 10:37 AM 2/17/2007, you wrote:
>  >Ceki Gülcü wrote:
>  >> At 11:05 PM 2/16/2007, John E. Conlon wrote:
>  >>
>  >>> Your right, neither do I want to increase the number of classes in the
>  >>> org.slf4j packages.  But we are basically doing the same kind of thing
>  >>> with the second approach as well - exposing our selves to greater
>  >>> coupling by clients.  By exporting the org.slf4j.spi package we are
>  >>> exporting what was once a private package and all classes in it, on to
>  >>> the OSGi package matrix.
>  >>>
>  >>
>  >> The o.s.spi package contains two interfaces, namely
>  >> LoggerFactoryBinder and MarkerFactoryBinder. I am not worried about
>  >> exposing these interfaces into the public.
>  >>
>  >>
>  >That makes sense.  I just committed  the change.  Project now builds
>  >with -Posgi flag.
>  >
>  >End users will still only import o.s while adapters clients will import
>  >both o.s and o.s.spi.
>  >>> Right now we are in a very good position regarding client coupling to us
>  >>> and dependencies we have on other third party jars.  Although we are
>  >>> still using split packages to deliver our Logger service but now for
>  >>> 1.5.0 we do the 'package join' at maven build time versus before we had
>  >>> our clients do it on the classpath.
>  >>>
>  >>
>  >> It's quite nice that we have the technical ability to package all
>  >> SLF4J classes within each binding. However, I am not 100% convinced
>  >> that doing so yields the best user experience, especially as seen by
>  >> developers of libraries.
>  >>
>  >> Assume Alice is the developer of some library, say La. As far as
>  >> Alice is concerned, imposing slf4j-api as a dependency of La is
>  >> acceptable while imposing a binding is not. In SLF4J 1.2, Alice has to
>  >> depend on a binding in La, typically slf4j-simple, and then let the
>  >> user change the binding. It would be more convenient if La depended on
>  >> slf4j-api only. This would allow the end-user to import La as is,
>  >> including its dependency on slf4j-api without change.
>  >>
>  >Perhaps I am not seeing it but, wouldn't it work like it always has?
>  >Alice for her library still imposes the slf4j-api as a dependency and
>  >for testing uses one of the bindings.
>  >> For instance, if Bob was the author of some library, say Lb (how
>  >> original) which depended on La and by transitivity on slf4j-api, Bob
>  >> could use the SLF4J API without additional work.
>  >>
>  >Bob uses La for Lb which carries with it only the slf4j-api dependency,
>  >Bob then uses whatever binding he wishes for testing his Lb.
>  >
>  >Sally now builds an application from Lb and uses whatever binding she
>  >wants but when packaging the application for end user distribution only
>  >needs to add a slf4j binding to the installation zip.  (Even if she
>  >added the slf4j-api and the binding it should still work as expected.)
>  >
>  >John
>  >
>  >_______________________________________________
>  >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