Am 12/14/16 um 22:57 schrieb Robert Scholte:
> Digging into this case before the change:
>
> The 4 related modules ignoring the versions:
>
> org.apache.maven.wagon:wagon:pom
> {
> dependencyManagement {
> dependencies {
> org.apache.maven.wagon:wagon-provider-test:compile
> org.codehaus.plexus:plexus-container-default:test,
> }
> }
> }
>
> org.apache.maven.wagon:wagon-provider-test:jar {
> parent {
> org.apache.maven.wagon:wagon
> }
>
> dependencies {
> org.codehaus.plexus:plexus-container-default:compile,
> }
> }
>
> org.apache.maven.wagon:wagon-providers:pom {
> parent {
> org.apache.maven.wagon:wagon
> }
> dependencies {
> org.apache.maven.wagon:wagon-provider-test:test
> }
> }
>
> org.apache.maven.wagon:wagon-file:jar {
> parent {
> org.apache.maven.wagon:wagon-providers
> }
> }
>
> With the current M3.4.0-SNAPSHOT this fails during test-compile of
> org.apache.maven.wagon:wagon-file because
> org.codehaus.plexus:plexus-container-default is not on the classpath
Correct. It's a transitive dependency of 'wagon-provider-test' with
'test' scope.
> btw. wagon-provider-test shows why I don't like managing elements which
> have a default value: to me it looks weird to (re)set the scope to the
> default value of compile. But that's a matter of taste, I know...
The 'test' scope from dependency management had been overridden
everywhere to 'compile'. Managing it to 'test' during resolution and
overriding it everywhere to 'compile' (model builder, see A below) makes
no sense.
>
> So why would we expect org.codehaus.plexus:plexus-container-default on the
> test-classpath?
> FileWagonTest is only using classes from wagon-provider-test, which is a
> direct test-scoped dependency (via wagon-providers). Any compile/runtime
> scoped dependencies from wagon-provider-test should be added to the
> classpath: that's the responsibility of Maven, not of the user.
>
> I've removed org.apache.maven.wagon:wagon-provider-test from
> dependencyManagement and specify its version to the direct dependency and
> still the build fails for the same reason.
> To me this doesn't make sense, I think there's more to this.
>
> Anyhow, the original resolution with the so-called bug matches much more
> the expectations of dependency resolution and current behavior will likely
> break quite some builds.
I can only comment on what the code is doing. Dependency management is
implemented in two different places.
A) The model builder uses the information from the dependency management
to update elements of dependencies without a value. This has nothing to
do with resolution. The model builder just copies missing elements from
the dependency management to the dependencies when building the
effective model. The model builder will not apply the management
information to dependencies overriding the management values in the
effective model. This appears to be inconsistent to what the resolver does.
B) The dependency management also is passed to the resolver and is used
to manage all dependency elements, regardless of what the model builder
provides (ArtifactDescriptorReader calls the model builder). It has
always been that way. Going into details here means we need to discuss
dependency management as it got introduced in Maven 2.0.x. When Maven
2.0 got released, dependency management had not been implemented.
Someone provided a patch via JIRA making it "work somehow". Browsing to
"Versions" in the MNG project in JIRA shows no 2.x versions anymore. I
cannot look this up. I think that patch got applied and released with
Maven 2.0.6. I am not sure this is the correct version. From there on,
it had always been kept compatible to that patch but has never been
working as intendet. Everyone got used to it that way so anything making
it behave differently will appear to be something unintended.
<https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=blob;f=maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/manager/ClassicDependencyManager.java;h=fefb9fbb563ea58a1d454a80e492395ac4df7ad6;hb=HEAD>
> Replacing the scope of the dependency from test back its default compile
> scope whereas the build fails due to missing this test-scoped dependency
> is weird. I don't have a good story why this new behavior should be
> better, so IMHO this change must be revisited. If that means we need to
> adjust documentation, that's fine by me.
As others have suggested, we maybe need to provide a command line option
for this. It's not only the 'test' scope. It's also about 'provided' and
'optional'. Anything non-transitive is affected. There also is the
change from 'ClassicDependencyManager' to 'TransitiveDependencyManager'
and other bugfixes to dependency management. We already have
--legacy-local-repository, so we maybe should just add
-ldm,--legacy-dependency-management
Use Maven 2 dependency management behaviour. Can also be activated by
using -Dmaven.legacyDependencyManagement=true.
There are a bunch of issues in JIRA affecting dependency management.
That option could be used to provide a way for users to be able to
switch to the Maven 2 management behaviour. Maybe with this option in
place it would make sense to log warnings whenever this option is used
providing guidance for changing POMs.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
