Ok, so I think we need to change how we describe things a bit. Project resolution starts from a clean baseline. If you have a project with zero dependencies (other than those implicit in being a java project say... which means the JRE classpath is an implicit dependency) then you just have the implicit dependencies present.
Plugin resolution starts from a maven baseline. There are some dependencies which are forced on you by the nature of the maven version you are running. If we are dealing with a dependency that is not in the maven baseline, say com.example.foo:bar then project resolution and plugin resolution should behave exactly the same way for a plugin as for a project. If we are dealing with a dependency that is part of Maven core *but* not exposed to plugins, this could be org.slf4j:slf4j-api (but I would need to check the plugin classloader setup rules... in any case there are some dependencies in Maven that we do not expose to plugins) then project and plugin resolution should behave exactly the same way for a plugin as for a project. If we are dealing with a dependency that is exported by Maven core to plugins: plugin-api, plexus-utils, etc... now we are in a different situation. The plugin is no longer free to get the version it requested. The plugin *will* be getting the version exported by Maven Core irrespective of what it requested. This is what the xpath:/project/prerequisites/maven is for (though we probably have not been good at expressing its utility. So https://svn.apache.org/viewvc/maven/plugin-tools/trunk/maven-plugin-plugin/pom.xml?view=markup#l41 being 2.2.1 is probably "wrong" _if_ there is a conflict between the exported dependencies by Maven core and the dependencies in the plugin pom. The reason I say "wrong" is that logically it may not be *wrong* only feel wrong. What we should be doing is maintaining the Maven a list of _previous_ versions and the rules to apply to those... so for example, * when a plugin says xpath:/project/prerequisites/maven=2.2.1 then we know that it is expecting the 2.2.1 APIs on the classpath, we can then remove the corresponding implicits from the tree for that plugin despite the fact that some of the dependencies have been relocated / restructured. * when a plugin says xpath:/project/prerequisites/maven=3.3.9 then we know that it is expecting the APIs for 3.3.9 on the classpath and we can now assume that, for example, some of the 2.x Maven APIs that were removed with 3.0 are no longer implicit on that plugins classpath... except that we cannot do that right now as that would be a breaking change because we were not purists in enforcing this... So let's say we do the purist clean-up of dependencies... that would mean that going forward we declare that any plugin with xpath:/project/prerequisites/maven>=3.4.0 would need to have the correct dependencies of maven core for a "modern" style... those dependencies will be overridden by Maven core and you will get what Maven core says you will get. HTH On 23 December 2016 at 08:32, Christian Schulte <c...@schulte.it> wrote: > 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 > >
