是否存在依赖工件的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(或war,ear,无论如何)插件配置中排除
3. Shade Plugin最小化jar目标

我同意运送不必要的课程很烦人(我在生产部署中看到了junit和testng jars - brrrr ......),但是出于所有实际目的,它是一个相当小的一个.

如果你有一个依赖冲突(即运送一个库或框架的"所有deps"版本),这是一个不同的故事,但听起来不像你在这里面对的.