Am 12/26/16 um 23:04 schrieb Stephen Connolly: > 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
The bug is there since aether-1.0. What is a bit strange is that in aether-1.0 the selectors were not inconsistent but were implemented for what I've called dependency resolution. Just compare the 'deriveChildSelector' methods of these two classes in aether-1.0. <https://github.com/sonatype/sonatype-aether/blob/aether-1.0/util/src/main/java/org/sonatype/aether/util/graph/selector/OptionalDependencySelector.java> <https://github.com/sonatype/sonatype-aether/blob/aether-1.0/util/src/main/java/org/sonatype/aether/util/graph/selector/ScopeDependencySelector.java> One of the inconsistencies between the selector implementations got introduced in this commit and released with aether-1.1. <https://github.com/sonatype/sonatype-aether/commit/066bd42e19b57ed6b062dda96b930bacc22e8b34#diff-fc29adb2eeb81ae0520094c0cfdcfc5d> Compare the 'deriveChildSelector' methods of the same classes again after that commit. <https://github.com/sonatype/sonatype-aether/blob/aether-1.1/aether-util/src/main/java/org/sonatype/aether/util/graph/selector/OptionalDependencySelector.java> <https://github.com/sonatype/sonatype-aether/blob/aether-1.1/aether-util/src/main/java/org/sonatype/aether/util/graph/selector/ScopeDependencySelector.java> Maven 3.0-beta-3 is the first release bundled with aether-1.2. I verified the betas and alphas before that also resolved the plugins the way 3.0-beta-3 does it. So it's there since day one of Maven 3. > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
