27

我意识到这更多是语义上的追求，而不是功能上的追求。

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

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

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

  3. 编译 + 运行时 jar。

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

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

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

4

2 回答 2

13

如果你只知道它的一半词汇，不要抱怨这种语言没有很好的区别。

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

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

  1. 总是需要加载该类
    1. 该类应作为应用程序的一部分提供：<scope>compile</scope>
    2. 该类应由运行时环境提供：<scope>provided</scope>
  2. 有时是必要的（因为该类仅在特定情况下才会加载）：<optional>true</optional>

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

于 2012-10-10T17:01:25.840 回答
8

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

  1. 程序集描述符中的排除
  2. jar（或war、ear等）插件配置中的排除
  3. Shade Plugin 最小化 jar目标

我同意运送不必要的类很烦人（我已经在生产部署中看到了 junit 和 testng jar - brrrr ...），但出于所有实际目的，这是一个相当小的问题。

如果你有一个依赖冲突（即交付一个库或框架的“所有部门”版本），那就是另一回事了，但听起来不像你在这里所面临的。

于 2012-10-10T20:44:53.010 回答