> This is not something that the user should be able to control directly
Makes sense, since this only affects plugins, to not expect or enable user control of this feature. Thank you for explaining. (I also do not prefer a CLI switch for this due to the "reproducible builds" issue, and prefer a source controlled setting, which a pom change is a solution; I also agree we don't want that requirement nor is it needed to allow users to change it.) On Mon, Dec 26, 2016 at 2:07 PM, Stephen Connolly < [email protected]> wrote: > 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 <[email protected]> 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 < > > > > [email protected]> 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 <[email protected]> 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: [email protected] > > > > > > > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Sent from my phone > > > > > > > > > -- > Sent from my phone >
