是否存在依赖工件的Maven“仅编译器”范围

Question

我意识到这更多是语义任务，而不是功能任务。

我有三种类型的编译范围依赖项：

1. 仅编译范围，不在运行时使用。 GWT客户端开发，MVP4G，RestyGWT，源保留注释处理器。我使用REST，所以我不需要GWT服务器端。

2. 提供 - 编译所需的Hibernate jar，但是由JBoss提供。

3. 编译+运行时jar。

对于案例2，我们可以使用提供的范围。案例3，我们将使用编译范围。

但是对于案例1，我使用提供的范围，即使JBoss根本不提供这些文件。它们也不是在运行时需要的。

无论如何，你不认为Maven应该提供“提供”的同义词，除了在编译时，除了编译时不需要人工制品吗？或许，是否应该有“仅编译”范围？

Answer 1

如果你只知道一半的词汇量，不要抱怨语言没有提供细微的区别。

如果依赖项仅用于构建（例如注释处理器），则它应该是maven <plugin>或<dependency>。

否则，如果它在编译类路径中，则需要在运行时链接生成的类文件。然后，有两种情况：

1. 始终需要加载该类
   1. 该课程应作为申请的一部分发运：<scope>compile</scope>
   2. 该类应由运行时环境提供：<scope>provided</scope>
2. 有时需要（因为该类仅在特定情况下加载）：<optional>true</optional>

唯一没有涉及的选项是编译Java程序，而不是在JVM中运行它。这是一个非常模糊的用例，我不能指责maven的设计者因为不包括范围只是为了表达这种区别 - 特别是因为它与Maven的核心职责（构建软件）无关。

Answer 2

如果jar不是真正的“运行时”依赖项（仅用于构建）而不是最终工件，则可以通过各种方式排除它们：

1. 排除汇编描述符
2. 排除在jar（或战争，耳朵，无论如何）插件配置
3. Shade Plugin minimize jar目标

我同意运送不必要的课程很烦人（我在生产部署中看过junit和testng jars - brrrr ......），但是出于所有实际目的，这是一个相当小的课程。

如果你有一个依赖冲突（即发送一个库或框架的“所有deps”版本），这是一个不同的故事，但听起来不像你在这里面临的那样。