[MNG-5404] Wrong resolution of dependency scope by Maven 3

[jira-importer]

Dmitry Batrak opened MNG-5404 and commented

For the following POM:

<project> 
    <modelVersion>4.0.0</modelVersion> 

    <groupId>test</groupId> 
    <artifactId>A</artifactId> 
    <version>1.0</version> 

    <dependencies> 
        <dependency> 
            <groupId>org.apache.axis2</groupId> 
            <artifactId>axis2-xmlbeans</artifactId> 
            <version>1.5</version> 
            <scope>provided</scope> 
        </dependency> 
        <dependency> 
            <groupId>org.apache.axis2</groupId> 
            <artifactId>axis2-codegen</artifactId> 
            <version>1.5</version> 
            <exclusions> 
                <exclusion> 
                    <groupId>org.apache.geronimo.specs</groupId> 
                    <artifactId>geronimo-stax-api_1.0_spec</artifactId> 
                </exclusion> 
            </exclusions> 
        </dependency> 
    </dependencies> 
</project> 

running 'mvn dependency:resolve' using Maven 3.0.4 yields a wrong result.
Namely, geronimo-stax-api_1.0_spec dependency is reported as having the resolved scope of 'compile'. With Maven 2.2.1 I get the 'provided' scope, as expected.

Debug log is attached.

---

Affects: 3.0.4

Attachments:

• build.log (21.22 kB)
• compile-as-transitive-of-provided.tgz (15.96 kB)
• example.zip (402 bytes)

Issue Links:

• MNG-5622 Provided dependencies updated to 'compile' even when excluded

Backported to: needing-scrub-3.4.0-fallout

2 votes, 7 watchers

[jira-importer]

Robert Balazsi commented

I've found two documents with mutually exclusive specifications regarding this:

http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope -> nearest="provided", farthest="compile" => result="provided" (as you described)
http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Scoperesolution -> ... => result="compile"

I'm not sure which one should be respected. Let's assume that the result should be "provided", as you pointed out.

Note then, that "mvn dependency:tree" displays the correct result. After some investigation, I found that this is because DefaultDependencyTreeBuilder uses DefaultArtifactCollector (in the "maven-artifact" project) that does some scope update (has a method checkScopeUpdate(...), etc.).
However, the AbstractDependencyFilterMojo (which is the non-direct base class of ResolveDependenciesMojo that is called on "mvn dependency:resolve") relies on "project.getArtifacts()" filled previously by the DefaultProjectDependenciesResolver, which in turn, calls Aether's DefaultRepositorySystem.resolveDependencies(...) method.
This method resolves the scope conflict in question as "compile" so I guess Aether implements it a different way.

Note that there are several issues (such as MNG-5188 and MNG-5145) that are related to dependency scope resolution.

Actually, I'm not that familiar with the code, I was just debugging to see how it works. :-)

[jira-importer]

Dmitry Batrak commented

Please note that in the above example geronimo-stax-api_1.0_spec is explicitly excluded from transitive dependencies of axis2-codegen, so I don't expect its scope in that path to have any effect on the resulting scope.

[jira-importer]

Jason van Zyl commented

Please read https://cwiki.apache.org/confluence/display/MAVEN/Submitting+Issue+for+Maven%27s+Core

[jira-importer]

Dmitry Batrak commented

I've already shown pom.xml with which the issue can be reproduced, nothing else is required. Just in case you need the same as a file in a zip archive, I'm attaching it.

[jira-importer]

Renat Sabitov commented

I also can see this in Maven 3.3.9.

What I noticed is that the scope stopped being upgraded to compile if you exclude everything from the compile scoped dependency via

<exclusions>
    <exclusion>
        <groupId>*</groupId>
        <artifactId>*</artifactId>
    </exclusion>
</exclusions>

Adding my replicator for the bug. Use as:

mvn -X -f provided.xml dependency:tree
mvn -X -f compile.xml dependency:tree

Also, adding -Dverbose option to the compile.xml POM stops the scope upgrade.