(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)
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.
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?
By taking advantage of Maven's nearest definition logic, developers can override the version of a dependency by declaring it on the root pom. xml file.
Dependency scope is used to limit the transitivity of a dependency and to determine when a dependency is included in a classpath. This is the default scope, used if none is specified. Compile dependencies are available in all classpaths of a project. Furthermore, those dependencies are propagated to dependent projects.
Maven has six default dependency scopes. And it's important to understand that each scope — except for import — has an impact on transitive dependencies.
Maven Dependency Tree Transitive dependency means that if A depends on B and B depends on C, then A depends on both B and C. Sometimes, transitivity brings a very serious problem when different versions of the same artifacts are included by different dependencies. It may cause version mismatch issues in runtime.
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With