比较 sbt 和 Gradle [关闭]答案

【问题标题】：comparing sbt and Gradle [closed]比较 sbt 和 Gradle [关闭]
【发布时间】：2012-06-19 04:31:32
【问题描述】：

我正在研究 Scala 并注意到了 sbt。我对 Java/groovy 项目中的 Gradle 非常满意，而且我知道 Gradle 有一个 scala 插件。

在 Scala 项目中偏爱 sbt 而不是 Gradle 的充分理由是什么？

【问题讨论】：

SBT 在某种意义上就像一个 Vim：如果你了解它，你会很高兴。顺便说一句，还有 maven 和 lein（是为 clojure 创建的，但也适用于 scala）。
不要因为迁移到 SBT 而感到压力。 Scala 社区的一些知名成员使用 Gradle。相反，将 SBT 用作实验，知道您可以只使用 Gradle。
谢谢大家...阅读了您的见解后，我将坚持使用 Gradle。在我看来，当我们将 Maven 抛在身后时，JVM 领域的大多数构建工具工作都将在这方面进行。
令人讨厌的是，这个问题在这里被标记为“基于意见”，可能是那些不一直在 JVM 空间工作的人（因此缺乏监督）。下面的答案是真实的，没有圣战主义的。
不，这些答案主要是对可测试事实的陈述，而不是意见。虽然这个问题可能引来无用的答案，但事实上并没有这样做。它应该保持打开状态，作为对工具之间实际差异的有用描述。

标签： scala sbt gradle

【解决方案1】：

请注意，SBT 和 Gradle 之间的一个关键区别在于其依赖管理：

SBT：Ivy，带有一个可以作为固定版本（例如 1.5.2）或最新（或动态）版本的版本。
见“Ivy Dependency”
这意味着“-SNAPSHOT”机制支持可能会出现问题，即使 Mark Harrah 中有详细信息 this thread：

缓存可能会混淆是真的，但 Ivy 不理解解析快照并不是真的。 Eugene 在另一个线程中解释了这一点，也许在管理员列表中。 0.12 中解决了 sbt 的自动更新问题。

据我所知，Ivy 不支持以 Maven 的方式发布快照。我相信我已经在别处说明了这一点，但如果有人想改善这种情况，我认为最好与 Gradle 团队合作以重用他们的依赖管理代码。

Gradle：This thread 提及（Peter Niederwieser）：

让您知道，Ivy 和 Maven 快照依赖项的问题是 Gradle 最终用自己的依赖项管理代码替换 Ivy 的原因之一。这是一项艰巨的任务，但给我们带来了很多好处。

This tweet 提到未来所有情况都可能发生变化：

Mark 过去曾说过，他对使用 Gradle 而不是 Ivy 进行 SBT 很感兴趣。

（两个工具都可以learn from each other）

【讨论】：

我遇到的最不方便的是 sbt 是你不能指定规则在每次提到它时都不重新编译。 java 和 scala 的内置规则具有此功能，但未公开用于编写自定义规则。因此，每次您生成程序文件或文档时，即使您生成 jar 文件，您的任务也会在每次调用时执行，而不管是否实际完成了对源的任何更改。即使 make 也足够聪明，但不是 sbt
@ayvango 现在的 sbt 并非如此。有很多插件使用了这个功能，比如android-sdk-plugin
您知道该功能使用什么 API 吗？
所以与 maven 和 gradle 相比，这是 ivy 所缺乏的吗？这很奇怪

【解决方案2】：

对我来说，SBT 的主要特点是：

快速编译（比fsc 更快）。
持续编译/测试：命令~test 将在您每次保存修改时重新编译并测试您的项目。
跨多个 Scala 版本的交叉编译和交叉发布。
自动检索具有正确 scala 版本兼容性的依赖项。

缺点是：

一种会阻碍新用户（尤其是来自 Java 的用户）的象形文字语法
没有简单的方法来定义“任务”：如果您需要特殊的构建过程，您将需要找到一个插件，或者自己编写一个插件。

【讨论】：

由于 Scala 存在向后二进制不兼容的问题，我是否正确地认为需要交叉编译/发布功能？
是的。当迁移到 Scala 2.10 时，这些问题可能会再次发生。
我还要补充两个不同之处： * 在 SBT 中，更容易自我管理依赖关系，IMO。 * SBT 测试运行器似乎更快；我怀疑这里涉及到一些狡猾的并发，但我猜。 SBT 似乎是一个功能更强大但不太成熟的产品。
+1 表示“象形文字语法”的缺点。这是我对 SBT 最大的不满。运算符重载总是导致滥用：-/
神秘的 SBT 语法带来了 scala 中最糟糕的情况。 Gradle 基于经过深思熟虑的领域模型和直截了当的语法。

【解决方案3】：

sbt 是 Scala DSL，对于它来说 Scala 是一等公民，所以原则上它似乎很合适。

但是 sbt 存在版本之间的主要不兼容更改，这使得很难为任务找到正确的工作插件并使其工作。

我个人放弃了 sbt，因为它造成的问题多于解决的问题。我实际上切换到了 gradle。

去看看。

【讨论】：

据我所知，只有一个非常大的变化：当 sbt 从 0.7.x 切换到 0.1.x 时
如果你使用sbt 0.11.2的插件，然后再去sbt 0.12，需要等待插件作者编译新版本或者自己做。 idea-sbt 就是一个例子。
@fmpwizard sbt 0.12 行尚未发布...停止传播 FUD。
不是 sbt 无法使用，我们的团队使用它。但我的评论是支持这个答案，它说“......但是 sbt 在版本之间存在重大不兼容的变化，这使得很难找到正确的工作插件并让它工作......”就像你注意到的，我不能只使用 scct 插件，我必须修改它（是的小改动，但后来我必须将它发布到某个地方，以便我的整个团队都可以访问它）无缘无故的痛苦。
你能用 gradle 为不同的 Scala 版本做交叉编译吗？

【解决方案4】：

我对 gradle 还很陌生，对 sbt 也很陌生——到目前为止，我真正喜欢 sbt 的是交互式控制台。它允许我使用“检查”之类的命令来更好地了解正在发生的事情。 AFAIK gradle 不提供这样的自动取款机。

【讨论】：

【解决方案5】：

Sbt 和 gradle，都是基于静态类型语言的....但是 sbt 没有什么优势：

更好的插件支持，特别是自动插件
任务创建和任务之间的依赖管理
sbt 特别适合 scala 项目，因为它支持增量构建，并且大部分 sbt 本身是用 scala 编写的，而 sbt 构建定义是用 scala 编写的
sbt 具有交互式 shell 支持以及许多有用的内置任务
sbt 默认生命周期非常有用，新手可以轻松上手

【讨论】：

Gradle 基于 groovy，它不是静态类型语言。
Gradle 在任务之间进行依赖管理，创建任务尽可能简单，我不知道编写插件比使用 groovy、Java、gradle 插件的 gradle 更容易甚至更多。