Skip to content
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

Closed
wants to merge 1 commit into from
Closed

[MRELEASE-1042] releaseProfiles get overriden by activeProfiles #56

wants to merge 1 commit into from

Conversation

bguerin
Copy link
Contributor

@bguerin bguerin commented May 18, 2020

Fix UnsupportedOperationException when altering releaseDescriptor.activateProfiles

@@ -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 );
Copy link
Contributor

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.

Copy link
Contributor Author

@bguerin bguerin May 19, 2020

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we will test ASAP

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") ) );

Copy link
Contributor Author

@bguerin bguerin May 19, 2020

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 ;)

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

Copy link
Contributor

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 )

Copy link

@nfalco79 nfalco79 May 22, 2020

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() );

Copy link
Contributor Author

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 ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

copyPropertiesToReleaseDescriptor means set

@rfscholte
Copy link
Contributor

I don't mind if this piece of code is rewritten. For 3.0.0 I extracted a new interface ReleaseDescriptor, which is part of the API with only (immutable) getters. All new classes introduced were written to keep the original behavior, but with clear separation of reading and writing. DefaultReleaseManager contains code to get the final Release final descriptor based on goal-configuration and release.properties. It looks like that code deserves extra classes in the org.apache.maven.shared.release.config package.

@bguerin
Copy link
Contributor Author

bguerin commented May 22, 2020

Ok, thanks for answer, I will change and try to find a way that sounds good to you

@bguerin bguerin requested a review from rfscholte June 27, 2020 14:04
@bguerin
Copy link
Contributor Author

bguerin commented Jun 27, 2020

Sorry, could not find spare time before .. New try, does it sound better ?

Fix UnsupportedOperationException when altering releaseDescriptor.activateProfiles
Copy link

@eolivelli eolivelli left a 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?

@bguerin
Copy link
Contributor Author

bguerin commented Aug 6, 2020

Hello @eolivelli

I already did ..

Copy link

@eolivelli eolivelli left a 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?

@bguerin
Copy link
Contributor Author

bguerin commented Aug 6, 2020

This PR is a fix of a previous one : #50, where a new test was added :
https://github.com/apache/maven-release/pull/50/files#diff-1579aec6b35365b482da7a7e6b257f30R710

Here, in this PR, I am also fixing the previously added test

@bguerin
Copy link
Contributor Author

bguerin commented Oct 16, 2020

Hello,

Any chance to get this merged ?


if ( specificProfiles != null && !specificProfiles.isEmpty() )
{
List<String> allProfiles = new ArrayList<>();
Copy link
Contributor

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.

Copy link
Contributor Author

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

https://github.com/apache/maven-release/pull/50/files#diff-c4d606c66477b937977eccf603f2f04a7b87f464b7439bcb8e4576307792ff2cR709

and this PR changes a little bit this test

Copy link
Contributor

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.

Copy link
Contributor Author

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

Copy link
Contributor Author

@bguerin bguerin Oct 16, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

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 ...

Copy link

@nfalco79 nfalco79 Apr 2, 2021

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?

@rfscholte
Copy link
Contributor

Merged with a553e19
Thanks for the PR

@rfscholte rfscholte closed this Apr 2, 2021
@bguerin bguerin deleted the bugfix/MRELEASE-1042 branch April 3, 2021 16:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants