Well a command line switch is useless imho. 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. We need something that works the way users expect *without* requiring that they change their poms (If we have no solution available other than "you have to change your poms" then we need to do that, but first priority is not to force users to change their poms) So prerequisites comes into play because it defines the minimum version of Maven that the plugin works with. I am presuming that Maven 2.x did not have this issue. I suspect, perhaps Maven 3.0.x did not have it either... it would be good to get some history if the behaviour. (If it turns out that maven 2.x behaves the same as 3.3.9 in this regard then really the bug is the Java docs) If you are a plugin developer, and you mark your plugin as compatible with Maven 2.2.1+ (which is what 'prerequisites' does... you do know that field is *only* applicable to plugins!) we have to assume you tested on Maven 2.2.1, and you should thus have git a 2.2.1 classpath. If that is not the same as a 3.3.9 classpath... boom that is a bug in 3.3.9 and it is perfectly legitimate for 3.4.0 to provide the plugin with the classpath it would get with Maven 2.2.1 (which may even be different from 3.4.0) 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. 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) If the user finds bugs they can either upgrade/roll back the plugin or upgrade/roll back Maven and we update our mapping layer for the 3.4.1 release and move forward. Adding 1000 command line options is not the right answer. It seems we got lucky here with it only affecting plugins... so we can use our luck as a get out of jail free card and use the plugins advertised minimum Maven version requirement to control the resolution strategy for each plugin. On Mon 26 Dec 2016 at 18:54, Jeff Jensen <jjen...@apache.org> wrote: > I find the prerequisites idea very intriguing. However, does that mean > > it's automatic behavior and no way for user to control it? > > (For user to control it, in addition to normal docs, I expect release notes > > describing the issue (e.g. links to JIRA) and how to enable/disable the new > > breaking feature or breaking fix (e.g. POM element or property)). > > > > > > BTW Christian, I admire your work and tenacity on this fix. While I > > understand the "main line development" pattern and what you intended, I > > also think it should have been on a branch with some commits squashed (and > > full tests run before pushing). > > > > > > On Mon, Dec 26, 2016 at 12:29 PM, Stephen Connolly < > > stephen.alan.conno...@gmail.com> wrote: > > > > > Rather than a CLI switch can we use the plugin prerequisites to control > the > > > behaviour? > > > > > > If prerequisites is < 3.0 or >= 3.4 then apply the fix otherwise > replicate > > > the bug. > > > > > > That way if the plugin was built and tested against 2.x (which presumably > > > doesn't have the bug) or against 3.4+ you get the. Ore than behaviour. > > > Plugins that were developed and tested against 3.0-3.3 should get the > > > behaviour they were tested against > > > > > > Wdyt > > > On Mon 26 Dec 2016 at 16:07, Christian Schulte <c...@schulte.it> wrote: > > > > > > > Am 12/26/16 um 11:36 schrieb Robert Scholte: > > > > > > > > > This is becoming a bug versus feature discussion. > > > > > > > > > > > > > > > > It shouldn't. > > > > > > > > > > > > > > > > > Up until now you've made > > > > > > > > > changes which might change the resolution because you've marked them > > > as a > > > > > > > > > bug which must be fixed. However, what is 'the truth': the > > > documentation > > > > > > > > > or the code? The answer is: in the end it is the code. And if you > want > > > to > > > > > > > > > have them in sync, you sometimes need to adjust the documentation > > > instead > > > > > > > > > of the code, because the code has a behavior one is used to. > > > > > > > > > > > > > > > > Have you read the Javadoc and the code? If you would have done that, > you > > > > > > > > would notice that everything behaves consistently and as documented > > > > > > > > *but* one class which is fixed now. If it would be *all* classes, there > > > > > > > > would be no question the code is behaving the way it should. > > > > > > > > > > > > > > > > MRESOLVER-8 > > > > > > > > > > > > > > > > This *only* affects plugin and extension resolution by stopping to > > > > > > > > discard any test and provided *direct* dependencies of a plugin the > same > > > > > > > > way optional *direct* dependencies are not discarded and the same way > > > > > > > > the dependency manager is not managing *direct* dependencies. It does > > > > > > > > not affect project resolution in any way. That's what we are really > > > > > > > > lucky about. If we don't want Maven to behave that way (with plugin and > > > > > > > > extension resolution fixed) it's the Maven codebase to adjust - not the > > > > > > > > resolver. That's just an API used by Maven and should just be > consistent > > > > > > > > and correct. The original author really could have left a few unit > tests > > > > > > > > in that area. We would not discuss anything, if he would have done > that. > > > > > > > > He would have noticed things himself or would have left a comment at > > > > > > > > least. The issue above together with > > > > > > > > > > > > > > > > MRESOLVER-9 > > > > > > > > MRESOLVER-10 > > > > > > > > > > > > > > > > is really "just" bugfixes. What we learn from that is that we should > > > > > > > > "commit" any resolution result during deployment so that bugs like > these > > > > > > > > can be fixed without influencing the resolution performed for a > deployed > > > > > > > > project. That's the PDT file we are going to deploy in Maven X. > > > > > > > > > > > > > > > > > Since we're talking about changes in resolution, I also expose this > > > > topic. > > > > > > > > > To me it is not a bug nor a feature, but it is a design flaw. And the > > > > > > > > > issue is often not exposed, because the dependencies used for testing > > > are > > > > > > > > > not conflicting the compile dependencies. As long as the compilations > > > > > > > > > works and all the tests run, users often don't look in detail at the > > > > > > > > > dependency. > > > > > > > > > The fact right now is that if I add/change a test-scoped dependency, > it > > > > > > > > > could happen that the project won't run due to a missing transitive > > > > > > > > > dependency. > > > > > > > > > We are very, very lucky this doesn't happen that often. > > > > > > > > > > > > > > > > This is what would stop if we would just fix those bugs. We are running > > > > > > > > into those bugs ourselves. Take a look at the PMD plugin POM again. > What > > > > > > > > would you have done, if the test dependencies I moved to compile scope > > > > > > > > would be required for compilation of that project? This is already > > > > > > > > yelling for an enforcer rule or something like that. "Are all classes > > > > > > > > used by the classes on the compilation classpath available during > > > > > > > > compilation?" Currently it's a result of trial and error. Really. If we > > > > > > > > let this go on, we need to be even more lucky in a few years. If we say > > > > > > > > plugins and extensions just are not resolved the same way as projects > > > > > > > > (how it has been for a long time), this will make the following IT > start > > > > > > > > to fail, when done consistently. > > > > > > > > > > > > > > > > < > > > > https://git-wip-us.apache.org/repos/asf?p=maven-integration- > > > testing.git;a=commit;h=4d9d7104d3491ec4a00e3ffc6713d983c84a19d0 > > > > > > > > > > > > > > > > > > > > > So we would need to adjust the Maven codebase to keep it behaving as > > > > > > > > before. The resolver is not the correct codebase for this. I could do > > > > > > > > that easily although it's inconcistent with itself that way. If you > take > > > > > > > > a look at what updates needed to be performed to various plugin POMs, > > > > > > > > those are really all bugs in the POMs. Either we fix them, or we make > > > > > > > > plugin resolution differ from project resolution (non-transitive > > > > > > > > *direct* dependencies only override main scope dependencies during > > > > > > > > building but are ignored when building the runtime classpath). Just say > > > > > > > > so and it'll be done. My personal opinion is that having a different > > > > > > > > runtime classpath than what was used during building is a bad idea and > > > > > > > > we are running into issues due to this ourselves which proves this > > > correct. > > > > > > > > > > > > > > > > Regards, > > > > > > > > -- > > > > > > > > Christian > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > > > -- > > > Sent from my phone > > > > > -- Sent from my phone
