On Fri, 16 Dec 2016 21:23:14 +0100, Christian Schulte <c...@schulte.it>
wrote:
Am 12/16/16 um 20:30 schrieb Robert Scholte:
On Fri, 16 Dec 2016 17:25:16 +0100, Christian Schulte <c...@schulte.it>
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.
No, no, no. Dependency management may never make dependencies disappear,
no matter the scope specified. If a user doesn't want a dependency, it
must use dependency.excludes.
Robert
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,
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
