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 _______________________________________________ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev
