比较sbt和Gradle

我正在潜入Scala并注意到了sbt。 我在java / groovy项目中对Gradle很满意，我知道Gradle有一个scala插件。

在Scala项目中赞成Gradle的原因是什么？

Answer 1

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

• SBT ： 常春藤 ，可以修改为固定版本（例如1.5.2）或最新版本（或dynamic版本）。
  见“ 常春藤依赖 ”
  这意味着“SNAPSHOT”机制支持可能会有问题，即使Mark Harrah在此主题中提供了详细信息：

caching可能会混淆，但常春藤不理解快照是不正确的。 Eugene在另一个线索（也许在pipe理员名单上）解释了这一点。 sbt的自动更新存在一个问题，在0.12中解决。

据我所知，常春藤不支持以Maven的方式发布快照。 我相信我已经在其他地方说过了，但是如果有人想改善这种情况，我认为最好花费在与Gradle团队合作来重用他们的依赖pipe理代码。

• Gradle ： 这个post提到（ Peter Niederwieser ）：

只是为了让你知道，常春藤和Maven快照依赖的问题是Gradle最终用自己的依赖pipe理代码取代常春藤的原因之一。 这是一个很大的任务，但给我们带来了很多好处。

这篇推文提到所有情况都可能在未来发展：

马克在过去说过，他有兴趣使用Gradle而不是常青藤做SBT。

（这两种工具都可以相互学习 ）

Answer 2

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

• 快速编译（比fsc快）
• 连续编译/testing：命令~test将重新编译并testing您每次保存修改项目。
• 交叉编译和交叉发布，跨越几个scala版本。
• 使用正确的scala版本兼容性自动检索依赖关系。

缺点是：

• 倾向于阻止新用户的象形文字语法（特别是如果他们来自Java）
• 没有简单的方法来定义一个“任务”：如果你需要一个特殊的构build过程，你将需要find一个插件，或者自己写一个插件。

Answer 3

sbt是一个Scala DSL，对于它来说Scala是一stream的公民，所以原则上它似乎是一个很好的select。

但是，sbt遭受了版本之间主要的不兼容的变化，这使得很难find正确的工作插件的任务，并得到它的工作。

我个人放弃了，因为它造成了更多的问题，而不是解决问题。 我其实切换到了gradle。

去搞清楚。

Answer 4

我对gradle相当陌生，对于sbt非常新颖 – 到目前为止，我真正喜欢sbt的是交互式控制台。 它允许我使用“检查”等命令来更好地了解发生了什么事情。 AFAIK gradle不提供这样的atm。

Answer 5

Sbt和Gradle，都是基于静态types的语言……但是却没有什么优势：

• 更好的插件支持，特别是autoplugins
• 任务创build和任务之间的依赖关系pipe理
• sbt特别适合scala项目，它支持增量构build，大部分sbt本身是用scala编写的，而sbt构build定义是用scala编写的
• sbt与许多有用的内置任务有内在的shell支持
• sbt的默认生命周期是相当有用的，可以让新手开始与相当less的努力