[MNG-6141] Dependency management overrides are not transitive and should be considered an anti-pattern.

[jira-importer]

Christian Schulte opened MNG-6141 and commented

Overriding the dependency management in a module's <dependencies> section, the overridden value will not be preserved transitively. It makes no sense to be able to override the dependency management in a module if that is only effective in that module and nowhere else. Overriding the dependency management from inside a <dependencies> element should be considered an anti-pattern. Maven should provide a warning when it is used. During the development of Maven 3.4, there have been quite a few discussions on dev@ about build issues which were all caused by overriding the dependency management that way without noticing this is not supported transitively.

---

Attachments:

• MNG-6141.zip (1.93 kB)
• MNG-6141-3.zip (2.52 kB)

Issue Links:

• MRESOLVER-33 New 'DefaultDependencyManager' managing dependencies on all levels supporting transitive dependency management
  ("is blocked by")

3 votes, 14 watchers

[jira-importer]

Christian Schulte commented

Example project demonstrating the issue. Unpack and execute mvn package dependency:tree -X. The parent is managing the org.apache.maven:maven-plugin-api dependency to version 2.0. The module-1 overrides that to version 3.0. module-2 depends on module-1 and there the version of the transitive org.apache.maven:maven-plugin-api is managed to 2.0 (expected behaviour) although module-1 is overriding it to 3.0 (should not be supported).

Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
Maven home: /home/schulte/Applications/apache-maven-3.3.9.orig
Java version: 1.7.0_80, vendor: Oracle Corporation
Java home: /usr/local/jdk-1.7.0/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "openbsd", version: "6.0", arch: "amd64", family: "unix"

[DEBUG] localhost:module-1:jar:1.0-SNAPSHOT
[DEBUG]    org.apache.maven:maven-plugin-api:jar:3.0:compile
[DEBUG]       org.apache.maven:maven-model:jar:3.0:compile
[DEBUG]          org.codehaus.plexus:plexus-utils:jar:2.0.4:compile
[DEBUG]       org.apache.maven:maven-artifact:jar:3.0:compile
[DEBUG]       org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile
[DEBUG]          org.codehaus.plexus:plexus-component-annotations:jar:1.5.4:compile
[DEBUG]          org.codehaus.plexus:plexus-classworlds:jar:2.2.3:compile
[DEBUG]          org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile
[DEBUG]             org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile
[INFO]

[DEBUG] localhost:module-2:jar:1.0-SNAPSHOT
[DEBUG]    localhost:module-1:jar:1.0-SNAPSHOT:compile
[DEBUG]       org.apache.maven:maven-plugin-api:jar:2.0:compile (version managed from 3.0 by localhost:parent:1.0-SNAPSHOT)

[jira-importer]

Joerg Schaible commented

Sorry, but this is a perfectly legal situation! We manage a global POM with depMgmt section for some products. However, some derived projects will override the settings in the depMgmt section on purpose. Yes, it is possible to shoot yourself into the foot using a depMgmt section, but in any case, it must have been my own decision. Nobody said, the managing dependencies is easy, but I expect the build tool to respect my choices.

[jira-importer]

Christian Schulte commented

Is any of those projects you are talking about publicly available?

[jira-importer]

Joerg Schaible commented

No, they are not public. However, even the maven-parent sets defaults for some dependencies in a dependencyManagement section.

[jira-importer]

Christian Schulte commented

Issue is not about setting defaults in the dependency management. It's about overriding these defaults in modules other modules depend on.

[jira-importer]

Joerg Schaible commented

I know, but if you set such defaults in a parent, you may deliberately overwrite it in a child. At least we do this in some special cases.

[jira-importer]

Christian Schulte commented

Can you please test if your dependency management is still working the same way with a recent 3.4.0-SNAPSHOT.

https://builds.apache.org/view/Maven/job/maven-master-release-status-build/

That snapshot contains a fix for MNG-5761. As long as you never add a dependency to something which has overridden the management, nothing should have changed. I fear those overrides stop working the way you are used to as soon as they become transitive dependencies somewhere. With this fix, Maven no longer ignores the transitive dependency management. That leads to the management overriding those overrides consistently also cross-reactor (issue described above).

[jira-importer]

Christian Schulte commented

FYI, that fix to MNG-5761 also fixes MNG-5708.

