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? 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]. 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]
