【发布时间】：2019-07-04 03:59:58
【问题描述】：
免责声明
（我最初以非常详细的方式提出了这个问题over here。我在这里摘录了它，因为maven-users 邮件列表已经对这个问题保持沉默。）（不仅仅是另一个新手问题）
参考
我的参考资料是 http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management;如果这已过时或错误，请在此讨论中告诉我。
问题
该文档中有一节以“第二个，非常重要...”开头。在下文中，我将参考该部分的项目A 和B，并将从中摘录。
在该部分中，您将看到项目A 有一个<dependencyManagement> 部分，除其他外，该部分定义了一个工件c，其范围为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>
然后您将看到项目 B 的 pom.xml，它 (a) 继承自项目 A（因此继承了其 dependencyManagement 部分）并且 (b) 建立了对工件 c 的依赖关系，而无需指定其version。您还会注意到，对工件 c 的依赖将 c 的范围覆盖为 runtime，而不是 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>
同样，您会注意到没有 <version> 元素，但有一个 <scope>runtime</scope> 元素。
我对此的解释是，当一切都说完了，B 将取决于runtime 范围内的工件c 的版本1.0，而不是compile 范围。
正确吗？ My maven-ear-plugin bug 基于这是预期行为的事实。 maven-ear-plugin 构建 .ear 文件时不会发生这种情况。
接下来，如果这是正确的，我还希望如果工件 c 有任何传递 runtime 依赖项，它们将在 B 的 runtime 类路径中可用（由 @ 中有些令人费解的表定义987654324@).
对吗？
【问题讨论】：
-
即使在阅读了这个问题和 bug 票之后，我仍然不明白 如何 我实际上可以覆盖子模块中的范围。在我的例子中，项目的父 POM 声明了对 groovy-all（Spock 使用）的测试依赖，但一个子模块实际上需要具有编译范围的 groovy-all，因为它在运行时评估 Groovy 脚本。即使父级直接声明依赖项（非托管），子级似乎也无法覆盖自身的范围。它编译得很好，但在运行时错过了依赖关系或遮蔽了父级的 uber JAR。你能帮帮我吗？
-
嗯，实际上覆盖范围基本上适用于编译，所以也许这毕竟是 Maven Shade 插件中的一个问题。如果我在负责冗余着色的模块中添加依赖项，它可以工作，但这并不好。你怎么看？
标签： maven dependency-management maven-ear-plugin