Am 12/23/16 um 08:16 schrieb Hervé BOUTEMY: > Le vendredi 23 décembre 2016, 03:59:17 CET Christian Schulte a écrit : >> Am 12/22/16 um 19:14 schrieb Robert Scholte: >>> -0.9 for the commandline option, there should be only one truth. >> >> +1 >> >>> Dependency management is way too important, you should not have an option >>> to choose. Better to agree that we are indeed fixing a bug or that we >>> should maintain the current behavior. And that'll take time. I will have a >>> look at all the related issues which could be controlled by this flag and >>> find a way to get feedback from more people. >> >> -1 for maintaining the current behavior. Issues will get reported over >> and over again. > you keep saying that but don't give any other example than MPLUGIN-296 = a > failure caused by your purist fix in MRESOLVER-8 > and you talked about findbugs-maven-plugin, but did not give any pointer > > once again, can you give examples of something that MRESOLVER-8 fixes, apart > from the logic of exact resolution?
Why are you questioning making plugin resolution work the same way project resolution is performed? I don't get that. The bugfix immediately uncovered a mistake in a POM of a plugin everyone agrees to be a real issue. I just verified that selector had that bug right from the intial resolver contribution outside Apache so has always been there. Right now only the maven-plugin-plugin version 3.4 is affected. Version 3.3 and 3.5 are not affected. The findbugs-maven-plugin issue I've been talking about is unrelated to the resolver and is also fixed in recent releases. <https://github.com/gleclaire/findbugs-maven-plugin/commit/7954b94eff5c6b0524e7fe26d8f114b3c5450b86> This is nothing different to the resolver bugfix. The changes in core were made to make collections returned by getters in maven core consistently immutable. A lot of return this.collection == null ? Collections.emptyList() : this.collection; were updated to look like return this.collection == null ? Collections.emptyList() : Collections.unmodifiableList(this.collection); The emptyList is immutable and will lead to runtime exceptions when modified so the collection returned always needs to be immutable and not only when null just to prevent someone from beeing able to modify a non-empty list returned and then run into runtime exceptions when that list "magically" is null. > > I respect logic, since I can imagine that in addition to the case that worked > magically, there can be cases that fail magically = not something I want > forever. > You found a few cases working magically = in fact one recipe based on it, > that > is still in our documentation [1] as "<!-- annotations are needed only to > build the plugin -->"). > If we didn't find cases failing magically, pressure to change is not the same. Things working magically are a recipe for desaster. It's just unpredictable behaviour presented to be something done intentionally although things are just a matter of luck or bad luck. Especially when a lot of the POMs around are a result of trial and error. Maven should have produced an error but did not "magically". Chances are great someone starts applying his findings to each and every project without ever noticing things really are not working as intended. We should be super sure that this trial and error always leads to valid POMs. > > And of course, this wrong explanation in our doc should be fixed and > explained: > I'll work on that (because, remember, I already told I'm supportive of > improvements): I opened MPLUGIN-321 [2], please review and improve > explanations if necessary = this is the start of something that will also > appear in release notes for the version of Maven that will contaning the > updated plugin resolution algorithm (we'll see later if it's Maven 3.4.0 or > not) > There is nothing wrong about that documentation. It's a special case with the maven-plugin-plugin. Only that plugin must not use "provided" for the annotations because that plugin is what needs them at runtime. It is the provider itself. Other plugins should in fact use "provided" because the annotations are provided by maven-plugin-plugin and not used by anything else. Regards, -- Christian --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
