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]
