[jira] [Comment Edited] (MNG-6141) Dependency management overrides are not transitive and should be considered an anti-pattern.
[
https://issues.apache.org/jira/browse/MNG-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16267225#comment-16267225
]
Curtis Rueden edited comment on MNG-6141 at 11/27/17 6:41 PM:
--
It would be a shame indeed for that work to be lost. But my understanding was
that these patches were going to be cherry-picked into future releases, no?
was (Author: ctrueden):
It would be a shame indeed for that work to be lost. But my understanding is
that these patches were going to be cherry-picked into future releases, no?
> Dependency management overrides are not transitive and should be considered
> an anti-pattern.
>
>
> Key: MNG-6141
> URL: https://issues.apache.org/jira/browse/MNG-6141
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Priority: Critical
> Attachments: MNG-6141-3.zip, MNG-6141.zip
>
>
> Overriding the dependency management in a module's {{}}
> 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 {{}} 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.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MNG-6141) Dependency management overrides are not transitive and should be considered an anti-pattern.
[
https://issues.apache.org/jira/browse/MNG-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216635#comment-16216635
]
Joerg Schaible edited comment on MNG-6141 at 10/24/17 10:08 AM:
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.
{code:title=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
{code}
Module-3 obviously uses wrong plexus-utils and junit versions, but at least the
correct version of maven-plugin-api and plexus-component-annotations:
{code:title=Module 3}
[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
{code}
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.
was (Author: joehni):
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.
{code:title=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
{code}
Module-3 obviously uses wrong plexus-utils and junit versions, but at least the
correct version of maven-plugin-api:
{code:title=Module 3}
[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
{code}
Generated with Maven 3.3.9.
If I understand you proposal now
[jira] [Comment Edited] (MNG-6141) Dependency management overrides are not transitive and should be considered an anti-pattern.
[
https://issues.apache.org/jira/browse/MNG-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15785896#comment-15785896
]
Christian Schulte edited comment on MNG-6141 at 12/29/16 7:08 PM:
--
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).
{code:title=mvn -v}
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"
{code}
{code:title=module-1 CollectResult}
[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]
{code}
{code:title=module-2 CollectResult}
[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)
{code}
was (Author: schulte77):
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).
{code:title=module-1 CollectResult}
[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]
{code}
{code:title=module-2 CollectResult}
[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)
{code}
> Dependency management overrides are not transitive and should be considered
> an anti-pattern.
>
>
> Key: MNG-6141
> URL: https://issues.apache.org/jira/browse/MNG-6141
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Critical
> Attachments: MNG-6141.zip
>
>
> Overriding the dependency management in a module, 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 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 without noticing this is not supported transitively.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
