You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Paolo Compieta (JIRA)" <ji...@codehaus.org> on 2009/11/19 16:42:55 UTC
[jira] Created: (MDEP-243) dependency:resolve decides to take older
(incompatible) version for transitive dep
dependency:resolve decides to take older (incompatible) version for transitive dep
----------------------------------------------------------------------------------
Key: MDEP-243
URL: http://jira.codehaus.org/browse/MDEP-243
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: resolve, tree
Affects Versions: 2.1, 2.0
Environment: WinXp
Maven 2.0.9/2.2.1
Reporter: Paolo Compieta
Assignee: Brian Fox
Attachments: m2WrongTransitiveDepResolve.zip
I'll use modules Parent,ModuleA,ModuleB,ModuleEAR and dependency Commons-Net to explain the case.
Parent specifies commons-net/1.3.0 in dependencyManagement
\- ModuleB declares commons-net/1.4.1 as dependency (overrides version), and resolves correctly 1.4.1
\- ModuleA declares ModuleB as dependency (obtaining transitive dep to commons-net), and resolves *erroneously* 1.3.0
\- ModuleC (ear) takes in 1.3.0 whilst no module is actually using or declaring it
I'd expect this case to resolve 1.4.1 or at least to fail the build, because in this example B is the only one using commons-net (maybe exploiting 1.4.1-only features), while the final build resolves 1.3.0 (see ModuleA or ModuleC).
I'm not 100% which is the best policy, but i've got problems (wrong jars, different behaviours and runtime errors) with this kind silent down-resolution of version.
Regards,
Paolo
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNG-4457) dependency:resolve decides to take
older (incompatible) version for transitive dep
Posted by "Paolo Compieta (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paolo Compieta reopened MNG-4457:
---------------------------------
I agree with MNG-1577, but there are a few differences here, so i'm kindly asking more clarifications.
1) *no one* is using 1.3.0 in the build, but Maven resolves 1.3.0 -could we point this out during the build or better manage this case?
2) Maven chooses the *older* version (not a newer one) while B is declaring a *direct dep* with an *explicit,newer* version -could we could point this out with a short message? [also a short hint in the dep resolution phase would be ok: "some deps older than requested"]
3) why is A's-transitive-older-managed-dep winning over B's direct-dep? Is this right?
Regarding point 3), i could agree if there were (another) ModuleD with direct-dep inheriting version 1.3.0 from parent: in this case, resolving 1.3.0 instead of 1.4.1 would be fair (see attached example).
> dependency:resolve decides to take older (incompatible) version for transitive dep
> ----------------------------------------------------------------------------------
>
> Key: MNG-4457
> URL: http://jira.codehaus.org/browse/MNG-4457
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
> Affects Versions: 2.2.1
> Environment: WinXp
> Maven 2.0.9/2.2.1
> Reporter: Paolo Compieta
> Assignee: Brian Fox
> Attachments: m2FairTransitiveDepResolve.zip, m2WrongTransitiveDepResolve.zip
>
>
> I'll use modules Parent,ModuleA,ModuleB,ModuleEAR and dependency Commons-Net to explain the case.
> Parent specifies commons-net/1.3.0 in dependencyManagement
> \- ModuleB declares commons-net/1.4.1 as dependency (overrides version), and resolves correctly 1.4.1
> \- ModuleA declares ModuleB as dependency (obtaining transitive dep to commons-net), and resolves *erroneously* 1.3.0
> \- ModuleC (ear) takes in 1.3.0 whilst no module is actually using or declaring it
> I'd expect this case to resolve 1.4.1 or at least to fail the build, because in this example B is the only one using commons-net (maybe exploiting 1.4.1-only features), while the final build resolves 1.3.0 (see ModuleA or ModuleC).
> I'm not 100% which is the best policy, but i've got problems (wrong jars, different behaviours and runtime errors) with this kind silent down-resolution of version.
> Regards,
> Paolo
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-243) dependency:resolve decides to take
older (incompatible) version for transitive dep
Posted by "Joerg Schaible (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MDEP-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=198731#action_198731 ]
Joerg Schaible commented on MDEP-243:
-------------------------------------
This works exactly as defined. The depMgmt section is used to override even transitive deps.
> dependency:resolve decides to take older (incompatible) version for transitive dep
> ----------------------------------------------------------------------------------
>
> Key: MDEP-243
> URL: http://jira.codehaus.org/browse/MDEP-243
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: resolve, tree
> Affects Versions: 2.0, 2.1
> Environment: WinXp
> Maven 2.0.9/2.2.1
> Reporter: Paolo Compieta
> Assignee: Brian Fox
> Attachments: m2WrongTransitiveDepResolve.zip
>
>
> I'll use modules Parent,ModuleA,ModuleB,ModuleEAR and dependency Commons-Net to explain the case.
> Parent specifies commons-net/1.3.0 in dependencyManagement
> \- ModuleB declares commons-net/1.4.1 as dependency (overrides version), and resolves correctly 1.4.1
> \- ModuleA declares ModuleB as dependency (obtaining transitive dep to commons-net), and resolves *erroneously* 1.3.0
> \- ModuleC (ear) takes in 1.3.0 whilst no module is actually using or declaring it
> I'd expect this case to resolve 1.4.1 or at least to fail the build, because in this example B is the only one using commons-net (maybe exploiting 1.4.1-only features), while the final build resolves 1.3.0 (see ModuleA or ModuleC).
> I'm not 100% which is the best policy, but i've got problems (wrong jars, different behaviours and runtime errors) with this kind silent down-resolution of version.
> Regards,
> Paolo
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4457) dependency:resolve decides to take older
(incompatible) version for transitive dep
Posted by "Paolo Compieta (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paolo Compieta updated MNG-4457:
--------------------------------
Attachment: m2FairTransitiveDepResolve.zip
> dependency:resolve decides to take older (incompatible) version for transitive dep
> ----------------------------------------------------------------------------------
>
> Key: MNG-4457
> URL: http://jira.codehaus.org/browse/MNG-4457
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
> Affects Versions: 2.2.1
> Environment: WinXp
> Maven 2.0.9/2.2.1
> Reporter: Paolo Compieta
> Assignee: Brian Fox
> Attachments: m2FairTransitiveDepResolve.zip, m2WrongTransitiveDepResolve.zip
>
>
> I'll use modules Parent,ModuleA,ModuleB,ModuleEAR and dependency Commons-Net to explain the case.
> Parent specifies commons-net/1.3.0 in dependencyManagement
> \- ModuleB declares commons-net/1.4.1 as dependency (overrides version), and resolves correctly 1.4.1
> \- ModuleA declares ModuleB as dependency (obtaining transitive dep to commons-net), and resolves *erroneously* 1.3.0
> \- ModuleC (ear) takes in 1.3.0 whilst no module is actually using or declaring it
> I'd expect this case to resolve 1.4.1 or at least to fail the build, because in this example B is the only one using commons-net (maybe exploiting 1.4.1-only features), while the final build resolves 1.3.0 (see ModuleA or ModuleC).
> I'm not 100% which is the best policy, but i've got problems (wrong jars, different behaviours and runtime errors) with this kind silent down-resolution of version.
> Regards,
> Paolo
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4457) dependency:resolve decides to take
older (incompatible) version for transitive dep
Posted by "Paolo Compieta (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=198817#action_198817 ]
Paolo Compieta commented on MNG-4457:
-------------------------------------
1) ok
2) ok
3) i added C only in the second example, to show a 'normal' (IMO) resolution to 1.3.0; in the first example there were only A and B, and Maven didn't pick the closest
I still see this last case as a problem:
- A resolves 1.3.0 via B via DepMgmt, 2 hops
- B has 1.4.1, 1 hop
So, should B win? (case: m2WrongTransitiveDepResolve.zip)
If no, i agree to close this issue.
> dependency:resolve decides to take older (incompatible) version for transitive dep
> ----------------------------------------------------------------------------------
>
> Key: MNG-4457
> URL: http://jira.codehaus.org/browse/MNG-4457
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
> Affects Versions: 2.2.1
> Environment: WinXp
> Maven 2.0.9/2.2.1
> Reporter: Paolo Compieta
> Assignee: Brian Fox
> Attachments: m2FairTransitiveDepResolve.zip, m2WrongTransitiveDepResolve.zip
>
>
> I'll use modules Parent,ModuleA,ModuleB,ModuleEAR and dependency Commons-Net to explain the case.
> Parent specifies commons-net/1.3.0 in dependencyManagement
> \- ModuleB declares commons-net/1.4.1 as dependency (overrides version), and resolves correctly 1.4.1
> \- ModuleA declares ModuleB as dependency (obtaining transitive dep to commons-net), and resolves *erroneously* 1.3.0
> \- ModuleC (ear) takes in 1.3.0 whilst no module is actually using or declaring it
> I'd expect this case to resolve 1.4.1 or at least to fail the build, because in this example B is the only one using commons-net (maybe exploiting 1.4.1-only features), while the final build resolves 1.3.0 (see ModuleA or ModuleC).
> I'm not 100% which is the best policy, but i've got problems (wrong jars, different behaviours and runtime errors) with this kind silent down-resolution of version.
> Regards,
> Paolo
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-4457) dependency:resolve decides
to take older (incompatible) version for transitive dep
Posted by "Paolo Compieta (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=198817#action_198817 ]
Paolo Compieta edited comment on MNG-4457 at 11/20/09 5:14 AM:
---------------------------------------------------------------
1) ok
2) ok
3) i added C only in the second example, to show a 'normal' (IMO) resolution to 1.3.0; in the first example there were only A and B, and Maven didn't pick the closest
I still see this last case as a problem:
- A resolves 1.3.0 via B via DepMgmt, 2 hops
- B has 1.4.1, 1 hop
So, should B win? (case: m2WrongTransitiveDepResolve.zip)
If no, i agree to close this issue.
was (Author: paolo.compieta):
1) ok
2) ok
3) i added C only in the second example, to show a 'normal' (IMO) resolution to 1.3.0; in the first example there were only A and B, and Maven didn't pick the closest
I still see this last case as a problem:
- A resolves 1.3.0 via B via DepMgmt, 2 hops
- B has 1.4.1, 1 hop
So, should B win? (case: m2WrongTransitiveDepResolve.zip)
If no, i agree to close this issue.
> dependency:resolve decides to take older (incompatible) version for transitive dep
> ----------------------------------------------------------------------------------
>
> Key: MNG-4457
> URL: http://jira.codehaus.org/browse/MNG-4457
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
> Affects Versions: 2.2.1
> Environment: WinXp
> Maven 2.0.9/2.2.1
> Reporter: Paolo Compieta
> Assignee: Brian Fox
> Attachments: m2FairTransitiveDepResolve.zip, m2WrongTransitiveDepResolve.zip
>
>
> I'll use modules Parent,ModuleA,ModuleB,ModuleEAR and dependency Commons-Net to explain the case.
> Parent specifies commons-net/1.3.0 in dependencyManagement
> \- ModuleB declares commons-net/1.4.1 as dependency (overrides version), and resolves correctly 1.4.1
> \- ModuleA declares ModuleB as dependency (obtaining transitive dep to commons-net), and resolves *erroneously* 1.3.0
> \- ModuleC (ear) takes in 1.3.0 whilst no module is actually using or declaring it
> I'd expect this case to resolve 1.4.1 or at least to fail the build, because in this example B is the only one using commons-net (maybe exploiting 1.4.1-only features), while the final build resolves 1.3.0 (see ModuleA or ModuleC).
> I'm not 100% which is the best policy, but i've got problems (wrong jars, different behaviours and runtime errors) with this kind silent down-resolution of version.
> Regards,
> Paolo
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-4457) dependency:resolve decides to take older
(incompatible) version for transitive dep
Posted by "Brian Fox (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brian Fox closed MNG-4457.
--------------------------
Resolution: Not A Bug
The bug appears to describe that MNG-1577 is working as intended.
> dependency:resolve decides to take older (incompatible) version for transitive dep
> ----------------------------------------------------------------------------------
>
> Key: MNG-4457
> URL: http://jira.codehaus.org/browse/MNG-4457
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
> Affects Versions: 2.2.1
> Environment: WinXp
> Maven 2.0.9/2.2.1
> Reporter: Paolo Compieta
> Assignee: Brian Fox
> Attachments: m2WrongTransitiveDepResolve.zip
>
>
> I'll use modules Parent,ModuleA,ModuleB,ModuleEAR and dependency Commons-Net to explain the case.
> Parent specifies commons-net/1.3.0 in dependencyManagement
> \- ModuleB declares commons-net/1.4.1 as dependency (overrides version), and resolves correctly 1.4.1
> \- ModuleA declares ModuleB as dependency (obtaining transitive dep to commons-net), and resolves *erroneously* 1.3.0
> \- ModuleC (ear) takes in 1.3.0 whilst no module is actually using or declaring it
> I'd expect this case to resolve 1.4.1 or at least to fail the build, because in this example B is the only one using commons-net (maybe exploiting 1.4.1-only features), while the final build resolves 1.3.0 (see ModuleA or ModuleC).
> I'm not 100% which is the best policy, but i've got problems (wrong jars, different behaviours and runtime errors) with this kind silent down-resolution of version.
> Regards,
> Paolo
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-243) dependency:resolve decides to take
older (incompatible) version for transitive dep
Posted by "Brian Fox (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MDEP-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=198732#action_198732 ]
Brian Fox commented on MDEP-243:
--------------------------------
This isn't dependency plugin functionality, it's core.
However what you describe is correct. From Module A's point of view, the dependencyManagement overrides the transitive dependency version of 1.3.0.
See MNG-1577 for more information.
> dependency:resolve decides to take older (incompatible) version for transitive dep
> ----------------------------------------------------------------------------------
>
> Key: MDEP-243
> URL: http://jira.codehaus.org/browse/MDEP-243
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: Artifacts and Repositories
> Affects Versions: 2.2.1
> Environment: WinXp
> Maven 2.0.9/2.2.1
> Reporter: Paolo Compieta
> Assignee: Brian Fox
> Attachments: m2WrongTransitiveDepResolve.zip
>
>
> I'll use modules Parent,ModuleA,ModuleB,ModuleEAR and dependency Commons-Net to explain the case.
> Parent specifies commons-net/1.3.0 in dependencyManagement
> \- ModuleB declares commons-net/1.4.1 as dependency (overrides version), and resolves correctly 1.4.1
> \- ModuleA declares ModuleB as dependency (obtaining transitive dep to commons-net), and resolves *erroneously* 1.3.0
> \- ModuleC (ear) takes in 1.3.0 whilst no module is actually using or declaring it
> I'd expect this case to resolve 1.4.1 or at least to fail the build, because in this example B is the only one using commons-net (maybe exploiting 1.4.1-only features), while the final build resolves 1.3.0 (see ModuleA or ModuleC).
> I'm not 100% which is the best policy, but i've got problems (wrong jars, different behaviours and runtime errors) with this kind silent down-resolution of version.
> Regards,
> Paolo
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MNG-4457) dependency:resolve decides to take older
(incompatible) version for transitive dep
Posted by "Brian Fox (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brian Fox moved MDEP-243 to MNG-4457:
-------------------------------------
Complexity: Intermediate
Component/s: (was: tree)
(was: resolve)
Artifacts and Repositories
Affects Version/s: (was: 2.1)
(was: 2.0)
2.2.1
Key: MNG-4457 (was: MDEP-243)
Project: Maven 2 (was: Maven 2.x Dependency Plugin)
> dependency:resolve decides to take older (incompatible) version for transitive dep
> ----------------------------------------------------------------------------------
>
> Key: MNG-4457
> URL: http://jira.codehaus.org/browse/MNG-4457
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
> Affects Versions: 2.2.1
> Environment: WinXp
> Maven 2.0.9/2.2.1
> Reporter: Paolo Compieta
> Assignee: Brian Fox
> Attachments: m2WrongTransitiveDepResolve.zip
>
>
> I'll use modules Parent,ModuleA,ModuleB,ModuleEAR and dependency Commons-Net to explain the case.
> Parent specifies commons-net/1.3.0 in dependencyManagement
> \- ModuleB declares commons-net/1.4.1 as dependency (overrides version), and resolves correctly 1.4.1
> \- ModuleA declares ModuleB as dependency (obtaining transitive dep to commons-net), and resolves *erroneously* 1.3.0
> \- ModuleC (ear) takes in 1.3.0 whilst no module is actually using or declaring it
> I'd expect this case to resolve 1.4.1 or at least to fail the build, because in this example B is the only one using commons-net (maybe exploiting 1.4.1-only features), while the final build resolves 1.3.0 (see ModuleA or ModuleC).
> I'm not 100% which is the best policy, but i've got problems (wrong jars, different behaviours and runtime errors) with this kind silent down-resolution of version.
> Regards,
> Paolo
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4457) dependency:resolve decides to take
older (incompatible) version for transitive dep
Posted by "Brian Fox (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=198750#action_198750 ]
Brian Fox commented on MNG-4457:
--------------------------------
1) isn't true. A is using 1.3.0 by nature of declaring B as a dependency, and by declaring 1.3.0 it in it's DependencyManagement. Even though it's not a direct dependency, the fact you have it in DepMgt says: "IF it's in my transitive hull, use THIS version." This is exactly MNG-1577
2)There is a message in the logs about selecting one version over another because of a "managed" version. Maven assumes that since you asked for this version, you know it's supposed to be used. A warning is in appropriate in this case and thus the debug message. If we printed even an INFO everytime someone used DepMgt, that would be a mess. Again, "some deps older than requested" is not true, 1.3.0 was requested by DepMgt in the case of A.
3)Most likely because C is also managing the dependency down to 1.3.0. Otherwise it would pick the closest version which in this case would be 1.4.1
> dependency:resolve decides to take older (incompatible) version for transitive dep
> ----------------------------------------------------------------------------------
>
> Key: MNG-4457
> URL: http://jira.codehaus.org/browse/MNG-4457
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
> Affects Versions: 2.2.1
> Environment: WinXp
> Maven 2.0.9/2.2.1
> Reporter: Paolo Compieta
> Assignee: Brian Fox
> Attachments: m2FairTransitiveDepResolve.zip, m2WrongTransitiveDepResolve.zip
>
>
> I'll use modules Parent,ModuleA,ModuleB,ModuleEAR and dependency Commons-Net to explain the case.
> Parent specifies commons-net/1.3.0 in dependencyManagement
> \- ModuleB declares commons-net/1.4.1 as dependency (overrides version), and resolves correctly 1.4.1
> \- ModuleA declares ModuleB as dependency (obtaining transitive dep to commons-net), and resolves *erroneously* 1.3.0
> \- ModuleC (ear) takes in 1.3.0 whilst no module is actually using or declaring it
> I'd expect this case to resolve 1.4.1 or at least to fail the build, because in this example B is the only one using commons-net (maybe exploiting 1.4.1-only features), while the final build resolves 1.3.0 (see ModuleA or ModuleC).
> I'm not 100% which is the best policy, but i've got problems (wrong jars, different behaviours and runtime errors) with this kind silent down-resolution of version.
> Regards,
> Paolo
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-4457) dependency:resolve decides
to take older (incompatible) version for transitive dep
Posted by "Brian Fox (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=198750#action_198750 ]
Brian Fox edited comment on MNG-4457 at 11/19/09 2:48 PM:
----------------------------------------------------------
1) isn't true. A is using 1.3.0 by nature of declaring B as a dependency, and by declaring 1.3.0 it in it's DependencyManagement. Even though it's not a direct dependency, the fact you have it in DepMgt says: "IF it's in my transitive hull, use THIS version." This is exactly MNG-1577
2)There is a message in the logs about selecting one version over another because of a "managed" version. Maven assumes that since you asked for this version, you know it's supposed to be used. A warning is in appropriate in this case and thus the debug message. If we printed even an INFO everytime someone used DepMgt, that would be a mess. Again, "some deps older than requested" is not true, 1.3.0 was requested by DepMgt in the case of A.
3)Most likely because C is also managing the dependency down to 1.3.0 by inheriting the DepMgt from the parent. Otherwise it would pick the closest version which in this case would be 1.4.1
was (Author: brianfox):
1) isn't true. A is using 1.3.0 by nature of declaring B as a dependency, and by declaring 1.3.0 it in it's DependencyManagement. Even though it's not a direct dependency, the fact you have it in DepMgt says: "IF it's in my transitive hull, use THIS version." This is exactly MNG-1577
2)There is a message in the logs about selecting one version over another because of a "managed" version. Maven assumes that since you asked for this version, you know it's supposed to be used. A warning is in appropriate in this case and thus the debug message. If we printed even an INFO everytime someone used DepMgt, that would be a mess. Again, "some deps older than requested" is not true, 1.3.0 was requested by DepMgt in the case of A.
3)Most likely because C is also managing the dependency down to 1.3.0. Otherwise it would pick the closest version which in this case would be 1.4.1
> dependency:resolve decides to take older (incompatible) version for transitive dep
> ----------------------------------------------------------------------------------
>
> Key: MNG-4457
> URL: http://jira.codehaus.org/browse/MNG-4457
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
> Affects Versions: 2.2.1
> Environment: WinXp
> Maven 2.0.9/2.2.1
> Reporter: Paolo Compieta
> Assignee: Brian Fox
> Attachments: m2FairTransitiveDepResolve.zip, m2WrongTransitiveDepResolve.zip
>
>
> I'll use modules Parent,ModuleA,ModuleB,ModuleEAR and dependency Commons-Net to explain the case.
> Parent specifies commons-net/1.3.0 in dependencyManagement
> \- ModuleB declares commons-net/1.4.1 as dependency (overrides version), and resolves correctly 1.4.1
> \- ModuleA declares ModuleB as dependency (obtaining transitive dep to commons-net), and resolves *erroneously* 1.3.0
> \- ModuleC (ear) takes in 1.3.0 whilst no module is actually using or declaring it
> I'd expect this case to resolve 1.4.1 or at least to fail the build, because in this example B is the only one using commons-net (maybe exploiting 1.4.1-only features), while the final build resolves 1.3.0 (see ModuleA or ModuleC).
> I'm not 100% which is the best policy, but i've got problems (wrong jars, different behaviours and runtime errors) with this kind silent down-resolution of version.
> Regards,
> Paolo
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira