Am 2017-05-28 um 13:01 schrieb Hervé BOUTEMY:
I'm not confident on this one.

I understand the inconsistency issue, that may lead to edge-case issues in
plugins or extensions (that unexpectedly get an immutable empty list when they
usually get a modifiable non-empty list)

Is it the right solution to change every non-empty list to immutable?

Neither is unless you exactly know how the lists will be used.

Why wouldn't be the solution to make every returned empty list mutable?

This is also I am not in favor of neither one, but it has to be predictable, thus consisitent.

Or a mix: on some cases, immutable is a good feature, but on others consistent
mutable would be the good choice?

The caller does not know wether he will receive a populated or empty list.

Do you know how many plugins or extensions this update will break?
I know that consistent breaks are better than inconsistent breaks (on empty
lists), but is it the right time to take such risk?

I can run all plugin ITs from our aggregator and see how they work.

I know that core ITs pass: that does not mean that external plugins won't
break (thousands in Central only, I don't know how many corporate plugins
exist)


How many cases are changed? In which areas of Maven API?
That is the information I need to vote for this change, knowing the effective
impact it will have

As far as I can see for the changes, they all look like read-only structures.

I fully understand your concerns. Let me run plugins ITs and see return, we can postpone to 3.6 if we think this is too problematic.

Michael

Le dimanche 28 mai 2017, 12:01:20 CEST Michael Osipov a écrit :
Am 2017-05-25 um 21:12 schrieb Michael Osipov:
Who seconds MNG-6164 for 3.5.1?

This is a non-functional consistency fix. All ITs pass.

Anyone?


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]





---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to