[jira] (MENFORCER-146) requireUpperBoundDeps inneffective when DependencyManagement is used
[
https://jira.codehaus.org/browse/MENFORCER-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MENFORCER-146.
Resolution: Fixed
Fix Version/s: 1.3
Assignee: Robert Scholte
Fixed in [r1493553|http://svn.apache.org/r1493553] based on the patch of Ben.
Thanks!
> requireUpperBoundDeps inneffective when DependencyManagement is used
>
>
> Key: MENFORCER-146
> URL: https://jira.codehaus.org/browse/MENFORCER-146
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
>Reporter: Ben Noland
>Assignee: Robert Scholte
> Fix For: 1.3
>
> Attachments: menforcer146_withIT.patch, patch2.patch,
> RequireUpperBoundDepsVisitor.diff
>
>
> Consider the following dependency tree:
> {noformat}
> A
> +- B
> | \-X (1.1)
> +- C
>\-X (2.1)
> {noformat}
> I can use the requireUpperBoundDeps to find these types of issues (I want to
> use D 2.1 rather than 1.1).
> To fix the issue I use dependencyManagement to set the version of X to 2.1.
> As I understand it, using dependencyManagement effectively changes the tree
> to look like this:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 1.1, but managed to 2.1)
> +- C
>\-X (2.1)
> {noformat}
> Now, if B is upgraded to depend on X 2.5, I will never know:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 2.5, but managed to 2.1, I want to know about this!!)
> +- C
>\-X (2.1)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-146) requireUpperBoundDeps inneffective when DependencyManagement is used
[
https://jira.codehaus.org/browse/MENFORCER-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MENFORCER-146:
-
Attachment: menforcer146_withIT.patch
I've written an IT (see attachment, which also contains your adjustment,
although reformatted and slightly changed) based on your description, but it
doesn't fail.
Can you update the project, apply my patch and run {{mvn clean verify -Prun-its
-Dinvoker.test=require-upper-bound-dependencies-managed_failure}} and explain
what's going wrong?
> requireUpperBoundDeps inneffective when DependencyManagement is used
>
>
> Key: MENFORCER-146
> URL: https://jira.codehaus.org/browse/MENFORCER-146
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
>Reporter: Ben Noland
> Attachments: menforcer146_withIT.patch, patch2.patch,
> RequireUpperBoundDepsVisitor.diff
>
>
> Consider the following dependency tree:
> {noformat}
> A
> +- B
> | \-X (1.1)
> +- C
>\-X (2.1)
> {noformat}
> I can use the requireUpperBoundDeps to find these types of issues (I want to
> use D 2.1 rather than 1.1).
> To fix the issue I use dependencyManagement to set the version of X to 2.1.
> As I understand it, using dependencyManagement effectively changes the tree
> to look like this:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 1.1, but managed to 2.1)
> +- C
>\-X (2.1)
> {noformat}
> Now, if B is upgraded to depend on X 2.5, I will never know:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 2.5, but managed to 2.1, I want to know about this!!)
> +- C
>\-X (2.1)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-146) requireUpperBoundDeps inneffective when DependencyManagement is used
[
https://jira.codehaus.org/browse/MENFORCER-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben Noland updated MENFORCER-146:
-
Attachment: patch2.patch
> requireUpperBoundDeps inneffective when DependencyManagement is used
>
>
> Key: MENFORCER-146
> URL: https://jira.codehaus.org/browse/MENFORCER-146
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
>Reporter: Ben Noland
> Attachments: patch2.patch, RequireUpperBoundDepsVisitor.diff
>
>
> Consider the following dependency tree:
> {noformat}
> A
> +- B
> | \-X (1.1)
> +- C
>\-X (2.1)
> {noformat}
> I can use the requireUpperBoundDeps to find these types of issues (I want to
> use D 2.1 rather than 1.1).
> To fix the issue I use dependencyManagement to set the version of X to 2.1.
> As I understand it, using dependencyManagement effectively changes the tree
> to look like this:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 1.1, but managed to 2.1)
> +- C
>\-X (2.1)
> {noformat}
> Now, if B is upgraded to depend on X 2.5, I will never know:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 2.5, but managed to 2.1, I want to know about this!!)
> +- C
>\-X (2.1)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-146) requireUpperBoundDeps inneffective when DependencyManagement is used
[
https://jira.codehaus.org/browse/MENFORCER-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=326542#comment-326542
]
Ben Noland commented on MENFORCER-146:
--
In the second block, A has dependencyManagement for X (2.1), B has it
explicitly set (1.1). A's dependencyManagement wins since we're building A (A
doesn't depend directly on X).
I ended up making a few more changes to the rule (I'll attach another patch).
We've been using this for a couple of months and it's working pretty well.
> requireUpperBoundDeps inneffective when DependencyManagement is used
>
>
> Key: MENFORCER-146
> URL: https://jira.codehaus.org/browse/MENFORCER-146
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
>Reporter: Ben Noland
> Attachments: patch2.patch, RequireUpperBoundDepsVisitor.diff
>
>
> Consider the following dependency tree:
> {noformat}
> A
> +- B
> | \-X (1.1)
> +- C
>\-X (2.1)
> {noformat}
> I can use the requireUpperBoundDeps to find these types of issues (I want to
> use D 2.1 rather than 1.1).
> To fix the issue I use dependencyManagement to set the version of X to 2.1.
> As I understand it, using dependencyManagement effectively changes the tree
> to look like this:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 1.1, but managed to 2.1)
> +- C
>\-X (2.1)
> {noformat}
> Now, if B is upgraded to depend on X 2.5, I will never know:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 2.5, but managed to 2.1, I want to know about this!!)
> +- C
>\-X (2.1)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-146) requireUpperBoundDeps inneffective when DependencyManagement is used
[
https://jira.codehaus.org/browse/MENFORCER-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=326423#comment-326423
]
Robert Scholte commented on MENFORCER-146:
--
After re-reading this issue I think you misunderstood the usage
{{dependencyManagement}}.
When using {{dependencyManagement}} you don't have to specify the version for a
{{dependency}}, but if you do the version of the {{dependencyManagement}} will
be overruled.
So your second block should look like this:
{noformat}
A
+- B
| \-X *(1.1) (explicit set to 1.1, was 2.1 through dependencyManagement)*
+- C
\-X (2.1)
{noformat}
So I'm not sure if the adjustment of the rule is still required.
> requireUpperBoundDeps inneffective when DependencyManagement is used
>
>
> Key: MENFORCER-146
> URL: https://jira.codehaus.org/browse/MENFORCER-146
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
>Reporter: Ben Noland
> Attachments: RequireUpperBoundDepsVisitor.diff
>
>
> Consider the following dependency tree:
> {noformat}
> A
> +- B
> | \-X (1.1)
> +- C
>\-X (2.1)
> {noformat}
> I can use the requireUpperBoundDeps to find these types of issues (I want to
> use D 2.1 rather than 1.1).
> To fix the issue I use dependencyManagement to set the version of X to 2.1.
> As I understand it, using dependencyManagement effectively changes the tree
> to look like this:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 1.1, but managed to 2.1)
> +- C
>\-X (2.1)
> {noformat}
> Now, if B is upgraded to depend on X 2.5, I will never know:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 2.5, but managed to 2.1, I want to know about this!!)
> +- C
>\-X (2.1)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-146) requireUpperBoundDeps inneffective when DependencyManagement is used
[
https://jira.codehaus.org/browse/MENFORCER-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317443#comment-317443
]
Ben Noland edited comment on MENFORCER-146 at 1/16/13 3:21 PM:
---
I don't know that the relationship between B and C matters. X could be guava, B
could be an internal project, C could be an external library.
If A calls a method of B that uses a method that's new in X version 2.5, you're
going to get an error.
I do agree that the useManagedVersions param seems like a good solution, I just
don't know that false is the best default, other than to ease people into the
new behavior.
was (Author: bennoland):
I don't know that the relationship between B and C matters. X could be
guava, B could be an internal project, C could be an external library.
If A calls a method of B that uses a method that's new in X version 2.5, you're
going to get an error.
I do agree that the useManagedVersions param seems like a good solution, I just
don't know that true is the best default, other than to ease people into the
new behavior.
> requireUpperBoundDeps inneffective when DependencyManagement is used
>
>
> Key: MENFORCER-146
> URL: https://jira.codehaus.org/browse/MENFORCER-146
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
>Reporter: Ben Noland
> Attachments: RequireUpperBoundDepsVisitor.diff
>
>
> Consider the following dependency tree:
> {noformat}
> A
> +- B
> | \-X (1.1)
> +- C
>\-X (2.1)
> {noformat}
> I can use the requireUpperBoundDeps to find these types of issues (I want to
> use D 2.1 rather than 1.1).
> To fix the issue I use dependencyManagement to set the version of X to 2.1.
> As I understand it, using dependencyManagement effectively changes the tree
> to look like this:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 1.1, but managed to 2.1)
> +- C
>\-X (2.1)
> {noformat}
> Now, if B is upgraded to depend on X 2.5, I will never know:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 2.5, but managed to 2.1, I want to know about this!!)
> +- C
>\-X (2.1)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-146) requireUpperBoundDeps inneffective when DependencyManagement is used
[
https://jira.codehaus.org/browse/MENFORCER-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317443#comment-317443
]
Ben Noland edited comment on MENFORCER-146 at 1/16/13 3:22 PM:
---
I don't know that the relationship between B and C matters. X could be guava, B
could be an internal project, C could be an external library.
If A calls a method of B that uses a method that's new in X version 2.5, you're
going to get an error.
I do agree that the useManagedVersions param seems like a good solution.
was (Author: bennoland):
I don't know that the relationship between B and C matters. X could be
guava, B could be an internal project, C could be an external library.
If A calls a method of B that uses a method that's new in X version 2.5, you're
going to get an error.
I do agree that the useManagedVersions param seems like a good solution, I just
don't know that false is the best default, other than to ease people into the
new behavior.
> requireUpperBoundDeps inneffective when DependencyManagement is used
>
>
> Key: MENFORCER-146
> URL: https://jira.codehaus.org/browse/MENFORCER-146
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
>Reporter: Ben Noland
> Attachments: RequireUpperBoundDepsVisitor.diff
>
>
> Consider the following dependency tree:
> {noformat}
> A
> +- B
> | \-X (1.1)
> +- C
>\-X (2.1)
> {noformat}
> I can use the requireUpperBoundDeps to find these types of issues (I want to
> use D 2.1 rather than 1.1).
> To fix the issue I use dependencyManagement to set the version of X to 2.1.
> As I understand it, using dependencyManagement effectively changes the tree
> to look like this:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 1.1, but managed to 2.1)
> +- C
>\-X (2.1)
> {noformat}
> Now, if B is upgraded to depend on X 2.5, I will never know:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 2.5, but managed to 2.1, I want to know about this!!)
> +- C
>\-X (2.1)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-146) requireUpperBoundDeps inneffective when DependencyManagement is used
[
https://jira.codehaus.org/browse/MENFORCER-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317443#comment-317443
]
Ben Noland commented on MENFORCER-146:
--
I don't know that the relationship between B and C matters. X could be guava, B
could be an internal project, C could be an external library.
If A calls a method of B that uses a method that's new in X version 2.5, you're
going to get an error.
I do agree that the useManagedVersions param seems like a good solution, I just
don't know that true is the best default, other than to ease people into the
new behavior.
> requireUpperBoundDeps inneffective when DependencyManagement is used
>
>
> Key: MENFORCER-146
> URL: https://jira.codehaus.org/browse/MENFORCER-146
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
>Reporter: Ben Noland
> Attachments: RequireUpperBoundDepsVisitor.diff
>
>
> Consider the following dependency tree:
> {noformat}
> A
> +- B
> | \-X (1.1)
> +- C
>\-X (2.1)
> {noformat}
> I can use the requireUpperBoundDeps to find these types of issues (I want to
> use D 2.1 rather than 1.1).
> To fix the issue I use dependencyManagement to set the version of X to 2.1.
> As I understand it, using dependencyManagement effectively changes the tree
> to look like this:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 1.1, but managed to 2.1)
> +- C
>\-X (2.1)
> {noformat}
> Now, if B is upgraded to depend on X 2.5, I will never know:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 2.5, but managed to 2.1, I want to know about this!!)
> +- C
>\-X (2.1)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-146) requireUpperBoundDeps inneffective when DependencyManagement is used
[
https://jira.codehaus.org/browse/MENFORCER-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317435#comment-317435
]
Robert Scholte commented on MENFORCER-146:
--
IMO as long as B and C aren't related, it shouldn't be an issue. But I can
imagine the situation. So {{useManagedVersions}} should be a {{boolean}},
default to {{false}}. A test to prevent regression would be welcome as well.
> requireUpperBoundDeps inneffective when DependencyManagement is used
>
>
> Key: MENFORCER-146
> URL: https://jira.codehaus.org/browse/MENFORCER-146
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
>Reporter: Ben Noland
> Attachments: RequireUpperBoundDepsVisitor.diff
>
>
> Consider the following dependency tree:
> {noformat}
> A
> +- B
> | \-X (1.1)
> +- C
>\-X (2.1)
> {noformat}
> I can use the requireUpperBoundDeps to find these types of issues (I want to
> use D 2.1 rather than 1.1).
> To fix the issue I use dependencyManagement to set the version of X to 2.1.
> As I understand it, using dependencyManagement effectively changes the tree
> to look like this:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 1.1, but managed to 2.1)
> +- C
>\-X (2.1)
> {noformat}
> Now, if B is upgraded to depend on X 2.5, I will never know:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 2.5, but managed to 2.1, I want to know about this!!)
> +- C
>\-X (2.1)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-146) requireUpperBoundDeps inneffective when DependencyManagement is used
[
https://jira.codehaus.org/browse/MENFORCER-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben Noland updated MENFORCER-146:
-
Attachment: RequireUpperBoundDepsVisitor.diff
I've attached a patch showing the behavior I find more useful. It uses the
preManagedVersion() of the DependencyNode, rather than the resolved version.
> requireUpperBoundDeps inneffective when DependencyManagement is used
>
>
> Key: MENFORCER-146
> URL: https://jira.codehaus.org/browse/MENFORCER-146
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
>Reporter: Ben Noland
> Attachments: RequireUpperBoundDepsVisitor.diff
>
>
> Consider the following dependency tree:
> {noformat}
> A
> +- B
> | \-X (1.1)
> +- C
>\-X (2.1)
> {noformat}
> I can use the requireUpperBoundDeps to find these types of issues (I want to
> use D 2.1 rather than 1.1).
> To fix the issue I use dependencyManagement to set the version of X to 2.1.
> As I understand it, using dependencyManagement effectively changes the tree
> to look like this:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 1.1, but managed to 2.1)
> +- C
>\-X (2.1)
> {noformat}
> Now, if B is upgraded to depend on X 2.5, I will never know:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 2.5, but managed to 2.1, I want to know about this!!)
> +- C
>\-X (2.1)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-146) requireUpperBoundDeps inneffective when DependencyManagement is used
[
https://jira.codehaus.org/browse/MENFORCER-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MENFORCER-146:
-
Description:
Consider the following dependency tree:
{noformat}
A
+- B
| \-X (1.1)
+- C
\-X (2.1)
{noformat}
I can use the requireUpperBoundDeps to find these types of issues (I want to
use D 2.1 rather than 1.1).
To fix the issue I use dependencyManagement to set the version of X to 2.1.
As I understand it, using dependencyManagement effectively changes the tree to
look like this:
{noformat}
A
+- B
| \-X (2.1) (really 1.1, but managed to 2.1)
+- C
\-X (2.1)
{noformat}
Now, if B is upgraded to depend on X 2.5, I will never know:
{noformat}
A
+- B
| \-X (2.1) (really 2.5, but managed to 2.1, I want to know about this!!)
+- C
\-X (2.1)
{noformat}
was:
Consider the following dependency tree:
A
+- B
| \-X (1.1)
+- C
\-X (2.1)
I can use the requireUpperBoundDeps to find these types of issues (I want to
use D 2.1 rather than 1.1).
To fix the issue I use dependencyManagement to set the version of X to 2.1.
As I understand it, using dependencyManagement effectively changes the tree to
look like this:
A
+- B
| \-X (2.1) (really 1.1, but managed to 2.1)
+- C
\-X (2.1)
Now, if B is upgraded to depend on X 2.5, I will never know:
A
+- B
| \-X (2.1) (really 2.5, but managed to 2.1, I want to know about this!!)
+- C
\-X (2.1)
> requireUpperBoundDeps inneffective when DependencyManagement is used
>
>
> Key: MENFORCER-146
> URL: https://jira.codehaus.org/browse/MENFORCER-146
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
>Reporter: Ben Noland
>
> Consider the following dependency tree:
> {noformat}
> A
> +- B
> | \-X (1.1)
> +- C
>\-X (2.1)
> {noformat}
> I can use the requireUpperBoundDeps to find these types of issues (I want to
> use D 2.1 rather than 1.1).
> To fix the issue I use dependencyManagement to set the version of X to 2.1.
> As I understand it, using dependencyManagement effectively changes the tree
> to look like this:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 1.1, but managed to 2.1)
> +- C
>\-X (2.1)
> {noformat}
> Now, if B is upgraded to depend on X 2.5, I will never know:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 2.5, but managed to 2.1, I want to know about this!!)
> +- C
>\-X (2.1)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-146) requireUpperBoundDeps inneffective when DependencyManagement is used
Ben Noland created MENFORCER-146: Summary: requireUpperBoundDeps inneffective when DependencyManagement is used Key: MENFORCER-146 URL: https://jira.codehaus.org/browse/MENFORCER-146 Project: Maven 2.x Enforcer Plugin Issue Type: Bug Reporter: Ben Noland Consider the following dependency tree: A +- B | \-X (1.1) +- C \-X (2.1) I can use the requireUpperBoundDeps to find these types of issues (I want to use D 2.1 rather than 1.1). To fix the issue I use dependencyManagement to set the version of X to 2.1. As I understand it, using dependencyManagement effectively changes the tree to look like this: A +- B | \-X (2.1) (really 1.1, but managed to 2.1) +- C \-X (2.1) Now, if B is upgraded to depend on X 2.5, I will never know: A +- B | \-X (2.1) (really 2.5, but managed to 2.1, I want to know about this!!) +- C \-X (2.1) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
