使用 Eclipse 声明编译和运行时之间的瞬时依赖关系的最佳方法是什么？答案

【问题标题】：What is the best way to declare transient dependencies between compile and runtime with Eclipse?使用 Eclipse 声明编译和运行时之间的瞬时依赖关系的最佳方法是什么？
【发布时间】：2013-08-02 06:30:36
【问题描述】：

我们正在寻求改进我们在 Eclipse 上的 Java 构建过程。目前我们使用 Gradle！作为这项工作的一部分，我们正在研究是否以最佳方式使用 Gradle。我们使用 Gradle 的 Eclipse 插件并使用 compile 声明我们的依赖项。不幸的是，这增加了我们生成的 Eclipse 项目的大量临时依赖项，这是不可取的。这些额外的依赖项仅在运行时有效。

那么，有没有办法在 Gradle 中声明一个依赖 ONCE，并将其编译依赖设置为第一级依赖，并将其运行时依赖设置为第一级加上瞬态依赖？

目前我们在 compile 中使用 @jar 语法，这为我们提供了编译的第一级依赖项，但我们仍然必须再次声明该依赖项以供运行时使用。不理想，因为我们有两个地方可以去更新依赖项。

有没有更好的办法？

【问题讨论】：

我建议您创建一个非常简单的示例，准确显示您想要实现的目标，并在问题中提出。如果我理解正确，这就是 <optional>true</optional> 对 Maven 中的依赖项所做的事情。

标签： java maven ant build-process gradle

【解决方案1】：

我假设你的意思是传递依赖。

如果您只希望直接依赖项出现在 Gradle 的编译类路径上，那么您当前的解决方案似乎是合理的。（将来我们希望有一个更准确的开箱即用的编译类路径。）潜在的改进是使compile 配置不可传递（而不是使用@jar）或编写一个插件提供自定义依赖语法，从而消除编译和运行时依赖之间的重复。

但是，这对 Eclipse 没有帮助，因为 Eclipse 没有单独的编译和运行时类路径的概念。唯一的出路是让运行配置负责提供运行时类路径，但这可能很难设置（例如，运行配置通常是即时创建的），并且 Gradle 没有任何不合时宜的对此的开箱即用支持。您可以使用 Gradle 的 Eclipse 插件的通用 XML 挂钩来生成运行配置，但我不确定 Eclipse Gradle 集成是否会选择它们。

由于这些困难，大多数 Eclipse 开发人员将所有运行时依赖项放在 Eclipse 项目类路径上（无论他们是否使用 Gradle），尽管有明显的缺点。

我们的愿景是 Gradle 有朝一日可以充当 Eclipse 的构建引擎。一旦发生这种情况，IDE 和构建工具（类路径、代码生成、集成测试等）之间的差异将成为过去。 Gradle 现在已经可以充当 NetBeans 的构建引擎，很快也可以充当 IntelliJ IDEA（由 Android Studio 的需求驱动）。

【讨论】：

【解决方案2】：

虽然我当然同意@Peter 的观点，即彻底检查 Eclipse 构建过程是一个长期目标，但在短期内，您可能能够使用 Maven 和 m2eclipse 完成您想要的。迁移到 Maven 的权衡是否值得额外控制完全取决于您。

【讨论】：

我不明白这将如何解决手头的问题，因为 Maven 在编译类路径上也放了太多东西。充其量，您必须以 Richard 已经为他的 Gradle 构建所做的相同方式重新配置 Maven 构建，我认为从 Eclipse 执行代码时会导致类似的问题。
这不是一个很好的解决方案，但 m2eclipse 确实可以正确管理编译和运行时类路径。
正确定义。 Maven 在自己的编译类路径上放了太多东西，m2eclipse 不会有什么不同。并且可能 m2eclipse 至少使用 Maven 编译类路径（如果不是运行时）作为 Eclipse 类路径，我认为它仍会以某些方式使用（例如，用于编辑/搜索/导航）。
我的意思是，使用 m2eclipse 运行的构建将使用与使用 Maven 独立运行的构建相同的类路径（与我理解的 Gradle 和 Eclipse 类路径不匹配的问题相反）。
这当然很好，但它不会解决 Richard 的问题，因为（Maven 编译和）Eclipse 类路径上有太多东西。他仍然会得到大量的传递依赖。