Maven
  1. Maven
  2. MNG-2794

Transitive dependency resolution differs between 2.0.4 and (future) 2.0.5

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.0.5
    • Fix Version/s: 2.0.5
    • Component/s: Dependencies
    • Labels:
      None
    • Complexity:
      Intermediate
    • Number of attachments :
      1

      Description

      Say you have a project that has 3 dependecies A, B and C, amongst which 2 of them have a dependency D but with a different version:
      A -> D v2.1
      B -> D v3
      C (has no transitive dependency to D)
      In the project, you call a class that exists in D v3 but not in D v2.1.

      -> If you launch "mvn clean compile" with M2.0.4, the build is successful, but not with M2.0.5.

      And the most surprising: if you remove dependency C, then both builds break...

      I attached a test project that reproduces the bug.

        Issue Links

          Activity

          Fabrice Bellingard made changes -
          Field Original Value New Value
          Summary Transitive dependency resolution differs between 2.0.4 and 2.0.5 Transitive dependency resolution differs between 2.0.4 and (future) 2.0.5
          Fabrice Bellingard made changes -
          Affects Version/s 2.0.4 [ 12527 ]
          Affects Version/s 2.0.5 [ 12294 ]
          Emmanuel Venisse made changes -
          Fix Version/s 2.0.5 [ 12294 ]
          Hide
          nicolas de loof added a comment -

          Maven 2.0.4 uses the "nearest" strategy to solve dependency conflicts, so the issue
          "
          project depends on A -> D-v2
          project depends on B -> D-v3
          "

          has no determinist solution about what version of D will be transitively used. Having this work in maven 2.0.4 in some circonstances is only beeing lucky. If your project depends on classes from D v3, you should declare it as a dependency to solve the conflict.

          there is some plan to enhance the resolution strategy with (http://docs.codehaus.org/display/MAVENUSER/Improving+Maven2+Dependency+Resolution)
          but AFAIK the target is maven 2.1.

          Show
          nicolas de loof added a comment - Maven 2.0.4 uses the "nearest" strategy to solve dependency conflicts, so the issue " project depends on A -> D-v2 project depends on B -> D-v3 " has no determinist solution about what version of D will be transitively used. Having this work in maven 2.0.4 in some circonstances is only beeing lucky. If your project depends on classes from D v3, you should declare it as a dependency to solve the conflict. there is some plan to enhance the resolution strategy with ( http://docs.codehaus.org/display/MAVENUSER/Improving+Maven2+Dependency+Resolution ) but AFAIK the target is maven 2.1.
          Hide
          Rodrigo Ruiz added a comment -

          Hi Nicolas,

          So, the problem is that Maven 2.0.4 and 2.0.5 bahave different when the dependency information has errors!? If the "workaround" is to correct the POM, shouldn't this be a "will not be resolved" case?

          Show
          Rodrigo Ruiz added a comment - Hi Nicolas, So, the problem is that Maven 2.0.4 and 2.0.5 bahave different when the dependency information has errors!? If the "workaround" is to correct the POM, shouldn't this be a "will not be resolved" case?
          Hide
          Herve Boutemy added a comment -

          As explained in http://www.nabble.com/Re%3A--VOTE--Release-Maven-2.0.5-p8382858s177.html :
          > IIRC, Maven 2.0.4's behavior with two versions of the same dependency
          > at the same depth was undefined. Now, it's supposed to be
          > predictable.
          > IIRC, the order in which dependencies are declared effectively becomes the
          > tie-breaker when two dependency versions are declared at the same depth...

          The case explained here seems to be affected by this precise dependency resolution change.
          The fact that removing dependency on C breaks M2.0.4 build shows that M2.0.4 behaviour was really problematic !

          But all this information is taken from a mailing list, referring to "IIRC" : I don't know who can confirm the information and close this issue.
          And ideally give us stable pointers to some documentation or issue, since this case will probably occur to other people when then switch from M2.0.4 to M2.0.5...

          Show
          Herve Boutemy added a comment - As explained in http://www.nabble.com/Re%3A--VOTE--Release-Maven-2.0.5-p8382858s177.html : > IIRC, Maven 2.0.4's behavior with two versions of the same dependency > at the same depth was undefined. Now, it's supposed to be > predictable. > IIRC, the order in which dependencies are declared effectively becomes the > tie-breaker when two dependency versions are declared at the same depth... The case explained here seems to be affected by this precise dependency resolution change. The fact that removing dependency on C breaks M2.0.4 build shows that M2.0.4 behaviour was really problematic ! But all this information is taken from a mailing list, referring to "IIRC" : I don't know who can confirm the information and close this issue. And ideally give us stable pointers to some documentation or issue, since this case will probably occur to other people when then switch from M2.0.4 to M2.0.5...
          Hide
          Jason van Zyl added a comment -

          After looking at this specific case, you are doing something that we do not recommend. If the project you are working has a direct dependency which you require for compilation then you should be specifying it. I realize something has changed, but you should be specifying. And the behavior in 2.0.5 is actually more correct according to our select the nearest strategy. If you rearrange the dependencies and put the dependency that has a dependency on commons-collections 3.0 then the builds works fine.

          Show
          Jason van Zyl added a comment - After looking at this specific case, you are doing something that we do not recommend. If the project you are working has a direct dependency which you require for compilation then you should be specifying it. I realize something has changed, but you should be specifying. And the behavior in 2.0.5 is actually more correct according to our select the nearest strategy. If you rearrange the dependencies and put the dependency that has a dependency on commons-collections 3.0 then the builds works fine.
          Hide
          Jason van Zyl added a comment -

          The behavior in 2.0.5 is correct and is the behavior we actually have documented.

          Show
          Jason van Zyl added a comment - The behavior in 2.0.5 is correct and is the behavior we actually have documented.
          Jason van Zyl made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Resolution Won't Fix [ 2 ]
          Hide
          Herve Boutemy added a comment -

          http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html update is already scheduled when M2.0.5 will be released ?
          Or should I open a separate issue ?

          Show
          Herve Boutemy added a comment - http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html update is already scheduled when M2.0.5 will be released ? Or should I open a separate issue ?
          Herve Boutemy made changes -
          Link This issue relates to MNG-2832 [ MNG-2832 ]

            People

            • Assignee:
              Unassigned
              Reporter:
              Fabrice Bellingard
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: