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

[Jacob Kjome]

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