[slf4j-user] Using slf4j in a library project

[Ceki Gülcü]

At 11:29 PM 1/31/2007, Tim Vernum wrote:

>That's the way it used to be, but that presents a number of issues.
>
>Specifically, there are logging implementation (such as logback) that
>directly
>implement the API. If you push the api out into the implementation
>jars, then
>you start forcing other projects to bundle slf4j into their packages,
>and they
>need to track the slf4j team's changes themselves.
>So, if Ceki (or Sebastien, or ...) fixes a bug in the API, then some
>other team
>that is not directly connected to the slf4j team has to do a release
>of their
>project. This way that problem is avoided.

Well said.

>A similar problem would exist for applications teams who write their
>own slf4j
>implementations. The current approach just requires that they write
>their
>implementation and bundle it up, without having to track, or include,
>any slf4j
>classes.

Another good point.

>If you are building an application/library that depends on slf4j you
>will need
>to compile against slf4j-api.jar and sl4j-nop.jar
>
>Because the slf4j team is currently distributing most of the major
>implementations, it looks a little weird to people who chose to use
>one of those
>implementations. But, hopefully it's clear that if/when the other
>logging
>projects start implementing slf4j themselves, they will need a common
>-api.jar.

I am quite amazed at how well you have put it. Thank you Tim.


-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch