我意识到这更像是一种语义上的探索，而不是功能上的探索。
我有三种类型的编译范围依赖：
- GWT客户端dev，MVP 4G，RestyGWT，Source retention annotation processors。我使用REST，所以我不需要GWT服务器端。
1.提供-编译所需的Hibernate jar，但由JBoss提供。
1.编译+运行时jar。
对于第二种情况，我们可以使用提供的作用域。第三种情况，我们将使用编译作用域。
但是对于案例1，我使用了提供的作用域，尽管JBoss根本不提供这些文件，在运行时也不需要它们。
无论如何，你不认为Maven应该为一个作用域提供一个“provided”的同义词吗？在这个作用域中，除了在编译时之外，工件并不真正需要。也许，应该有一个“compile-only”作用域吗？
2条答案
按热度按时间y53ybaqx1#
如果依赖项仅用于构建，例如注解处理器，则它应该是maven
<plugin>或其<dependency>。否则，如果它在编译类路径中，则需要在运行时链接生成的类文件。那么，有两种情况：
1.总是需要加载该类
1.类应该作为应用程序的一部分提供：
<scope>compile</scope>1.类应该由运行时环境提供：
<scope>provided</scope>1.这有时是必要的（因为该类仅在特定情况下才会被加载）：
<optional>true</optional>唯一没有涉及的选项是编译Java程序，并且永远不要在JVM中运行它。这是一个非常模糊的用例，我不能责怪maven的设计者没有包括一个范围来表达这种区别-特别是因为它与Maven的核心职责（构建软件）无关。
5vf7fwbs2#
如果带有的jar不是真正的“运行时”依赖项（仅用于构建），而不是最终工件，您可以通过各种方式排除它们：
1.程序集描述符中的排除
我同意运送不必要的类是令人讨厌的（我在生产部署中见过junit和testng jar- brrrr.），但对于所有实际目的来说，这是一个相当小的问题。
如果你有一个依赖冲突（即发布一个库或框架的“所有deps”版本），那就是另一回事了，但听起来不像你在这里面临的。