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

[Eric Crahen]

I like it ;-)

On 2/17/07, Jacob Kjome <hoju at visi.com> 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
>



-- 

- Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/slf4j-dev/attachments/20070217/01efc2fb/attachment.htm>