title: Maven dependency resolution and scope overriding
body: <h3>Disclaimer</h3>
  
  <p>(I originally asked the question in a very detailed manner <a href="http://maven.40175.n5.nabble.com/Dependency-resolution-and-dependencyManagement-overriding-of-scope-td4849396.html" rel="noreferrer">over here</a>.  I've excerpted it here as the <code>maven-users</code> mailing list has gone quiet on this question.) (not just another newbie question)</p>
  
  <h3>Reference</h3>
  
  <p>My reference material is
  <a href="http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management" rel="noreferrer">http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management</a>; please let me know in this discussion if this is outdated or wrong.</p>
  
  <h3>Question</h3>
  
  <p>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 <code>A</code> and <code>B</code>, and will excerpt from them.</p>
  
  <p>In that section, you will see that project <code>A</code> has a <code>&lt;dependencyManagement&gt;</code> section that--among other things--defines an artifact, <code>c</code>, as having scope <code>compile</code>:</p>
  
  
  
  <pre class="lang-xml prettyprint-override"><code>&lt;!-- In A's pom.xml; condensed for brevity --&gt;
  &lt;dependencyManagement&gt;
      &lt;dependency&gt;
          &lt;groupId&gt;test&lt;/groupId&gt;
          &lt;artifactId&gt;c&lt;/artifactId&gt;
          &lt;version&gt;1.0&lt;/version&gt;
          &lt;scope&gt;compile&lt;/scope&gt; &lt;!-- look: compile scope --&gt;
      &lt;/dependency&gt;
  &lt;/dependencyManagement&gt;
  </code></pre>
  
  <p>Then you will see a <code>pom.xml</code> for project <code>B</code> that (a) inherits from project <code>A</code> (thus inheriting its <code>dependencyManagement</code> section) and (b) establishes a dependency on artifact <code>c</code>, without having to specify its <code>version</code>.  You will also notice that the dependency on artifact <code>c</code> overrides the scope of <code>c</code> to be <code>runtime</code>, not <code>compile</code>:</p>
  
  <pre class="lang-xml prettyprint-override"><code>&lt;!-- In B's pom.xml, whose parent is A's pom.xml (above); condensed for brevity --&gt;
  &lt;dependencies&gt;
      &lt;dependency&gt;
          &lt;groupId&gt;test&lt;/groupId&gt;
          &lt;artifactId&gt;c&lt;/artifactId&gt;
          &lt;scope&gt;runtime&lt;/scope&gt; &lt;!-- look: runtime scope --&gt;
      &lt;/dependency&gt;
  &lt;/dependencies&gt;
  </code></pre>
  
  <p>Again, you'll note that there is no <code>&lt;version&gt;</code> element, but there is a <code>&lt;scope&gt;runtime&lt;/scope&gt;</code> element.</p>
  
  <p>My interpretation of this is that when all is said and done, <em><code>B</code> will depend on version <code>1.0</code> of artifact <code>c</code> in <code>runtime</code> scope, not <code>compile</code> scope.</em></p>
  
  <p>Is that correct? <a href="https://jira.codehaus.org/browse/MEAR-143" rel="noreferrer">My <code>maven-ear-plugin</code> bug</a> rests on the fact that this is the expected behavior.  It is not what happens when the <code>maven-ear-plugin</code> builds an <code>.ear</code> file.</p>
  
  <p>Next, if that's correct, I would also expect that if artifact <code>c</code> had any transitive <code>runtime</code> dependencies they would be available in <code>B</code>'s <code>runtime</code> classpath (as defined by the somewhat baffling table in <a href="http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope" rel="noreferrer">http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope</a>).</p>
  
  <p>Is that correct?</p>