47

I use the maven-enforcer-plugin to check for dependency convergence issues. A typical output would be:

[WARNING] Rule 1: org.apache.maven.plugins.enforcer.DependencyConvergence failed 
  with message:
Failed while enforcing releasability the error(s) are [
Dependency convergence error for junit:junit:3.8.1 paths to dependency are:
+-foo:bar:1.0-SNAPSHOT
  +-ca.juliusdavies:not-yet-commons-ssl:0.3.9
    +-commons-httpclient:commons-httpclient:3.0
      +-junit:junit:3.8.1
and
+-foo:bar:1.0-SNAPSHOT
  +-junit:junit:4.11
]

Seeing this message, I would normally "solve" it by excluding the transitive dependency, e.g.

<dependency>
  <groupId>ca.juliusdavies</groupId>
  <artifactId>not-yet-commons-ssl</artifactId>
  <version>0.3.9</version>
  <exclusions>
    <!-- This artifact links to another artifact which stupidly includes 
      junit in compile scope -->
    <exclusion>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
    </exclusion>
  </exclusions>
</dependency>

I'd like to understand whether this is truly a fix and the risks involved in excluding libraries in this fashion. As I see it:

  • The "fix" is normally safe, provided I'm choosing to use the newer version. This relies on the library authors maintaining backwards compatibility.

  • There is typically no impact on the Maven build (since the nearer definition wins), however by excluding the dependency I'm telling Maven that I know about this problem and thus appeasing the maven-enforcer-plugin.

Are my thoughts correct and is there an alternative way of handling this issue? I'm interested in answers that focus on the general case - I realise the junit example above is a little strange.

Duncan Jones
  • 67,400
  • 29
  • 193
  • 254

3 Answers3

76

We all agree that JUnit should never be set to another scope than test. Generally speaking I don't think either that there is another solution than excluding the unwanted dependency, so we all agree that your are right to do it.

A SIMPLE CASE :

As Andreas Krueger says, there may be a risk with versions (I actually encountered it). Let say that the project's dependencies are the following:

+-foo:bar:1.0-SNAPSHOT
  +-group1:projectA:2.0
     +-group2:projectB:3.8.1
  +-group2:projectB:4.11

Note that it is only a mere simplification of your case. Seeing this dependency tree, you would exclude the dependency projectB given by projectA :

<dependency>
  <groupId>group1</groupId>
  <artifactId>projectA</artifactId>
  <version>2.0</version>
  <exclusions>
    <exclusion>
      <groupId>group2</groupId>
      <artifactId>projectB</artifactId>
    </exclusion>
  </exclusions>
</dependency>

After packaging the project with maven, the remaining dependency would be group2-someProjectB-4.11.jar, version 4.11 and not 3.8.1. Everything would be fine and the project would run without encountering any problem at all.

Then, a while after, let say that you decide to upgrade to the next version of project A, version 3.0 which adds new great features :

<dependency>
  <groupId>group1</groupId>
  <artifactId>projectA</artifactId>
  <version>3.0</version>
  <exclusions>
    <exclusion>
      <groupId>group2</groupId>
      <artifactId>projectB</artifactId>
    </exclusion>
  </exclusions>
</dependency>

The problem is that you are not aware yet that projectA version 3.0 also have upgraded its dependency projectB to version 5.0 :

+-foo:bar:1.0-SNAPSHOT
  +-group1:projectA:3.0
     +-group2:projectB:5.0
  +-group2:projectB:4.11

In that case, the exclusion you would have made a while ago excludes projectB version 5.0.

However, projectA version 3.0 needs the improvements from project B version 5.0. Because of the exclusion, after packaging the project with maven, the remaining dependency would be group2-someProjectB-4.11.jar, version 4.11 and not 5.0. At the moment you use any of projectA's new features, the program wouldn't run correctly.

WHAT WAS THE SOLUTION ?

I encountered this problem in a Java-EE project.

A team developped database services. They packaged it as projectA. Each time they updated the services, they also updated a file listing all their current dependencies and the current versions.

ProjectA was a dependency for the Java-EE project I was working on. Each time the service-team updated ProjectA, I also checked the versions' updates.

In fact, there is no harm in excluding a dependency. But each time you update a dependency where an exclusion has been set, You have to check :

  • if this exclusion still makes sense.
  • if you need to upgrade the version of the excluded dependency in your own project.

I guess maven exclusions are like kitchen knifes. It's sharp, cuts vegetables with no effort, but requires care when handling it...

  • 1
    A very good response, thank you. I hadn't thought about the dangers of maintaining an exclusion. – Duncan Jones Apr 29 '13 at 10:35
  • I awarded you the bounty due to the level of detail in your answer. It was nice to see a (somewhat) real world example of how this can go wrong. – Duncan Jones Apr 29 '13 at 13:00
  • @DuncanJones Thanks. My answer is rather a warning than a solution. Still, I hope it will help. –  Apr 29 '13 at 13:36
  • In the specific case of JUnit with compile scope the exclusion approach is correct, but "generally speaking" the dependencyManagement approach should be preferable. See http://timsteffens.blogspot.com/2014/05/solving-conflicts-with-transitive-maven.html – Pino Jun 28 '18 at 10:53
  • @DuncanJones: Great movie - Moon :-) – Kieran Ryan Apr 08 '20 at 12:57
3

If JUnit as an artifact is coming through as a dependency in compile scope, it is a bug of one of your libraries, here: ca.juliusdavies.

JUnit should always be included in test scope. Thus, it is not packed into the produced .jar, .war or .ear file, on successful build.

Generally speaking, there is no harm in excluding already included dependencies, as when library 1 and library 2 share one common dependency.

The only problem, of course, that can occur, is when library 1 and library 2 include different versions of the same dependent artifact. This can cause run-time errors, when the features of the library have changed. Fortunately, this is not often the case, unless the difference in the version numbers is great. In general, it is advisable to include the latest dependency version and exlude the older one. This is most of the time viable.

If not, check wheter there are updates to the first-level dependencies of your project.

Andreas Krueger
  • 1,497
  • 13
  • 16
  • Regarding your first point, yes you are correct (hence the comment in my XML bemoaning the stupidity of needing to do this). It sounds like we agree on your second point (regarding backwards compatibility). – Duncan Jones Apr 22 '13 at 14:49
  • Duncan, I think that I already gave you the answer about your second question, too. The risk is to potentially face run-time errors. Since the direct dependenies are already compiled, when you include them, the Maven build will not tell you. All that can occur, when mixing up different versions of indirect dependencies are run-time errors. A run time error also being a deployment error of a WAR. JAR or EAR file in the web or application container. – Andreas Krueger Apr 22 '13 at 21:00
0

Best way to solve this dependency issue while using enforcer in project, One should add error causing dependency in dependency management i.e pom.xml like in this junit is causing the problem, so picking the higher version and add as dependency in pom.xml

            <dependency><groupId>junit_or_group_id_error_causing_dependency</groupId><artifactId>Junit_or_artifact_id_group_id_error_causing_dependency</artifactId><version>4.11_or_higher_version_of_error_causing_dependency</version></dependency>

Exclusion can be other solution,but I found it more cleaner way of doing the same.

Gaurav Tanwar
  • 482
  • 6
  • 16