Maven 2 & 3

Add explicit transitive dependencies in dependencyManagement section of pom.xml

Details

  • Type: New Feature New Feature
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Duplicate
  • Affects Version/s: 2.0.9
  • Fix Version/s: None
  • Component/s: Dependencies
  • Labels:
    None
  • Complexity:
    Intermediate
  • Number of attachments :
    0

Description

Transitive dependencies cause lots of headaches and require a fair amount of manual intervention to fix conflicts. It is common to see a pom with the following scenario:

<dependencyManagement>
<dependencies>
<!-- Must manually include com.other.common when using com.sample.foo -->
<dependency>
<groupId>com.sample</groupId>
<artifactId>foo</artifactId>
<version>1</version>
<exclusions>
<!-- com.sample.foo includes old version 1 of com.other.common -->
<exclusion>
<groupId>com.other</groupId>
<artifactId>common</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.other</groupId>
<artifactId>common</artifactId>
<version>2</version>
</dependency>
<dependency>
<groupId>com.sample</groupId>
<artifactId>bar</artifactId>
<version>3</version>
<!-- com.sample.foo includes version 2 of com.other.common -->
</dependency>
</dependencies>
</dependencyManagement>

This is problematic because descendant poms must manually include the com.other.common dependency when including the com.sample.foo dependency. The word around is creating separate pom projects to manage the dependencies, but this doesn't do a great job of expressing intent, leads to a proliferation of projects, and makes dependency management more difficult since it's scattered over multiple poms.

Ideally users should be allowed to specify inclusions in the dependency management section of the pom e.g. something like:

<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.sample</groupId>
<artifactId>foo</artifactId>
<version>1</version>
<!-- com.sample.foo includes old version 1 of com.other.common -->
<exclusions>
<exclusion>
<groupId>com.other</groupId>
<artifactId>common</artifactId>
</exclusion>
</exclusions>
<inclusions>
<inclusion>
<groupId>com.other</groupId>
<artifactId>common</artifactId>
<version>2</version>
</inclusion>
</inclusions>
</dependency>
<dependency>
<groupId>com.sample</groupId>
<artifactId>bar</artifactId>
<version>3</version>
<!-- com.sample.foo includes version 2 of com.other.common -->
</dependency>
</dependencies>
</dependencyManagement>

Issue Links

Activity

Hide
Brett Porter added a comment -

unless I misunderstand what you're saying, simply declaring the "inclusion" in dependency management as another dependency and omitting the exclusion will do what you need

Show
Brett Porter added a comment - unless I misunderstand what you're saying, simply declaring the "inclusion" in dependency management as another dependency and omitting the exclusion will do what you need
Hide
Joel Turkel added a comment -

The problem occurs when the dependencyManagement section is declared in the root pom file of a large project hierarchy. Then every descendant project that depends on com.sample:foo must also explicitly include the dependency on com.other:common. This is not ideal since the com.other:common is really just a transitive dependency of com.sample:foo and causes a large maintenance overhead. An even bigger problem occurs if the conflict is introduced when upgrading to a new version of com.sample:bar. A version upgrade that should only involve a change to the dependencyManagement section of the root pom file ends up requiring changes to all descendant projects that use com.sample:foo and/or com.sample:bar.

Show
Joel Turkel added a comment - The problem occurs when the dependencyManagement section is declared in the root pom file of a large project hierarchy. Then every descendant project that depends on com.sample:foo must also explicitly include the dependency on com.other:common. This is not ideal since the com.other:common is really just a transitive dependency of com.sample:foo and causes a large maintenance overhead. An even bigger problem occurs if the conflict is introduced when upgrading to a new version of com.sample:bar. A version upgrade that should only involve a change to the dependencyManagement section of the root pom file ends up requiring changes to all descendant projects that use com.sample:foo and/or com.sample:bar.
Hide
Joerg Schaible added a comment -

This is not true. If you declare com.other:common in the depMgmnt as Brett advised, it will take also precedence for transitive deps.

Show
Joerg Schaible added a comment - This is not true. If you declare com.other:common in the depMgmnt as Brett advised, it will take also precedence for transitive deps.
Hide
Joel Turkel added a comment -

The suggested workaround will work for version number changes. Another common scenario is incompatible jars e.g. javax.servlet:servlet-api and generonimo-specs:servlet-api. For scenarios like this we want to replace all dependencies transitive dependency on javax.servlet:servlet-api with generonimo-specs:servlet-api.

Show
Joel Turkel added a comment - The suggested workaround will work for version number changes. Another common scenario is incompatible jars e.g. javax.servlet:servlet-api and generonimo-specs:servlet-api. For scenarios like this we want to replace all dependencies transitive dependency on javax.servlet:servlet-api with generonimo-specs:servlet-api.
Hide
Brett Porter added a comment -

I think the issue you're referring to there is "global dependency exclusions", so I've linked this issue to that.

Show
Brett Porter added a comment - I think the issue you're referring to there is "global dependency exclusions", so I've linked this issue to that.

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: