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 12:45:10 GMT
The "global exclusion" is rquested since ... some years (I can't exactly
remember, but I've seen it in Jira for a while) and can't be fixed until the
POM schema is changed - something that cannot occur before maven 3.x, so one
or two years.
(For info, the issue with POM format change is that it requires a new maven
release to support it and previous maven users could not read artifacts from
repo anymore. Maven 3 will support a more plugable POM reader to fix this)

exluding commons-logging from all transitive dependencies "by hand" is a
solution (considering for example the m2eclipse right click "exclude from
dependencies") BUT must be applied on every dependency add/change. A simple
version update MAY retintroduce commons-logging. This is known on
user@mavenlist as the "commons-logging
dependency hell", that can be compared to the also known "commons-logging
classloader hell" - Please note I have myself nothing again commons-logging


2009/5/19 Mario Ivankovits <>

> Hmmm ....
> Couldn't we ask the maven devs to extend the pom to allow "global
> excludes"?
> The only thing this 0.0 stuff solves, is, that the user does not need to
> exclude commons-logging from each and every dependency.
> What you can do ... and what I did.
> Nice would be, as opposite to the <dependencies>, to have a global
> <excludes>, no?
> That way, problems like this are sorted out once and for all.
> Or do I miss something?
> Ciao,
> Mario
> -----Original Message-----
> From: Ceki Gulcu []
> Sent: Tuesday, May 19, 2009 2:03 PM
> To: Commons Developers List
> Subject: Re: commons-logging version 0.0.0-EMPTY
> 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.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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