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 >
