Dependency resolution and dependencyManagement: overriding of scope?

[Laird Nelson <lj...@gmail.com>]

I submitted a bug on the maven-ear-plugin:
http://jira.codehaus.org/browse/MEAR-143

I think that in the comments I'm being told that dependency management works
in a particular way that I don't see any (documentation) evidence for.  I am
happy to admit I am wrong, if indeed I am wrong.

I would like to educate myself on how dependency management really works so
that either I can close the bug or figure out what the root cause is.

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 project 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.

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?

Thank you for the education.

Best,
Laird

-- 
http://about.me/lairdnelson