-
Notifications
You must be signed in to change notification settings - Fork 132
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
[MRELEASE-1042] releaseProfiles get overriden by activeProfiles #56
Conversation
@@ -58,7 +59,9 @@ public ReleaseDescriptorBuilder addCheckModificationExclude( String string ) | |||
|
|||
public ReleaseDescriptorBuilder setActivateProfiles( List<String> profiles ) | |||
{ | |||
releaseDescriptor.setActivateProfiles( profiles ); | |||
List<String> copy = new ArrayList<>(); | |||
copy.addAll( profiles ); |
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.
This now acts as a merge, not as a setter, so this can't be the right approach.
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.
This is not a merge, I do not keep the old value. It is a defensive setter, ensuring that the list implementation used is not read only / immuable
This change is the minimal one is we want to keep your remarks on my previous 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.
we will test ASAP
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.
@bguerin I confirm that the fix works.
I would also suggest to change the test case here and use the same approach at few lines above.
In short replace:
secondBuilder.setActivateProfiles( new ArrayList( Arrays.asList("aProfile", "bProfile") ) );
with
secondBuilder.setActivateProfiles( Arrays.asList( Arrays.asList("aProfile", "bProfile") ) );
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 confirm that the fix works.
YOUPI !!!
change the test case
This is already part of 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.
I had the same question
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.
there are 3 ways of merging when having a lefthandside and a righthandside:
- LHS over RHS ( setter )
- RHS over LHS ( setter )
- In case of Collections: combining LHS with RHS ( appender )
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 the
DefaultReleaseManager
you can already see some anonymous classes that are used to control such logic.
I see. Maybe could be the case implement an inner class MergeReleaseDescriptorBuilder and replace all the instancies unless in some cases you really want to merge only a specific properties. Anyway this way it's quite tricky, I say tricky because it's applied more times so the idea of a ReleaseDescriptorBuilder unmutable seems to be not so strong.
ReleaseDescriptor releaseDescriptor = loadReleaseDescriptor(
new ReleaseDescriptorBuilder() {
public void setActivateProfiles( List<String> profiles ) {
builder = performRequest.getReleaseDescriptorBuilder()
// merge with actual
builder.setActivateProfiles(builder.build().getActivateProfiles() + profiles);
}
}, performRequest.getReleaseManagerListener() );
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.
there are 3 ways of merging ..
You do not answer my question. When you say
copyPropertiesToReleaseDescriptor means: if property exists, apply that to release descriptor
What should it do in case of a collection ? what "apply" means in your sentence : override existing value, or append to it ?
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.
copyPropertiesToReleaseDescriptor
means set
I don't mind if this piece of code is rewritten. For 3.0.0 I extracted a new interface |
Ok, thanks for answer, I will change and try to find a way that sounds good to you |
Sorry, could not find spare time before .. New try, does it sound better ? |
Fix UnsupportedOperationException when altering releaseDescriptor.activateProfiles
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.
Hi
Thanks for working on this.
Can you please add tests that ensure that your code does what is expected to achieve?
Hello @eolivelli I already did .. |
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 can't see any new test.
Can you please point me those new tests?
This PR is a fix of a previous one : #50, where a new test was added : Here, in this PR, I am also fixing the previously added test |
Hello, Any chance to get this merged ? |
|
||
if ( specificProfiles != null && !specificProfiles.isEmpty() ) | ||
{ | ||
List<String> allProfiles = new ArrayList<>(); |
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 guess this part can result is a different set of activated profiles, but it is not covered by a test. Currently, the build is green and we've seen issues with profiles before, so we really need a higher code coverage here.
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.
once again ... this PR fix my previous one, where a Unit Test WAS ADDED
and this PR changes a little bit this test
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.
But if the current build is green, then there is no need to merge this.
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.
the current build is green because of the new ArrayList( ... )
in the unit test :
secondBuilder.setActivateProfiles( new ArrayList( Arrays.asList("aProfile", "bProfile") ) );
Remove it and the build will become red. And IT WAS a MISTAKE to add it, it is false comparing to what happens when using the plugin
This PR fix the code so that this new ArrayList( ... )
is not needed anymore, and the unit test is representative of the plugin usage
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.
Some background is in https://issues.apache.org/jira/browse/MRELEASE-1042 also ...
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 I remember the discussion. @rfscholte you wanted by design that the state of descriptor is immutable (link).
The test case use a new arraylist that is mutable but this is not at runtime. I know because we was forced to fork this repo and make our version of release plugin with a issue (1 year ago!).
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.
Here we inject an immutable list - so the test case is in fact wrong.
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.
@slachiewicz Yes, EXACTLY !!! The test case added in my previous PR is WRONG, and HERE, in THIS PR, I want to fix it ...
Please please, tell me what to do to get this merged and released, my team just NEED this ...
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.
@rfscholte, @slachiewicz please could you finalize this issue?
Merged with a553e19 |
Fix UnsupportedOperationException when altering releaseDescriptor.activateProfiles