我们正在寻求在 Eclipse 上改进我们的 Java 构建过程。目前我们使用 Gradle！作为这项工作的一部分，我们正在研究是否以最佳方式使用 Gradle。我们使用 Gradle 的 Eclipse 插件并使用 compile 声明我们的依赖项。不幸的是，这增加了我们生成的 Eclipse 项目的大量临时依赖项，这是不可取的。这些额外的依赖项仅在运行时有效。
那么，有没有办法在 Gradle 中声明一个依赖项，并将其编译依赖项设置为第一级依赖项，并将其运行时依赖项设置为第一级加上瞬态依赖项？
目前我们在编译时使用@jar 语法，它为我们提供了编译的第一级依赖项，但我们仍然必须再次声明该依赖项以供运行时使用。不理想，因为我们有两个地方可以去更新依赖项。
有没有更好的办法？
我假设你的意思是传递依赖。
如果您只希望直接依赖项出现在 Gradle 的编译类路径上，那么您当前的解决方案似乎是合理的。（将来我们希望有一个更准确的开箱即用的编译类路径。）潜在的改进是使compile配置不可传递（而不是使用@jar）或编写一个提供自定义依赖语法的插件，从而消除了编译和运行时依赖项之间的重复。
但是，这对 Eclipse 没有帮助，因为 Eclipse 没有单独的编译和运行时类路径的概念。唯一的出路是让运行配置负责提供运行时类路径，但这可能很难设置（例如，运行配置通常是即时创建的），并且 Gradle 没有任何不合时宜的对此的开箱即用支持。您可以使用 Gradle 的 Eclipse 插件的通用 XML 挂钩来生成运行配置，但我不确定 Eclipse Gradle 集成是否会选择它们。
由于这些困难，大多数 Eclipse 开发人员将所有运行时依赖项放在 Eclipse 项目类路径上（不管他们是否使用 Gradle），尽管有明显的缺点。
我们的愿景是 Gradle 有朝一日可以充当 Eclipse 的构建引擎。一旦发生这种情况，IDE 和构建工具（类路径、代码生成、集成测试等）之间的差异将成为过去。Gradle 现在已经可以充当 NetBeans 的构建引擎，很快也可以充当 IntelliJ IDEA（由 Android Studio 的需求驱动）。
虽然我当然同意@Peter 的观点，即彻底检查 Eclipse 构建过程是一个长期目标，但在短期内，您可能能够使用 Maven 和 m2eclipse 完成您想要的。迁移到 Maven 的权衡是否值得额外控制完全取决于您。