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 u...@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 ;) Nicolas 2009/5/19 Mario Ivankovits <ma...@ops.co.at> > 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 [mailto:c...@qos.ch] > 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. > http://logback.qos.ch > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
