比较 sbt 和 Gradle

我一头扎进了 Scala,注意到了 sbt。在 java/groovy 项目中,我非常喜欢 Gradle,我知道它有一个 scala 插件。

在 Scala 项目中,有什么好的理由支持 sbt 而不是 Gradle?

44826 次浏览

Sbt 是一个 Scala DSL,对它来说,Scala 是一个一等公民,所以从原则上来说,它似乎是一个不错的选择。

但 sbt 的版本之间存在很大的不兼容性变化,这使得它很难找到一个任务的正确工作插件并使其工作。

我个人放弃了 sbt,因为它带来的问题比解决的问题还多。

想想看。

对我来说,SBT 的主要特点是:

  • 快速编译(比 fsc快)。
  • 持续编译/测试: 每次保存修改时,命令 ~test都会重新编译并测试您的项目。
  • 跨多个 Scala 版本的交叉编译和交叉发布。
  • 自动检索具有正确的 Scala 版本兼容性的依赖项。

缺点是:

  • A hieroglyphic syntax that tends to discourage new users (especially if they come from Java)
  • 定义“任务”并不容易: 如果你需要一个特殊的构建过程,你需要找到一个插件,或者自己编写一个插件。

请注意,SBT 与 Gradle 的一个关键区别在于它的资本充足率:

  • SBT : 艾薇,带有一个可以作为固定版本(例如1.5.2)或最新版本(或动态版本)给出的修订版本。
    看“ 常春藤依赖症
    这意味着“-SNAPSHOT”机制支持可能存在问题,即使 这根线中的 Mark Harrah细节如下:

It is true the cache can get confused, but it is not true that Ivy doesn't understand resolving snapshots. Eugene explained this point in another thread, perhaps on the admin list. There is an issue with sbt's auto-update that was addressed in 0.12.

据我所知,Ivy 并不支持以 Maven 的方式发布快照。我相信我在其他地方已经说过了,但是如果有人想要改进这种情况,我的观点是,最好是与 Gradle 团队一起工作来重用他们的依赖管理代码。

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

这条推文提到所有的情况都可能在未来发生变化:

马克过去曾说过,他有兴趣在 SBT 考试中使用格拉德尔而不是常春藤。

(both tools can 互相学习)

我是相当新的分级,非常新的 sbt-什么我真的喜欢 sbt 到目前为止是交互式控制台。它允许我使用诸如“检查”之类的命令来更好地了解正在发生的事情。AFAIK 级别不提供这样的自动取款机的东西。

Sbt 和 gradle 都基于静态类型语言... ... 但 Sbt 没有什么优势:

  • 更好的插件支持,特别是自动插件
  • 任务创建和任务之间的依赖关系管理
  • Sbt 特别适合 scala 项目,因为它支持增量构建,并且 sbt 本身大部分是用 scala 编写的,sbt 构建定义也是用 scala 编写的
  • Sbt 对许多有用的内置任务提供交互式 shell 支持
  • Sbt 缺省生命周期非常有用,可以让初学者轻松入门