Well that certainly puts a different light on things With this being a regression introduced in 3.x it should be significantly less contentious to fix.
What would be good is to find when exactly the regression was introduced: 3.0.x or 3.1.x On Mon 26 Dec 2016 at 21:42, Christian Schulte <[email protected]> wrote: > 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: [email protected] > > For additional commands, e-mail: [email protected] > > > > -- Sent from my phone
