-
Notifications
You must be signed in to change notification settings - Fork 267
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#299: allowAnyUpdates should be ignored #941
Conversation
Alternatively, we could simply log a warning message if the user sets both "allowAnyUpdates" to true and one of the other modifies to false. |
Looks like this is also in line with what users expect – see the latest comments in #299. |
…e if any of: allowMajorUpdates, allowMinorUpdates, allowIncrementalUpdates is set to false
&& allowAnyUpdates | ||
&& !(allowMajorUpdates && allowMinorUpdates && allowIncrementalUpdates)) { | ||
getLog().warn("Assuming allowAnyUpdates false because one or more other \"allow\" switches is false."); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
allowAnyUpdates
has default value as true
so when user provide only one allow*
switch this warning will be always displayed.
As now we ignore at all allowAnyUpdates
maybe it is not needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As now we ignore at all allowAnyUpdates maybe it is not needed.
The problem is that we do not ignore allowAnyUpdates
-- we ignore all the other allow
options if allowAnyUpdates
is true
. Which it is by default.
See:
Line 514 in 0fe821e
? empty() |
That is basically the reason why I created this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In other words, if the user only sets allowMajorUpdates=false
, that option will be ignored because the user also must use allowAnyUpdates=false
together with that option for it to work... Which is flawed in my opinion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see that after this change allowAnyUpdates
will be ignored - so it will be not important what user set - right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, with a warning message.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, but settings or not allowAnyUpdates
will mo have any effect only warning message will be or not displayed
So I think that warning is such case is redundant
I don't see any more usage of allowAnyUpdates
...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see it either.
Ideally, I would remove it.
Should we? Then we could simply use the SegmentUtils method used elsewhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do it. allowAnyUpdates
is only used in this goal. Will be more clear.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay. How about a small refactoring job?
There's an inconsistency:
SegmentUtils.determineUnchangedSegment
will return the first segment that may not changeVersionDetails.restrictionFor
expects the first segment that may change.
So let's make parts that rely on these use the same thing and so we can get rid of this incrementing of the segement in some places (DisplayDependencyUpdates). But that will take some time (maybe one day, maybe two). Agreed?
Otherwise we can postpone this to the next release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agree - we can wait a few days.
I would to release next version at next week - about 25 - 26 of May
...ions-maven-plugin/src/main/java/org/codehaus/mojo/versions/DisplayDependencyUpdatesMojo.java
Show resolved
Hide resolved
...ions-maven-plugin/src/main/java/org/codehaus/mojo/versions/DisplayDependencyUpdatesMojo.java
Show resolved
Hide resolved
While working on the refactoring job, I've discovered a bug around With
and without:
That means that allow... options only display updates from the segment which is the first one which allows updates, but not from any lesser segments. Strange that we haven't found it with our tests. Well, I'm fixing this now (we'll get rid of Also, adding more tests... -> #960 will include this refactoring job in a fix for that. I'll keep this PR open until that is done. |
Looks more complicated ... so I have proposition to postpone this and related issues to next release. |
Not ready, I see that integration tests are failing, so there's more work needed. Also, I need to see if this is restricted to display-dependency-updates. So, let's postponse that one too. |
This might be seen as a breaking change, but I think it is in line with what most users expect to happen anyway.
So, this change sanctions these expectations -- allowAnyUpdates shall effectively assume the value of
false
if any of the other modifies are set tofalse
.Actually, this means that it's redundant, but the fact is that it's getting removed in version 3.0 anyway.
@slawekjaranowski what is your opinion?