37

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?

ROMANIA_engineer
  • 54,432
  • 29
  • 203
  • 199
Laird Nelson
  • 15,321
  • 19
  • 73
  • 127
  • Even after having read this question and the bug ticket, I do not really understand *how* I can actually override scope in a child module. In my case the project's parent POM declares a test dependency on groovy-all (used by Spock), but one child module actually needs groovy-all with a compile scope because it evaluates Groovy scripts during runtime. Even if the parent declares the dependency directly (not managed), the child cannot seem to override the scope for itself. It compiles fine, but misses the dependency during runtime or shading the parent's uber JAR. Can you pls help me? – kriegaex Mar 30 '14 at 07:34
  • Hmm, actually overriding scope basically works for compilation, so maybe this is a problem in the Maven Shade Plugin, after all. If I add the dependency in the module responsible for shading redundantly, it works, but this is not nice. What do you think? – kriegaex Mar 30 '14 at 08:53

2 Answers2

27

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

Andrey
  • 6,526
  • 3
  • 39
  • 58
Raghuram
  • 51,854
  • 11
  • 110
  • 122
  • 8
    Thank you; realizing that it takes precedence even for *scope* (not just version) was the key thing missing for me. – Laird Nelson Sep 30 '11 at 19:29
  • 2
    Is there any way to override the scope of a managed dependency in a child pom? – thecoop Apr 17 '15 at 12:24
  • @thecoop see http://stackoverflow.com/questions/31711024/jar-with-dependencies-and-a-managed-dependency/31711721?noredirect=1#comment51361414_31711721 – 6ton Jul 29 '15 at 22:51
0

The selected answer is good enough to clarify the key point that whether dependencyManagement takes precedence relies on whether the child dependency is declared explicitly or transitively.

As a plus, I just created a summary concerned with version & scope resolution to kill this problem totally:

dependency

Assuming that a dependency A is declared eight times in different ways, and each with a different version... which version will win last?

just remember the three rules in the picture:

  • explicit declaration > dependency-management declaration > implicit transitive declaration
  • 1st declaration > 2nd declaration
  • child declaration > parent declaration

and you will figure out the priority sequence shown as red numbered list in the picture.

YFlag
  • 51
  • 1
  • 3