我意识到这更像是一种语义上的追求，而不是功能性的追求。
我有三种类型的编译范围依赖关系：
仅编译作用域，不在运行时使用。GWT客户端开发，MVP4G，RestyGWT，源保留注释处理器。我使用REST，所以我不需要GWT服务器端。
提供 - 编译所需的休眠罐，但由 JBoss 提供。
编译 + 运行时 jar。
对于案例 2，我们可以使用提供的范围。案例 3，我们将使用编译范围。
但是，对于情况 1，我使用提供的范围，即使 JBoss 根本不提供这些文件。在运行时也不需要它们。
无论如何，你不认为Maven应该为“提供”提供一个同义词，用于除了编译时之外才真正需要人工制品的范围吗？也许，是否应该有一个“仅编译”的范围？
不要抱怨，如果你只知道它的一半词汇，那么这门语言就没有很好的区别。
如果依赖项仅用于构建，例如注释处理器，则它应该是 maven 或其。<plugin><dependency>
否则，如果它位于编译类路径中，则需要在运行时链接生成的类文件。然后，有两种情况：
<scope>compile</scope>
<scope>provided</scope>
<optional>true</optional>
唯一未涵盖的选项是编译 Java 程序，并且永远不要在 JVM 中运行它。这是一个非常晦涩难懂的用例，我不能责怪maven的设计师没有包括一个范围来表达这种区别 - 特别是因为它与Maven的核心责任（构建软件）无关。
如果 带有 的 jar 不是真正的“运行时”依赖项（仅用于构建），但不适用于最终工件，则可以通过各种方式将其排除：
我同意发布不必要的类很烦人（我已经在生产部署中看到过 junit 和 testng jar - brrrr...），但对于所有实际目的来说，这是一个相当小的问题。
如果你有一个依赖冲突（即发布一个库或框架的“所有部门”版本），那就是一个不同的故事，但听起来不像你在这里面对的。
