Am 12/26/16 um 21:07 schrieb Stephen Connolly: > Well a command line switch is useless imho.
+1 > > Suppose I have a multi-module reactor and one module uses version A of > plugin X and another module uses version B. > > Now A was built against Maven 3.3.3 and the classpath was "fixed" with > tweaks and hacks to ensure the transitive dependencies worked out correctly > (yes they should have filed a bug rather than work around, but life) > > B was built against Maven 3.4.0 and all the hacks were removed. > > How can we build that reactor with a command line switch? We cannot. The > CLI switch would force with A or B to be wrong. +1 Same for dependencies. > > We need something that works the way users expect *without* requiring that > they change their poms That'd be the best we can do. > This is not something that the user should be able to control directly > IMHO. Adding knobs to tweak the behaviour just complicates things for users. +1 When deployed, no one knows what knobs had been in effect during deployment. Bad idea. Information must be retained in the POMs. Prerequisites to the rescue. > We should look at the prerequisites of the plugin and give it the correct > classpath for that Maven version (and eg this could include adding in Maven > compat for anything pre-3.4.0, aether shims, sonatype shims, etc, mapping > plexus utils etc) +1 I just ran various tests against maven-pmd-plugin version 2.3. That version can still be used with Maven 2.0 and that version is the first version introducing an issue where a test artifact overrides a compile artifact. With Maven 2.0.11 and 2.2.1 the runtime classpath seems to be equal to what 3.4.0-SNAPSHOT currently does (test scope dependencies not available at runtime). This is from the Maven 2.2.1 debug messages: org.apache.maven:maven-artifact:jar:2.0:test (*not setting scope to: compile; local scope test wins*) org.apache.maven:maven-artifact:jar:2.0:test (*selected for test*) MRESOLVER-8 seems to be a Maven 3 regression that went unnoticed. This is something I would not have expected myself. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
