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

[Ceki Gülcü]

At 08:25 PM 2/18/2007, John E. Conlon wrote:

> > Assuming Maven 2 is used by all participants, without particular
> > action by Sally, slf4j-api would be packaged in the final
> > application along with a user-chosen binding, say slf4j-log4j12. In
> > that case, we would have the contents of slf4j-api project duplicated,
> > once in slf4j-api.jar and once in slf4j-log4j12.jar. It would most
> > probably work as expected, but I don't think it's good practice to
> > have class files duplicated.
> >
>I don't like this class duplication either, but AFAIK given the same
>classloader this should not matter.  The same classloader will load
>which ever it encounters first.  (Maybe I will eat these words latter?) ;-)

Hi John,

The driving premise behind SLF4J is to reduce surprises. I think we
should do things by the book and avoid duplication. Since SLF4J
version 1.1, user's have been asked to have two jars, slfl4-api.jar in
addition to a binding. In SLF4J 1.3, the general arrangement remains
the same, except that slf4j-api is now self-sufficient as a
compile-time dependency.

I quite like this user-story. Alice and Bob expose slf4j-api as a
transitive dependency, while Sally, the end-user, chooses to depend on
a binding of her own selection.  We respond to Eric Crahen's initial
request [1] without fundamentally changing how SLF4J works.

I do not wish to hide behind backward-compatibility excuses. We
finally have a nice and clear separation between slf4j-api and
slf4j-binding. Let's keep it clean and simple even if it costs an
extra jar on the class path.

[1]
http://www.qos.ch/pipermail/logback-user/2007-February/000129.html



>a good weekend for you too,
>John

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