Maven 2 - different dependency versions in test and compile

user_639753 0
Viewed 11132

I have project that depends on commons-httpclient [2.0] (compile).

I would like to write some jbehave tests - jbehave-core 3.4.5 (test). Both this dependencies depend on commons-lang but in different versions - 1.0.1 and 2.5.

dependency

When I execute mvn package I get [BUID FAILURE] in tests section. There is an exception for my testcase in surefire-plugin output:

java.lang.NoSuchMethodError: org.apache.commons.lang.StringUtils.substringBeforeLast(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;

As I looked in source code - in commons-lang 1.0.1 - indeed, there is no StringUtils.substringBeforeLast(...) method. Why maven uses commons-lang from commons-httpclient (compile) and not from jbehave-core in testing?

I can't afford to exclude this conflicting dependency in commons-httpclient so it must stay in compile time.

So how can this be resolved - commons-lang 2.5 version in testing and 1.0.1 in compile time?

maven version maven-2 java
4 Answers

In Maven 3, you can trick maven by adding a dot after groupId

<dependency>
  <groupId>groupId.</groupId>
  <artifactId>artifactId</artifactId>
  <version>version1</version>
  <scope>test</scope>
</dependency>

<dependency>
  <groupId>groupId</groupId>
  <artifactId>artifactId</artifactId>
  <version>version2</version>
  <scope>compile</scope>
</dependency>

The sequence matters here. need to have test first and then compile.

user_90962460 
<dependency>
  <groupId>groupId.</groupId>
  <artifactId>artifactId</artifactId>
  <version>version1</version>
  <scope>test</scope>
</dependency>

<dependency>
  <groupId>groupId</groupId>
  <artifactId>artifactId</artifactId>
  <version>version2</version>
  <scope>compile</scope>
</dependency>

Adding a dot doesnt work in pom.xml as . is converted to slash which in return generated incorrect URL. Is thr any other way to do this

user_74576550

It's a really bad idea to have two different versions for compile and test dependency:

Your non-test code might rely on behavior of the newer JAR and fail when using classes of the older JAR. When you use the older JAR in your tests, the non-test code would fail with the old JAR.

Otherwise you could have used the older JAR anywhere, with the same version... If you get both JAR versions into your classpath, you cannot know which one gets picked up when running your tests. That's also a bad idea.

Hence you should get non-test and test to the same JAR version dependency.

user_31566710
Related