Maven dependency resolution and scope overriding
Disclaimer
(I originally asked the question in a very detailed manner over here. I've excer开发者_如何学JAVApted 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?
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
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:
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.
精彩评论