I'm not ok with the "maven baseline" approach: IMHO, there is no such thing during plugin dependencies resolution.
AFAIK, plugin dependencies resolution happens "normally" (or more precisely with the current hack for test or provided scoped dependencies), then when plugin "classpath" creation happens (more precisely ClassWorlds classloader instanciation), there is: 1. some filtering 2. some inheritence from parent classloader Then whatever you put in your plugin pom, exact classes available at runtime are not what was requested by dependency resolution. For more details on code, see exportedPackages and exportedArtifacts of core extensions [1] and classloader hierarchy explanations and code pointers [2] Notice that having at runtime a different version from what you defined in your pom for build is quite classical: it happens constantly when dependency conflicts are resolved, then plugins are like anything else. Then the explanations about prerequisite "feeling wrong" are IMHO wrong :) Like anything else, you ask for one version when compiling, and when running in an integrated system, where full system resolution has been done and conflicts have been resolved at integrated system level, one component doesn't get the version it requested: as usual and full normal. That's why compatibility over time matters... Now there is currently a hack for plugins dependencies resolution that ignores test and provided scoped direct dependencies, because in such case, our current conflict resolution algorithm keeps test scope even if a transitive dependency requires the artifact at runtime: ok, this hack permitted plugins to work when normal libraries could not benefit of same feature. Then the fix is not to blindly remove the hack but improve the initial issue: test scoped dependencies should not override runtime scope transitive ones. There is MNG-5739 JIRA issue about that [3]. And waiting for MNG-5739 implementation, I'm fine with the hack that worked so well for 10 years. And nobody yet showed me a case where the hack caused an issue: remocing the hack is pure logic, that I fully understand and respect, but I prefer keeping this hack to adding a hack to a lot of plugins that consists in changing test scoped dependency to compile scope just to work around transitive dependency resolution issue. Do we agree on the initial explanation about the plugin runtime resolution hack? Do we agree on how to fix the hack? Regards, Hervé [1] http://maven.apache.org/ref/3-LATEST/maven-core/core-extensions.html [2] http://maven.apache.org/ref/3-LATEST/maven-core/ [3] https://issues.apache.org/jira/browse/MNG-5739 Le vendredi 23 décembre 2016, 09:33:50 CET Stephen Connolly a écrit : > 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/p > om.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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
