commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From nicolas de loof <>
Subject Re: commons-logging version 0.0.0-EMPTY
Date Tue, 19 May 2009 13:02:23 GMT
> nicolas de loof wrote:
>> A library autor that MAY use cl-0.0 to remove commons-logging from
>> dependency tree and use SLF4J will anyway have a dependency on
>> cl-over-sfl4j
>> that solves the ClassNotFoundException
> Good point but what if the end-user wanted to use commons-logging proper
> and not
> SLF4J? In other words, can the end-user override the propagation of
> cl-0.0-EMPTY and use cl-1.1 instead? Clearly, by declaring cl-1.1 in the
> project POM, the end-user can reinstate cl-1.1.

Let's suppose some lib author really don't like commons-logging and set a
dependency on cl-0.0. Based on this, his project has dependency on
cl-over-slf4j and slf4j-api.

If the end user WANT to use CL he just has to use the exclusion process :
remove dependency on cl-over-slf4j, and set it's own dependency on CL, maybe
also including slf4j-over-cl. Anyway if such a library came out (that would
be a strange choice but it is possible) they certainly have a good reason
not to use commons-logging. Maybe some strange classloader hacks ?

Such a use case would really be an rare case anyway, and end user can
allways control the dependency tree. The most difficulty with CL is that it
is so widely used that it becomes VERY difficult to replace it by another
API-compatible lib as SLF4J (maybe others ?)


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message