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:
users-unsubscribe@...
> For additional commands, e-mail:
users-help@...
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail:
users-unsubscribe@...
For additional commands, e-mail:
users-help@...