Am 12/23/16 um 10:33 schrieb Stephen Connolly: > 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
Still catching up with unread emails. +1 to all of that. As far as I can tell, we ourselves only use three different values for the prerequisites. 2.0 (implicitly because default), 2.2.1 and 3.0.0. Not much to research. I'll take a look at 2.0.11, 2.2.1 and 3.0.5. Depends on what the next prerequisite we are going to use. As it seems, that would be 3.6.0. Regards, -- Christian --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
