[
https://issues.apache.org/jira/browse/MNG-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787063#comment-17787063
]
Herve Boutemy commented on MNG-7906:
------------------------------------
MPH-183 is a first step: be able to know where the effective import comes from
then on the dedupe algorithm and clarification, we'll be able to discuss:
[~aalmiray] is doing a series of talks in many conferences for 1 or 2 years on
Maven Dependency surprises, we should probably ask him to share his examples so
we can improve explanations and feedback when building
on this notion of "closer", we need to define that it means depth first then
order
once we explicit that, in the case of dependencyManagement, there is no depth,
then there is only order: that's the same, just a notion that de-facto does not
exist
When I saw Andres talk first, I found that most cases he reported were due to
cases like that: no clarity on what a vague term like "closer" means, then
surprises when trying to apply in a context that has different initial facts.
But no rush on conclusions, let's go step by step on this dependencyManagement
import clarification (and I have to fight against saying "dependency import",
because dependencyManagement is fundamentally different from dependency: there
is no transitivity, then no depth, then consequences)
> Dependency Management import does not work the "maven way"
> ----------------------------------------------------------
>
> Key: MNG-7906
> URL: https://issues.apache.org/jira/browse/MNG-7906
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
> Reporter: Tamas Cservenak
> Priority: Blocker
> Fix For: 4.0.x-candidate
>
>
> This affects all released Maven versions so far.
> Problem reproducer: https://github.com/cstamas/MNG-7852 (repo name is wrong,
> obviously).
> In short: unlike with dependencies, where you CAN override some "deep
> transitive" dependency by re-declaring it directly as 1st level dependency in
> POM, for depMgt import this does not work, actually, it works quite the
> opposite ("first comes, wins"). Moreover, Maven remains silent about this, as
> reproducer shows, and all of this goes unnoticed.
> Solution: at least depMgt import should make "the maven way", maybe not by
> default (to not break existing builds) but configurable. Problem is solved if
> in reproducer:
> - with fix enabled, junit 5.9.3 is used, AND
> - with fix disabled, Maven yells about ignored depMgt import
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
