Lucas Bergman wrote: > I ran into a strange dependency resolution problem at work, which a > colleague and I whittled down to a fairly simple test case. Consider > the following POM: > > <project xmlns="http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/maven-v4_0_0.xsd";> > <modelVersion>4.0.0</modelVersion> > <groupId>com.example</groupId> > <artifactId>htmlunitbug</artifactId> > <packaging>jar</packaging> > <version>2.71828</version> > > <build> > <pluginManagement> > <plugins> > <plugin> > <artifactId>maven-compiler-plugin</artifactId> > <configuration> > <source>1.5</source> > <target>1.5</target> > </configuration> > </plugin> > </plugins> > </pluginManagement> > </build> > > <dependencies> > <dependency> > <groupId>junit</groupId> > <artifactId>junit</artifactId> > <version>4.6</version> > <scope>test</scope> > </dependency> > <dependency> > <groupId>net.sourceforge.htmlunit</groupId> > <artifactId>htmlunit</artifactId> > <version>2.5</version> > <scope>test</scope> > </dependency> > <dependency> > <groupId>org.hibernate</groupId> > <artifactId>hibernate-ehcache</artifactId> > <version>3.3.1.GA</version> > <scope>runtime</scope> > </dependency> > <!-- hibernate-ehcache depends on a very old version. --> > <dependency> > <groupId>net.sf.ehcache</groupId> > <artifactId>ehcache</artifactId> > <version>1.6.0</version> > <scope>runtime</scope> > </dependency> > </dependencies> > </project> > > And, consider the following test class: > > import com.gargoylesoftware.htmlunit.WebClient; > import org.junit.Test; > > public class MyTest { > @Test public void test() { new WebClient(); } > } > > Running this test with Maven 2.1.0 fails: > > java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory > [ ... ] > > The POM for htmlunit 2.5 declares commons-logging 1.1.1 as a > (compile-scope) dependency, so this seems wrong. There seems to be > some interaction between that POM and the dependent POMs. Indeed: > > 1. Moving the htmlunit dependency element below the > hibernate-ehcache and ehcache dependency elements causes > commons-logging to be a test-scope dependency, and the test > succeeds. This seems bizarre. Should the ordering of dependency > elements ever matter?
It does matter, but only for artifacts at the same distance from the dependency. > 2. Adding an exclusion of commons-logging to the hibernate-ehcache > dependency causes the test to succeed. I tried this, because the > hibernate-ehcache POM depends on commons-logging version > 99.0-does-not-exist, a rather famous JBoss kludge[1]. That is your problem. What this does is mess the dependency-tree. It removes commons-logging from the dependency tree because that version "99.0-..." is larger than the latest current release of commons-logging. The "99.0-..." version should *never ever* reach end users. It can *only* be used by internal project. > 3. Removing the dependency on hibernate-ehcache causes the test to > succeed. This is perhaps not surprising, in light of (2). > > 4. Removing the dependency on ehcache causes the test to succeed. > This is very strange to me, since ehcache directly depends on > commons-logging 1.0.4; it contains no funny business. > > Am I doing something wrong here? I'll be happy to follow this through > with a JIRA ticket, if somebody here can convince me that I haven't > done anything stupid; I'm not a very confident Maven user. > > Best, > -- Lucas > > Footnotes: > [1] > http://day-to-day-stuff.blogspot.com/2007/10/announcement-version-99-does-not-exist.html > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Dennis Lundberg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
