Le vendredi 23 décembre 2016, 09:32:50 CET Christian Schulte a écrit : > 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. please look at "if it ain't broke, don't fix it" proverb, or "never change a running system"
for example at https://en.wiktionary.org/wiki/if_it_ain't_broke,_don't_fix_it > The bugfix > immediately uncovered a mistake in a POM of a plugin everyone agrees to > be a real issue. no, I don't agree that it is 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. I fear it's not only one plugin, but every plugin that applied the scope=provided recipe that Maven Plugin Tools Annotations promotes > The findbugs-maven-plugin issue > I've been talking about is unrelated to the resolver and is also fixed > in recent releases. ok, I don't know why you talked about it if it's not related [...] > > 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. disaster didn't happen for years before your work on "fixing" something that didn't break: remember to read about "if it ain't broke, don't fix it" proverb, it has to be known and respected at least in some cases > It's just > unpredictable behaviour presented to be something done intentionally > although things are just a matter of luck or bad luck. that's why I try to know if you have reported cases (as you told) of something really broken (= something with bad luck) IIUC, you don't have any case of 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. ok, I start to understand: no, the plugin does not provide the annotations dependency (as I wrote in MPLUGIN-321, Maven core uses META-INF/maven/ plugin.xml) but this is one of the rare case where a dependency is simply *not used* at runtime... Ok, I now understand the real impact on plugins: no impact in general, only maven-plugin-plugin is impacted because it uses annotations to extract information from bytecode to generate META-INF/maven/plugin.xml I'll improve MPLUGIN-296 description, which is currently at least not clear at all (which I knew but could not get any useful answer) But at least, now, I think I better imagine the impact of this bugfix of a bug that nobody noticed: it just breaks maven-plugin-plugin, which is an edge case of the bugfix edge case. I feel more confident now on this one let's move on evaluating other changes currently in 3.4.0-SNAPSHOT Regards, Hervé > > > Regards, --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