[jira-importer]

Curtis Rueden commented

I also ran into this issue, and posted an MCVE gist illustrating it. In my view, if a library L believes it depends on component X at a particular version, projects depending on L should also inherit component X at that same version. See also this SO post.

[jira-importer]

Christian Schulte commented

Joerg Schaible To not introduce any misunderstandings. This issue is about overriding dependency management locally within a module's <dependencies> section. Such overrides are only in effect locally during building the module and nowhere else - not even in the same reactor. See the attached example project. You could override the dependency management inside <dependencyManagement> in a consistent way, though.

[jira-importer]

Curtis Rueden commented

Hmm, I guess the issue I stumbled over is something different then? Sorry for the noise.

[jira-importer]

Joerg Schaible commented

Extended example, where

• parent inherits maven-parent and manages junit,
• module-1 overrides plexus-component-annotations (managed by maven-parent) and manages plexus-utils with a depMgmt section and
• a new module-3 (without a parent) using module-1.

[DEBUG] localhost:module-1:jar:1.0-SNAPSHOT
[DEBUG]    org.codehaus.plexus:plexus-component-annotations:jar:1.5.0:compile
[DEBUG]       junit:junit:jar:3.8.1:compile (version managed from 3.8.2 by localhost:parent:1.0-SNAPSHOT)
[DEBUG]    org.apache.maven:maven-plugin-api:jar:3.0:compile
[DEBUG]       org.apache.maven:maven-model:jar:3.0:compile
[DEBUG]          org.codehaus.plexus:plexus-utils:jar:2.0.7:compile (version managed from 2.0.4 by localhost:module-1:1.0-SNAPSHOT)
[DEBUG]       org.apache.maven:maven-artifact:jar:3.0:compile
[DEBUG]       org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile
[DEBUG]          org.codehaus.plexus:plexus-classworlds:jar:2.2.3:compile
[DEBUG]          org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile
[DEBUG]             org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile

Module-3 obviously uses wrong plexus-utils and junit versions, but at least the correct version of maven-plugin-api and plexus-component-annotations:

[DEBUG] localhost:module-3:jar:1.0-SNAPSHOT
[DEBUG]    localhost:module-1:jar:1.0-SNAPSHOT:compile
[DEBUG]       org.codehaus.plexus:plexus-component-annotations:jar:1.5.0:compile
[DEBUG]          junit:junit:jar:3.8.2:compile
[DEBUG]       org.apache.maven:maven-plugin-api:jar:3.0:compile
[DEBUG]          org.apache.maven:maven-model:jar:3.0:compile
[DEBUG]             org.codehaus.plexus:plexus-utils:jar:2.0.4:compile
[DEBUG]          org.apache.maven:maven-artifact:jar:3.0:compile
[DEBUG]          org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile
[DEBUG]             org.codehaus.plexus:plexus-classworlds:jar:2.2.3:compile
[DEBUG]             org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile
[DEBUG]                org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile

Generated with Maven 3.3.9.

If I understand you proposal now correctly, you would like to forbid the local overriding of maven-plugin-api, which is ignored for module-2, but respected for module-3. OTOH module-3 exposes different problems, since the active depMgmt sections of a dependency itself are not considered.

One use case, where I use a local overriding also actively, is for testing a different version of a dependency. Existing unit test may reveal a different behaviour.

[jira-importer]

Joerg Schaible commented

Updated example. Replaces MNG-6141-2.zip

[jira-importer]

Ralph Goers commented

Can't this be resolved just by adding the enforcer plugin to the build?

[jira-importer]

Christian Schulte commented

FWIW I put a lot of effort into sorting out things like this during development of Maven 3.4.0. Nearly a year of work. All of this effort has been reverted and the master branch got reset. Personally I am still using that Maven version, of course. It is behaving differently but in a way I (and the users having reported the issues in JIRA) expect Maven to behave by default. It is available in my forked Maven repository and Maven resolver repository on Github. I am keeping the version at 3.4.0-SNAPSHOT so to not introduce any confusion. You can also grab a binary release in case you are interested to see how your projects behave with quite a lot of issues resolved not released and never to be released because of corrections to dependency resolution changing behaviour. It includes fixes for what this issue is about. Using that Maven, I seldomly stumble upon projects running into such corner cases without noticing and help them fix things.