Maven 2 & 3
  1. Maven 2 & 3
  2. MNG-1577

dependencyManagement does not work for transitive dependencies

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0
    • Fix Version/s: 2.0.6
    • Labels:
      None
    • Complexity:
      Intermediate
    • Number of attachments :
      11

      Description

      The dependencyManagement does not work for transient dependencies. The specified version is ignored.

      Use case:
      Main POM defines commons-digester-1.6 and commons-beanutils-1.7.0, A-SNAPSHOT and B-SNAPSHOT
      Project A is child of Main and depends directly on commons-beanutils (version inherited from Main)
      Project B is child of Main and depends directly on commons-digester (version inherited from Main)
      Project C is child of Main and depends directly on A & B (versions inherited from Main)

      A is compiled and tests are run using commons-beanutils-1.7.0
      B is compiled and tests are run using commons-digester-1.6 and commons-beanutils-1.6, since digester is dependend on this
      C is compiled and tests are run using commons-beanutils-1.7.0

      Integration tests of B did not verify, that B is behaving as expected in this scenario. B might fail with 1.7.0 and it is not even recognized.

      If I add beanutils also as direct dependency to B, it works fine, but then are transitive dependency useless. It should be possible to define at least in the dependencyManagement, that the versions of transient dependencies also defined in the dependencyManagement have priority.

      • Jörg
      1. mng1577.patch
        15 kB
        Ralph Goers
      2. mng1577a.patch
        15 kB
      3. mng1577b.patch
        35 kB
        Ralph Goers
      4. mng1577c.patch
        36 kB
        Ralph Goers
      5. mng1577d.patch
        74 kB
        Ralph Goers
      6. mng1577e.patch
        75 kB
        Ralph Goers
      7. mng1577e-trunk.patch
        85 kB
        Ralph Goers
      8. mng1577f.patch
        107 kB
        Patrick Schneider
      9. mng1577trunk.patch
        45 kB
        Ralph Goers
      10. MNG-1577-trunk-final.patch
        131 kB
        Patrick Schneider
      11. site.patch
        6 kB
        Ralph Goers

        Issue Links

          Activity

          Hide
          Brett Porter added a comment -

          I think we determined this wasn't the behaviour that would be used (depMgmt only applying to the current project and inheritence) - need to review and confirm then close as won't fix, or fix for 2.0.1 if I'm wrong.

          Show
          Brett Porter added a comment - I think we determined this wasn't the behaviour that would be used (depMgmt only applying to the current project and inheritence) - need to review and confirm then close as won't fix, or fix for 2.0.1 if I'm wrong.
          Hide
          Jörg Schaible added a comment -

          Well, with M1 we used entities to ensure global version consistency among different projects. For M2 the dependencyManagement was presented as solution for this. If it is not DM, what can we use else?

          Show
          Jörg Schaible added a comment - Well, with M1 we used entities to ensure global version consistency among different projects. For M2 the dependencyManagement was presented as solution for this. If it is not DM, what can we use else?
          Hide
          Brett Porter added a comment -

          I think I agree, as otherwise its just including the dependency falsely to ensure it is managed - just need to check the original discussion.

          Show
          Brett Porter added a comment - I think I agree, as otherwise its just including the dependency falsely to ensure it is managed - just need to check the original discussion.
          Hide
          Carlos Sanchez added a comment -

          I think I agree too

          Show
          Carlos Sanchez added a comment - I think I agree too
          Hide
          Ralph Goers added a comment -

          Can you provide a link to the original discussion? I just cannot see how this behavior can be tolerated. Since almost every dependency at ibiblio is going to have transitive dependencies with versions in them not fixing this will effectively make transitive dependencies useless as most projects will end up with multiple versions of the same jars in them.

          Show
          Ralph Goers added a comment - Can you provide a link to the original discussion? I just cannot see how this behavior can be tolerated. Since almost every dependency at ibiblio is going to have transitive dependencies with versions in them not fixing this will effectively make transitive dependencies useless as most projects will end up with multiple versions of the same jars in them.
          Hide
          Carlos Sanchez added a comment -

          > "most projects will end up with multiple versions of the same jars in them."
          That's wrong. What can happen is that different projects will use different versions of the dependencies, but one project always uses one and only one version

          Show
          Carlos Sanchez added a comment - > "most projects will end up with multiple versions of the same jars in them." That's wrong. What can happen is that different projects will use different versions of the dependencies, but one project always uses one and only one version
          Hide
          Jörg Schaible added a comment -

          This depends. Think of jBoss with its unified classloader and an ear with two integrated wars. If each war has a dependency with a different version, both dependend jars will be in the classpath. It is pure coincidence which one is taken. This issue is therefore our showstopper in M102 to M2 migration.

          Show
          Jörg Schaible added a comment - This depends. Think of jBoss with its unified classloader and an ear with two integrated wars. If each war has a dependency with a different version, both dependend jars will be in the classpath. It is pure coincidence which one is taken. This issue is therefore our showstopper in M102 to M2 migration.
          Hide
          Jörg Schaible added a comment -

          Meanwhile we are hit by an even worse use case: EJBs! If you add the dependencies to the manifest's classpath, you don't have any control over the transient dependencies anymore. With two EJBs in the same EAR you have quite often the problem, that one of the EJBs is broken, since the two EJBs will refer the artifacts in different versions in their manifest, but the EAR contains naturally only one veriosn of it. This is meanwhile really a blocker for us!

          Show
          Jörg Schaible added a comment - Meanwhile we are hit by an even worse use case: EJBs! If you add the dependencies to the manifest's classpath, you don't have any control over the transient dependencies anymore. With two EJBs in the same EAR you have quite often the problem, that one of the EJBs is broken, since the two EJBs will refer the artifacts in different versions in their manifest, but the EAR contains naturally only one veriosn of it. This is meanwhile really a blocker for us!
          Hide
          Stephen Duncan Jr added a comment -

          Can someone change the description of this bug to say "transitive" instead of "transient"? That should make it easier to find...

          Show
          Stephen Duncan Jr added a comment - Can someone change the description of this bug to say "transitive" instead of "transient"? That should make it easier to find...
          Hide
          Jorg Heymans added a comment -

          and while you're at it change dependencyManagent into dependencyManagement in the title

          Show
          Jorg Heymans added a comment - and while you're at it change dependencyManagent into dependencyManagement in the title
          Hide
          Craig McClanahan added a comment -

          This issue messes up the Maven2 based Shale builds too. The bottom line is that it puts the stability of Shale builds totally at the mercy of the creators of downstream dependencies ... there is no current way to override those settings and say "darn it ... I don't care what you say, use this version of the "foo" depency.".

          Show
          Craig McClanahan added a comment - This issue messes up the Maven2 based Shale builds too. The bottom line is that it puts the stability of Shale builds totally at the mercy of the creators of downstream dependencies ... there is no current way to override those settings and say "darn it ... I don't care what you say, use this version of the "foo" depency.".
          Hide
          Mike Perham added a comment -

          I agree with Jorg and Craig. This would solve a lot of issues we are seeing in building our large system (40-50 modules) with Maven. All too often we need to custom craft each dependency's POM to standardize their versions on the versions we want to use.

          Show
          Mike Perham added a comment - I agree with Jorg and Craig. This would solve a lot of issues we are seeing in building our large system (40-50 modules) with Maven. All too often we need to custom craft each dependency's POM to standardize their versions on the versions we want to use.
          Hide
          Craig McClanahan added a comment -

          My recommended approach to this is to adjust the version conflict resolution algorithm used to calculate "distance" on the dependency graph. Currently, the algorithm treats a transitive dependency inherited from a declared dependency, and a dependency inherited from a parent POM, as being at the same distance. I would advocate that dependencies declared in a parent POM (either explicitly, or with just a version number in a <dependencyManagement> section) should be considered closer, and therefore override version declarations in the transitive dependencies.

          Show
          Craig McClanahan added a comment - My recommended approach to this is to adjust the version conflict resolution algorithm used to calculate "distance" on the dependency graph. Currently, the algorithm treats a transitive dependency inherited from a declared dependency, and a dependency inherited from a parent POM, as being at the same distance. I would advocate that dependencies declared in a parent POM (either explicitly, or with just a version number in a <dependencyManagement> section) should be considered closer, and therefore override version declarations in the transitive dependencies.
          Hide
          Nathan Beyer (Cerner) added a comment -

          +1 for Craig's suggestion. The deterministic and user-controlled resolution of dependencies is a must in developing and testing any complex system, especially those that depend on projects that may be out of a user's control, such as open-source projects.

          Show
          Nathan Beyer (Cerner) added a comment - +1 for Craig's suggestion. The deterministic and user-controlled resolution of dependencies is a must in developing and testing any complex system, especially those that depend on projects that may be out of a user's control, such as open-source projects.
          Hide
          ruel loehr added a comment -

          +1 as well. I need to ensure that I have dependable, reproducible build where I know for sure what dependency versions are being used. Craig's suggestion would solve this.

          Show
          ruel loehr added a comment - +1 as well. I need to ensure that I have dependable, reproducible build where I know for sure what dependency versions are being used. Craig's suggestion would solve this.
          Hide
          Mike Perham added a comment -

          I would also say that if the dependency resolution algorithm should pick the latest version if all else is the same. I can't tell you the number of times I've had to deal with versions going from e.g. 1.1.2 -> 1.1.1 due to some change. If A requires 1.1.1 and B requires 1.1.2, Maven should default to the latter.

          Show
          Mike Perham added a comment - I would also say that if the dependency resolution algorithm should pick the latest version if all else is the same. I can't tell you the number of times I've had to deal with versions going from e.g. 1.1.2 -> 1.1.1 due to some change. If A requires 1.1.1 and B requires 1.1.2, Maven should default to the latter.
          Hide
          Ralph Goers added a comment -

          Cocoon now has an issue at http://issues.apache.org/jira/browse/COCOON-1890 which is a hack to try to deal with this issue. This is getting out of hand.

          Show
          Ralph Goers added a comment - Cocoon now has an issue at http://issues.apache.org/jira/browse/COCOON-1890 which is a hack to try to deal with this issue. This is getting out of hand.
          Hide
          Brett Porter added a comment -

          thanks for all the comments. This is certainly a priority to "fix" in 2.1, but won't be able to be done before, since it really changes the behaviour. I think appropriate measures need to be taken to ensure we bump the POM revision and retain the current behaviour for existing projects as this could potentially break builds.

          Show
          Brett Porter added a comment - thanks for all the comments. This is certainly a priority to "fix" in 2.1, but won't be able to be done before, since it really changes the behaviour. I think appropriate measures need to be taken to ensure we bump the POM revision and retain the current behaviour for existing projects as this could potentially break builds.
          Hide
          Ralph Goers added a comment -

          Brett. This can easily be done without breaking compatibility. It wasn't too hard to figure out how to add an "override" child element to the dependencyManagement element. By using "false" as the default value for this compatibility is maintained. The problem I am having is in figuring out how to pass this flag to the artifact resolver since the dependency management object is converted into a simple Map.

          Show
          Ralph Goers added a comment - Brett. This can easily be done without breaking compatibility. It wasn't too hard to figure out how to add an "override" child element to the dependencyManagement element. By using "false" as the default value for this compatibility is maintained. The problem I am having is in figuring out how to pass this flag to the artifact resolver since the dependency management object is converted into a simple Map.
          Hide
          Ralph Goers added a comment -

          Attached is a patch that addresses this issue. Without doing anything maven will behave as it currently does. However, adding <override>true</override> to the dependencyManagement section will cause the dependencyManagement section to be propogated to each child project and the versions in the dependencyManagement entries will override any versions specified in subprojects.

          This patch applies to 2.0.x at revision 442440.

          Show
          Ralph Goers added a comment - Attached is a patch that addresses this issue. Without doing anything maven will behave as it currently does. However, adding <override>true</override> to the dependencyManagement section will cause the dependencyManagement section to be propogated to each child project and the versions in the dependencyManagement entries will override any versions specified in subprojects. This patch applies to 2.0.x at revision 442440.
          Hide
          Ralph Goers added a comment -

          uploaded mng1577a.patch. The only change from the original patch was to not have child projects override versions specified in parents.

          Show
          Ralph Goers added a comment - uploaded mng1577a.patch. The only change from the original patch was to not have child projects override versions specified in parents.
          Hide
          Mike Perham added a comment -

          Anyone tried the patch yet? I'm considering upgrading us to use a patched binary to get this fix.

          Show
          Mike Perham added a comment - Anyone tried the patch yet? I'm considering upgrading us to use a patched binary to get this fix.
          Hide
          Ralph Goers added a comment -

          Pleaes wait until the end of the week. It was requested that I provide unit tests along with the patch. I've had a little trouble with that as Maven without the patches doesn't seem to handle DependencyManagement as documented. I'm going to try to talk to some of the Maven committers at ApacheCon this week to see if I can't get this put to bed.

          Show
          Ralph Goers added a comment - Pleaes wait until the end of the week. It was requested that I provide unit tests along with the patch. I've had a little trouble with that as Maven without the patches doesn't seem to handle DependencyManagement as documented. I'm going to try to talk to some of the Maven committers at ApacheCon this week to see if I can't get this put to bed.
          Hide
          Ralph Goers added a comment -

          mng1577b.patch and mng1577trunk.patch were given to Jason at ApacheCon but are being uploaded here for completeness. They contain 2 unit tests. The first, which tests override enabled passes. The second, which attempts to verify that override doesn't change the existing behavior, fails. However, this same unit test fails on an unmodified version of maven, indicating that the current behavior of dependencyManagement doesn't work as documented.

          Show
          Ralph Goers added a comment - mng1577b.patch and mng1577trunk.patch were given to Jason at ApacheCon but are being uploaded here for completeness. They contain 2 unit tests. The first, which tests override enabled passes. The second, which attempts to verify that override doesn't change the existing behavior, fails. However, this same unit test fails on an unmodified version of maven, indicating that the current behavior of dependencyManagement doesn't work as documented.
          Hide
          Mike Perham added a comment -

          -1 on this patch as is.

          If I have a dep in the child POM:

          <dependency>
          <groupId>junit</groupId>
          <artifactId>junit</artifactId>
          <scope>compile</scope>
          </dependency>

          and a dep in depMgmt in the parent POM:

          <dependency>
          <groupId>junit</groupId>
          <artifactId>junit</artifactId>
          <version>3.8.1</version>
          <scope>test</scope>
          </dependency>

          It forces the dep to the 'test' scope despite the fact that the child requires it as compile. The child should always override everything else. WYSIWYG.

          Show
          Mike Perham added a comment - -1 on this patch as is. If I have a dep in the child POM: <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <scope>compile</scope> </dependency> and a dep in depMgmt in the parent POM: <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> It forces the dep to the 'test' scope despite the fact that the child requires it as compile. The child should always override everything else. WYSIWYG.
          Hide
          Mike Perham added a comment -

          I changed this in src/main/java/org/apache/maven/artifact/resolver/DefaultArtifactCollector.java

          • if ( artifact.getScope() != null )
            + if ( artifact.getScope() != null && node.getArtifact().getScope() == null )
            {
            node.getArtifact().setScope( artifact.getScope() );

          This fixed my problem above but it still does not work properly with transitive dependencies that are marked as optional. They become non-optional if listed in the dependency management section.

          A transitive dep has it marked as compile/optional whereas my depMgmt section has it marked as test/non-optional. At runtime this becomes compile/non-optional and gets included in my EAR.

          Also when I turn on <override>true</override>, my EAR build goes from 8 seconds to 40 seconds and my -X output goes from 170k to 9MB. I believe this is because it is parsing the same deps over and over, without caching intermediate results.

          IOW, this patch needs more work.

          Show
          Mike Perham added a comment - I changed this in src/main/java/org/apache/maven/artifact/resolver/DefaultArtifactCollector.java if ( artifact.getScope() != null ) + if ( artifact.getScope() != null && node.getArtifact().getScope() == null ) { node.getArtifact().setScope( artifact.getScope() ); This fixed my problem above but it still does not work properly with transitive dependencies that are marked as optional. They become non-optional if listed in the dependency management section. A transitive dep has it marked as compile/optional whereas my depMgmt section has it marked as test/non-optional. At runtime this becomes compile/non-optional and gets included in my EAR. Also when I turn on <override>true</override>, my EAR build goes from 8 seconds to 40 seconds and my -X output goes from 170k to 9MB. I believe this is because it is parsing the same deps over and over, without caching intermediate results. IOW, this patch needs more work.
          Hide
          Ralph Goers added a comment -

          Thanks for the feedback. I'll see if I can address these problems. Did you happen to create test cases that I can use?

          Show
          Ralph Goers added a comment - Thanks for the feedback. I'll see if I can address these problems. Did you happen to create test cases that I can use?
          Hide
          Ralph Goers added a comment -

          I've uploaded mng1557c.patch for maven-2.0.x. I updated the patch with these changes:
          1. The prior patch was creating a ManagedVersionMap several times for a project. Now it just does it once.
          2. If no dependencyManagement section is present then the parent ManagedVersionMap is used instead of creating a clone.
          3. If override is enabled then the scope in the dependencyManagement is not used at all (only the version is used). If override is false then it continues to override the scope for compatibility (although I can't imagine a case where this would be desirable).
          4. Dependencies in child dependencyManagement sections override their parents. However, managed dependencies specified in the project will override transitive dependencies even if they extend a pom containing the same managed dependency. This is the desired behavior.
          5. I tested building myfaces with an unmodifed maven, with override set to false and with override set to true and didn't see any real difference in cpu. The debug file is slightly larger due to a few extra debug log entries.

          Please test this again and provide feedback.

          Show
          Ralph Goers added a comment - I've uploaded mng1557c.patch for maven-2.0.x. I updated the patch with these changes: 1. The prior patch was creating a ManagedVersionMap several times for a project. Now it just does it once. 2. If no dependencyManagement section is present then the parent ManagedVersionMap is used instead of creating a clone. 3. If override is enabled then the scope in the dependencyManagement is not used at all (only the version is used). If override is false then it continues to override the scope for compatibility (although I can't imagine a case where this would be desirable). 4. Dependencies in child dependencyManagement sections override their parents. However, managed dependencies specified in the project will override transitive dependencies even if they extend a pom containing the same managed dependency. This is the desired behavior. 5. I tested building myfaces with an unmodifed maven, with override set to false and with override set to true and didn't see any real difference in cpu. The debug file is slightly larger due to a few extra debug log entries. Please test this again and provide feedback.
          Hide
          Ralph Goers added a comment -

          Well darn. Don't bother testing mng1577c yet. I created a unit test to test the optional/non-optional issue that was raised and it is failing. FWIW, it does exactly the same thing with an unmodified maven. I'll have to run this under the debugger and figure out where it is coming from as the current patch isn't doing anything with optional/non-optional.

          Show
          Ralph Goers added a comment - Well darn. Don't bother testing mng1577c yet. I created a unit test to test the optional/non-optional issue that was raised and it is failing. FWIW, it does exactly the same thing with an unmodified maven. I'll have to run this under the debugger and figure out where it is coming from as the current patch isn't doing anything with optional/non-optional.
          Hide
          Ralph Goers added a comment -

          After digging into it it turns out I just didn't understand the results I was seeing. I've added a few tests to test the optional/non-optional behavior, but otherwise the patch is the same. Please test this. I'll also try to create the patch for trunk.

          Show
          Ralph Goers added a comment - After digging into it it turns out I just didn't understand the results I was seeing. I've added a few tests to test the optional/non-optional behavior, but otherwise the patch is the same. Please test this. I'll also try to create the patch for trunk.
          Hide
          Sei Syvalta added a comment -

          One thing I noticed related to this: if I override a version in dependencies (not in dependencyManagement), the pom of the "incorrect" version is still needed. This might be a problem, if that "incorrent" version of the pom can't be downloaded. It would be good not to require and download it at all. This same thing would then be nice to have also this pluginmanagement fix.

          Show
          Sei Syvalta added a comment - One thing I noticed related to this: if I override a version in dependencies (not in dependencyManagement), the pom of the "incorrect" version is still needed. This might be a problem, if that "incorrent" version of the pom can't be downloaded. It would be good not to require and download it at all. This same thing would then be nice to have also this pluginmanagement fix.
          Hide
          Sei Syvalta added a comment -

          My opinion is that the scope should be also possible to override, because there are so many poms with invalid dependencies. Perhaps we need a second property overrideScope?

          Show
          Sei Syvalta added a comment - My opinion is that the scope should be also possible to override, because there are so many poms with invalid dependencies. Perhaps we need a second property overrideScope?
          Hide
          Mike Perham added a comment -

          Ralph, I'm starting to test d now. First thing I noticed about the d patch is that it has ^Ms in all the new files. I believe this is a no-no. Be careful with your line endings.

          Show
          Mike Perham added a comment - Ralph, I'm starting to test d now. First thing I noticed about the d patch is that it has ^Ms in all the new files. I believe this is a no-no. Be careful with your line endings.
          Hide
          Ralph Goers added a comment -

          Thanks, Mike. I upgraded to IntelliJ 6.0 and didn't check that setting. I'll make sure it is set as virtually everything requires it. I should have to corresponding patch for trunk done by tomorrow. Please let me know how your testing goes.

          Show
          Ralph Goers added a comment - Thanks, Mike. I upgraded to IntelliJ 6.0 and didn't check that setting. I'll make sure it is set as virtually everything requires it. I should have to corresponding patch for trunk done by tomorrow. Please let me know how your testing goes.
          Hide
          Mike Perham added a comment -

          Uh oh, the depMgmt scope in the parent POM is still overriding the scope given in the leaf POM. This is bad - the leaf should always be able to override its parents settings. The depMgmt settings should only override transitive deps or provide info that is not given in the leaf (like if the scope is not given in the leaf, it should default to the scope in the parent's depMgmt).

          And I'm testing against the 2.0.x branch so please target that code first if you are going to get me an updated patch.

          Show
          Mike Perham added a comment - Uh oh, the depMgmt scope in the parent POM is still overriding the scope given in the leaf POM. This is bad - the leaf should always be able to override its parents settings. The depMgmt settings should only override transitive deps or provide info that is not given in the leaf (like if the scope is not given in the leaf, it should default to the scope in the parent's depMgmt). And I'm testing against the 2.0.x branch so please target that code first if you are going to get me an updated patch.
          Hide
          Ralph Goers added a comment -

          Mike,

          I suspect the behavior you are reporting is not part of the patch, but is part of how the pom's extend each other. In other words, I believe you will find that you get the same behavior without this patch applied. As part of my debugging I've noticed that every project that inherits from a parent has the dependencyManagement of its parent (plus whatever managed dependencies it introduces, if any). At first I was surprised by this but after thinking about it it made sense to me. However, since the code in my patch is simply taking the dependencyManagement that is provided and then is creating a ManagedVersionMap I've never investigated as to whether the dependencyManagement object was created correctly.

          I've noticed other behaviors that are a bit odd. While trying to create unit tests I noticed that if a dependency did not have a version then all dependency versions in that project seemed to be overridden from the dependencyManagement version. If all dependencies had a version then none of the dependencies were overridden. I was only expecting the one dependency to have been affected.

          I'll be happy to go on and try to figure out how to fix the behavior you've noted, but I don't think it should keep the patch from being applied as it is since I don't think it is breaking anything that isn't already broken. In fact, I've tried to keep all the broken behavior intact with override set to false in order to maintain backward compatibility.

          Show
          Ralph Goers added a comment - Mike, I suspect the behavior you are reporting is not part of the patch, but is part of how the pom's extend each other. In other words, I believe you will find that you get the same behavior without this patch applied. As part of my debugging I've noticed that every project that inherits from a parent has the dependencyManagement of its parent (plus whatever managed dependencies it introduces, if any). At first I was surprised by this but after thinking about it it made sense to me. However, since the code in my patch is simply taking the dependencyManagement that is provided and then is creating a ManagedVersionMap I've never investigated as to whether the dependencyManagement object was created correctly. I've noticed other behaviors that are a bit odd. While trying to create unit tests I noticed that if a dependency did not have a version then all dependency versions in that project seemed to be overridden from the dependencyManagement version. If all dependencies had a version then none of the dependencies were overridden. I was only expecting the one dependency to have been affected. I'll be happy to go on and try to figure out how to fix the behavior you've noted, but I don't think it should keep the patch from being applied as it is since I don't think it is breaking anything that isn't already broken. In fact, I've tried to keep all the broken behavior intact with override set to false in order to maintain backward compatibility.
          Hide
          Mike Perham added a comment -

          Ralph, I tried plain 2.0.x HEAD this weekend and it does not fail with the scope issue I noted. So I would assume that the issue is in your patch.

          Show
          Mike Perham added a comment - Ralph, I tried plain 2.0.x HEAD this weekend and it does not fail with the scope issue I noted. So I would assume that the issue is in your patch.
          Hide
          Ralph Goers added a comment -

          I've uploaded a new patch file for both 2.0.x and trunk. The basic patch is unchanged however the t04 and t05 tests have been modified to verify that the scope is set to the correct value. t04 runs with override=true and so fails against an unpatched trunk (even if the override element is removed). t05 runs with override=false and will produce the same result when run on an unpatched trunk.

          In short, these tests indicate that the patch is behaving correctly.

          Show
          Ralph Goers added a comment - I've uploaded a new patch file for both 2.0.x and trunk. The basic patch is unchanged however the t04 and t05 tests have been modified to verify that the scope is set to the correct value. t04 runs with override=true and so fails against an unpatched trunk (even if the override element is removed). t05 runs with override=false and will produce the same result when run on an unpatched trunk. In short, these tests indicate that the patch is behaving correctly.
          Hide
          Patrick Schneider added a comment -

          Hi all – Just a quick note to let everyone know that I am working on this issue as well – currently, I'm looking at the e patch for 2.0.x. I have a strong interest in and fair amount of bandwidth for getting this issue resolved, so feel free to contact me or whatever.

          Show
          Patrick Schneider added a comment - Hi all – Just a quick note to let everyone know that I am working on this issue as well – currently, I'm looking at the e patch for 2.0.x. I have a strong interest in and fair amount of bandwidth for getting this issue resolved, so feel free to contact me or whatever.
          Hide
          Barrie Treloar added a comment -

          Given the long list of comments and the potential hurdles raised in them, is there any direction on the proposed solutions to the problem so far?

          Show
          Barrie Treloar added a comment - Given the long list of comments and the potential hurdles raised in them, is there any direction on the proposed solutions to the problem so far?
          Hide
          Patrick Schneider added a comment -

          Here is an updated version of mng1577e.patch for the 2.0.x branch. It addresses not being able to bootstrap once the patch has been applied. (Some inheritance tests, added by the patch, were not finding their dependency jars.)

          Show
          Patrick Schneider added a comment - Here is an updated version of mng1577e.patch for the 2.0.x branch. It addresses not being able to bootstrap once the patch has been applied. (Some inheritance tests, added by the patch, were not finding their dependency jars.)
          Hide
          Ralph Goers added a comment -

          Patch to the maven web site to document the new behavior.

          Show
          Ralph Goers added a comment - Patch to the maven web site to document the new behavior.
          Hide
          Jason van Zyl added a comment -

          Patch applied, thanks Ralph.

          Show
          Jason van Zyl added a comment - Patch applied, thanks Ralph.
          Hide
          Patrick Schneider added a comment -

          This is the 1577 2.0.x patch ported so it will cleanly apply to the trunk @ rev 520633. Unit tests had to be refactored such that artifact names are unique. Verified that transitive deps are resolved correctly using the same small smoke tests and one large build that were tested for the the 2.0.x patch.

          Show
          Patrick Schneider added a comment - This is the 1577 2.0.x patch ported so it will cleanly apply to the trunk @ rev 520633. Unit tests had to be refactored such that artifact names are unique. Verified that transitive deps are resolved correctly using the same small smoke tests and one large build that were tested for the the 2.0.x patch.
          Hide
          Jason van Zyl added a comment -

          Thanks, patch applied on trunk.

          Show
          Jason van Zyl added a comment - Thanks, patch applied on trunk.

            People

            • Assignee:
              Jason van Zyl
              Reporter:
              Jörg Schaible
            • Votes:
              38 Vote for this issue
              Watchers:
              34 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: