[slf4j-user] Using slf4j in a library project

[Tim Vernum]

On 01/02/2007, at 3:02 AM, Jacob Kjome wrote:

>
> Though because LoggerFactory doesn't exist in slf4j-api.jar, this  
> jar is kind of
> useless, no?

No.
Well, it may be useless to you, but it's not useless to others.

> Why is it built at all?  Only various implementation jars should
> be built.

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.

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.

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.