Jörg Schaible wrote:
Forgive me for asking, but were you aware of the above. And if you
were, would you care to explain a scenario in mind which is troubling
you?
First: The solution is perfect for a normal user i.e. somebody building an
application, not a library/framework. The problem starts when somebody
publishes some artifacts that explicitly depend on cl-0.0.0-EMPTY:
1. Me building A, depending on B and C
2. B depends on cl-0.0.0-EMPTY
3. C depends on cl-1.1.1
According the definition above I get a ClassNotFoundException running A if I
declare my dependencies in sequence B, C. Since both deps use CL and A
inherits it transitively at equal level, the first one wins => boom.
You are correct. In defense of 0.0-EMPTY authors of libraries are not
supposed to use use cl-0.0-EMPTY. Only end-users should use it. Any
documentation for cl-0.0-EMPTY would need to emphasize that in bold
and red print. Moreover, if you are an author of a library, if you
don't want to use commons-logging, you can simply remove the
dependency on commons-logging. You would not need cl-0.0-EMPTY at
all. You would have use for cl-0.0-EMPTY if as an author of a library
or framework with many dependencies (e.g. wicket, tapestry) you had a
dependency which in turn depended on commons-logging, (and only if you
were using Maven and SLF4J).
Stern warnings in the documentation of version 0.0-EMPTY should goad
authors of shared components away from 0.0-EMPTY. However, I agree
with you that the risk of misuse of 0.0-EMPTY cannot be completely
alleviated. It's a tough call to make.
- Jörg
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
