[slf4j-user] Using slf4j in a library project
Tim Vernum
tim at adjective.org
Wed Jan 31 23:29:31 CET 2007
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.
More information about the slf4j-user
mailing list