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
