2

我的 Eclipse 工作区中有几个 gradle 项目。为简单起见，我只对其中 2 个真正感兴趣，让我们只使用 A 和 B。

所以我遇到的问题是项目 A 包含对 JBoss 的依赖，它引入了 javax validation-api 1.0.0.GA，而项目 B 依赖于 javax validation-api 1.1.0.Final。由于 Gradle 本身首先通过使用较新的库来解决冲突，所以 B 在使用 gradle 构建时很高兴。但是 Eclipse 本身包含在编辑时非常分散注意力的错误。

validation-api jar 的正确版本最终出现在 B 的类路径中，但问题是 Gradle IDE 插件将 project(':A') 依赖项更改为项目引用，并且 Eclipse 似乎将项目引用优先于外部罐子。因此，旧 jar 被扩展首选。

我尝试{ exclude module: 'validation-api' }在 B 的 build.gradle 中添加对 A 的依赖项，该依赖项根据“gradle dependencies”的输出工作，但是由于 Eclipse 只是将其作为项目引用，因此它不会排除 jar 并且问题仍然存在.

同样根据这个问题，我尝试添加{ transitive = false }并且发生了同样的事情。我认为即使是那里提出的 hack 也不会对我有用，因为 .classpath 包含对 Gradle 容器的单个引用，所以没有什么可以删除的。

我设法通过从我的 gradle 缓存中明确包含对正确版本 jar 的引用，然后将其移动到 Gradle 类路径容器上方，以便 eclipse 首先看到该版本来解决这个问题。

我的问题是：有没有更好/更通用的方法来做到这一点？最好是我可以在不破坏其他人的构建或要求他们在某处手动修改路径或属性的情况下致力于源代码控制的一种？还有另一个项目似乎有类似的问题，所以我可以在 build.gradle 文件中修复的东西会很棒。

最坏的情况是，如果 IntelliJ 的表现比 Eclipse-Gradle 集成更好，我可能会切换到 IntelliJ？

4

1 回答 1

1

这些传递依赖问题是 Gradle Eclipse 集成的长期问题（在 STS 工具中以及从 Gradle 的 Eclipse 插件命令行生成的 .classpath 元数据中。问题是 Eclipse 计算传递类路径的方式。

直到最近我们才找到了解决这个问题的合理方法。实际上，现在有两种解决方案，一种比另一种更好，但根据您的情况，您可能希望使用其中任何一种。

第一个解决方案是一个错误修复，它更改了项目依赖项的类路径顺序，因此它们不再“首选”于 jar 依赖项 PR-74。要获得此修复，您可能需要从快照更新站点安装 gradle 工具，因为修复是在 3.6.3 之后进行的。

此解决方案并不能解决真正的问题（您仍然在类路径中有“错误”的东西），但只会降低在您的项目中引起真正问题的可能性。

第二种解决方案是启用在 STS 3.6.3 中引入的“自定义工具 API 模型” PR-55 。这有点实验性，仅适用于最新版本的 Gradle，至少 1.12，但使用 2.x 可能更好。它也仅适用于启用了“依赖管理”的项目（如果未启用，您使用的是由 Gradle 的 eclipse 插件生成的 .classpath，该插件与 STS 工具具有相同的“损坏”类路径问题）。

“自定义工具模型”原则上确实是更好的解决方案，因为它修复了 gradle 类路径映射到 eclipse 项目的方式，因此不再导出项目依赖项，并且每个项目都有自己的类路径，考虑到依赖项冲突解决方案。

要启用此功能，请转到“Window >> Preferences >> Gradle”并启用复选框“Use Custom Tooling Model”。

于 2015-01-16T17:50:35.803 回答