Maven dependency resolution and scope overriding

Question

Disclaimer

(I originally asked the question in a very detailed manner over here. I've excerpted it here as the maven-users mailing list has gone quiet on this question.) (not just another newbie question)

Reference

My reference material is http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management; please let me know in this discussion if this is outdated or wrong.

Question

There is a section in that document that begins with "A second, and very important...". In what follows I'll refer to that section's projects A and B, and will excerpt from them.

In that section, you will see that project A has a <dependencyManagement> section that--among other things--defines an artifact, c, as having scope compile:

<!-- In A's pom.xml; condensed for brevity -->
<dependencyManagement>
    <dependency>
        <groupId>test</groupId>
        <artifactId>c</artifactId>
        <version>1.0</version>
        <scope>compile</scope> <!-- look: compile scope -->
    </dependency>
</dependencyManagement>

Then you will see a pom.xml for project B that (a) inherits from project A (thus inheriting its dependencyManagement section) and (b) establishes a dependency on artifact c, without having to specify its version. You will also notice that the dependency on artifact c overrides the scope of c to be runtime, not compile:

<!-- In B's pom.xml, whose parent is A's pom.xml (above); condensed for brevity -->
<dependencies>
    <dependency>
        <groupId>test</groupId>
        <artifactId>c</artifactId>
        <scope>runtime</scope> <!-- look: runtime scope -->
    </dependency>
</dependencies>

Again, you'll note that there is no <version> element, but there is a <scope>runtime</scope> element.

My interpretation of this is that when all is said and done, B will depend on version 1.0 of artifact c in runtime scope, not compile scope.

Is that correct? My maven-ear-plugin bug rests on the fact that this is the expected behavior. It is not what happens when the maven-ear-plugin builds an .ear file.

Next, if that's correct, I would also expect that if artifact c had any transitive runtime dependencies they would be available in B's runtime classpath (as defined by the somewhat baffling table in http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope).

Is that correct?

Solution

Running mvn dependency:tree on the sample project posted in the bug link specified above,

[INFO] Building MEAR-143 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.3:tree (default-cli) @ mear-143 ---
[INFO] ljnelson:mear-143:pom:1.0-SNAPSHOT
[INFO] \- junit:junit:jar:4.8.2:test
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building MEAR-143 Leaf 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.3:tree (default-cli) @ mear-143-leaf ---
[INFO] ljnelson:mear-143-leaf:jar:1.0-SNAPSHOT
[INFO] \- junit:junit:jar:4.8.2:test
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building MEAR-143 Middle 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.3:tree (default-cli) @ mear-143-middle ---
[INFO] ljnelson:mear-143-middle:jar:1.0-SNAPSHOT
[INFO] +- ljnelson:mear-143-leaf:jar:1.0-SNAPSHOT:runtime
[INFO] \- junit:junit:jar:4.8.2:test
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building MEAR-143 EAR 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.3:tree (default-cli) @ mear-143-ear ---
[INFO] ljnelson:mear-143-ear:ear:1.0-SNAPSHOT
[INFO] +- ljnelson:mear-143-middle:jar:1.0-SNAPSHOT:runtime
[INFO] |  \- ljnelson:mear-143-leaf:jar:1.0-SNAPSHOT:test (scope managed from ru
ntime)
[INFO] \- junit:junit:jar:4.8.2:test

The dependency scope of mear-143-leaf in mear-143-middle, where the dependency is explicitly defined is indeed runtime, overriding the test scope defined in the dependencyManagement section of parent pom, mear-143.

In mear-143-ear, mear-143-leaf gets included transitively. Here the test scope defined in dependencyManagement of mear-143 takes precedence over the inherited runtime scope.

This, I guess is in line with what is specified in the second bullet point in the section you have referred above. Quoting it here and highlighting in bold and italics the relevant parts:

b is defined in B's parent's dependency management section and since dependency management takes precedence over dependency mediation for transitive dependencies, version 1.0 will be selected should it be referenced in a or c's pom. b will also have compile scope

Comments

[Laird Nelson]

Thank you; realizing that it takes precedence even for scope (not just version) was the key thing missing for me.

[thecoop]

Is there any way to override the scope of a managed dependency in a child pom?

[6ton]

@thecoop see stackoverflow.com/questions/31711024/…