【问题标题】:Proper replacement for compile dependency正确替换编译依赖
【发布时间】:2019-11-21 03:57:46
【问题描述】:

这是我关于 gradle 驱动的纯 scala 项目的小问题系列之一。 接下来几天会发布更多内容。 编辑:鉴于对这个问题的反响不佳,我至少必须在发布之前对其进行修改。

几周前,我开始了一个新的私有 scala 项目,我想用 gradle 构建它。如果我只想做一些小的编辑,IDE 往往会在我的系统上启动时间很长,并且无法扩展。所以我选择了 gradle,因为我已经知道了(我也可以选择 sbt)。这也让我可以使用 IDE,以防我真的需要更多工具集,但大多数时候我只需要命令行。

我安装的最新版本是某个版本 2.x(在一段时间内仍然运行良好),然后我迅速升级到更新的 5.x 并且 - 部分测试新的插件语法 -前几天我也看了一下6.0。由于我的构建脚本中存在编译依赖项,这个最新版本给了我弃用警告。使用 6.0 版或多或少地使我的构建时间翻了一番,所以除非我真的需要一些新功能,否则我不会使用它,但是在使用 gradle 5.x 时,弃用警告仍然适用(如果不是更多的话)。

没问题,我想,因为 gradle-runtime 已经建议了如何修复它们。但是这种简单的用实现替换编译是行不通的,因为我(ab-)在我的代码中使用了编译依赖项的传递性。然后我希望其他人也有同样的问题。他们中有很多人提供了大量的指南来解决这个问题。不幸的是,没有一个适用于纯 scala 项目。对于 android 似乎是一个明显的 api 依赖解决方案。 Java 项目可以使用带有 api 依赖关系的 java-library 插件(这可能也是上述 android 项目解决方案的基础)。但是对于scala来说没有这样的方法,或者至少我还没有找到。

所以,要明确一点:我在这里有一个多项目设置,我只在与其他子项目的依赖关系上苦苦挣扎。不依赖于外部资源。并且替换运行时(用于外部库)和 testCompile 依赖项完全没有问题。

所以,这是我的问题:是否有适当/规范的方法来替换纯 scala 项目中的编译依赖项? (虽然几个小时前我对在我自己的一个 cmets 中使用“官方”并不特别满意,但是这个观点呢:不管是谁最初创建了 scala 插件(scala-team、scala-community、gradle-team,或 gradle-community),当时 gradle-team 决定将其包含在他们的发行版中,现在 gradle-team 决定将编译依赖项标记为已弃用。那么 gradle-team 不应该也有一个官方 关于如何继续维护 scala 项目的意见?)或者没有共同的建议,我只能在这些选项之间进行选择,无论出于何种原因,这些选项都不是最优的:

  1. 坚持编译依赖。从长远来看,绝对不是面向未来的
  2. 展开所有传递依赖并添加新的(技术上不必要的)依赖。如果 A 依赖于 B 并且 B 依赖于 C(并且 A 实际上使用来自 C 的定义),那么也添加从 A 到 C 的依赖关系。 膨胀依赖图和构建脚本
  3. 尽管我管理 scala 项目只是为了有一个 api 依赖项,但仍将 java 库应用到非应用程序项目中。 java-library 和 scala 都扩展了 java 插件,所以我希望这里没有真正的伤害。可能是最好的解决方案,尽管我不确定为单一依赖类型添加一个全新的插件是否是正确的选择。而且将任何“java”内容添加到“scala”项目似乎很奇怪
  4. 以某种方式重新发明轮子,并定义我自己的 api 依赖项。这似乎是最丑陋的方式,因为我必须从 gradle-repository 复制一些代码 到我自己的项目中。这就是插件的用途,不是吗。

提前致谢。

【问题讨论】:

  • 请参阅here,了解为什么这种主观问题不合适。
  • 我承认,我以前没有阅读过这个特定的指南,但你能详细说明一下,为什么你认为这是主观的?当然,我提出了一些建议,但只是为了帮助其他人了解我已经考虑到的内容。这并不是一个选择题测验,我不想看到哪个答案给出的最多。我的问题必须有一些官方的答案/解决方案,不是吗?而这个答案正是我要寻找的。​​span>
  • 这里的问题是什么?所有这些都非常主观,因为这些选择取决于您在.gradle 文件中所做的选择。 Gradle 允许如此高的灵活性,以至于对于大多数现实世界的 gradle 项目来说,做出客观的陈述是不可能的。对您的 gradle 构建适用于相同问题的方法可能不适用于其他 gradle 构建(甚至被认为是荒谬的)。
  • 更重要的是,我不喜欢所提供的每一个“选项”(至少是部分),并且我清楚地说明了每个选项的原因。所以我特别在寻找一些完全不同的方法。或者一些证据表明,没有这样的“正确”解决方案,而 gradle 对待 scala 程序员不像 - 说 - android 开发者那样受欢迎。
  • Gradle 并没有让任何开发人员感到受欢迎。 android 插件(和指南)由 android 开发人员和 google 开发。因此,如果 Scala 开发者社区愿意,他们可以投入 2-3 年时间来创建插件和指南的生态系统。而这正是android社区所做的……这并不容易,android + gradle在2013-2014年曾经是一个脆弱的难题,经过多年的改进,它变得一样好。

标签: scala gradle


【解决方案1】:

只需应用java-library 插件并使用api。将插件视为 Java 平台 库插件,而不是 Java 语言 库插件。

请注意,要充分发挥功能,您至少需要 Gradle 5.6,否则某些接线不完整。

【讨论】:

  • 我已经以某种方式预料到了,所以仍然感谢您的官方回答。你指的是5.6版。这是因为issue 9872吗? issue 8788 将我限制在至少 6.0 对我来说表现不佳怎么办?还是仅当我将 scala 和 java-library 应用于不同的项目时才适用?我会有一个 scala+java-lib 项目依赖于另一个 scala+java-lib 项目。
猜你喜欢
  • 1970-01-01
  • 2022-08-16
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多