Am 12/16/16 um 20:30 schrieb Robert Scholte: > On Fri, 16 Dec 2016 17:25:16 +0100, Christian Schulte <[email protected]> > wrote: > >> Am 12/16/16 um 15:21 schrieb Robert Scholte: >>> >>> but this cover the issue we are talking about, because IIUC you are >>> saying >>> that IF both junit and hamcrest get the test-scope AND hamcrest would >>> have >>> a dependency THEN that dependency is not added to the classpath. That is >>> still unexpected behavior. >> >> Just add 'test' scope to the hamcrest dependency in that pom. It will >> disappear from the classpath. I would expect that to happen. Why should >> it manage the version but not the scope? >> > > Because Junit refers to hamcrest classes, so they are required to be able > to compile. > There is an issue about this, that Maven should never reduce the scope.
It's not Maven reducing any scope, it's the user telling Maven to do that. The user is the dependency manager, not Maven. > Suppose the user wasn't aware that hamcrest is a runtime requirement of > JUnit and simply adds it for his own test there as test-scoped dependency > you will have a surprising effect. > I am of course aware that (currently) a dependency can only have one > version and one scope. However, I would love to go for a different > approach: choose one or more scopes and select all their matching > dependencies + transitive dependencies. Reflecting this to your example > hamcrest would always be selected as transitive dependency of junit and > its scope will be ignored. > This matches much better the real world expected behavior no matter what > the Maven documentation says. The following is status quo: The core (model builder) uses the dependency management as a source of default values it will copy to all dependencies lacking the corresponding elements. The resolver uses the dependency management passed to it as a source of effective values it will apply just like a global override. Prior 3.4, the dependency collection process looked like: 1. Request to resolve a dependency. 2. Query the repository system session's 'DependencySelector' to see if the dependency should be selected. 3. Override everything of that dependency with any requested management. 4. Do everything else (transformations and conflict resolution) with that managed state. In 3.4, the dependency collection process now looks like: 1. Request to resolve a dependency. 2. Override everything of that dependency with any requested management. 3. Query the repository system session's 'DependencySelector' to see if the dependency should be selected. 4. Do everything else (transformations and conflict resolution) with that managed state. It just calls the 'DependencySelector' with the managed state the same way it performs everything else with the managed state. The dependency selector in use happens to be setup to exclude "test", "provided" and "optional" transitive dependencies. Why is that correct? If the "DependencySelector" decides a "runtime" scoped dependency is to be selected and the very next step makes it a "test" scoped dependency, that dependency influences everything else in an unexpected way. The conflict resolver may decide to keep that managed "test" scope dependency over another node although that other node is what users would have expected to be collected. So what we now have on master is just behaving consistently with itself. The pom and the description from that mail is the example for the release notes, BTW. > Btw, this looks very close to > https://issues.apache.org/jira/browse/MNG-6058 MNG-6058 cannot be solved with model version 4.0.0. Regards, -- Christian --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
