首页 文章

比较sbt和Gradle [关闭]

提问于
浏览
105

我潜入斯卡拉并注意到了sbt . 我对Java / groovy项目中的Gradle非常满意,我知道Gradle有一个scala插件 .

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

5 回答

  • 52

    请注意,SBT和Gradle之间的一个关键区别是 dependency management

    • SBTIvy,带有可作为固定版本(例如1.5.2)或最新版本(或动态版本)的修订版本 .
      见“Ivy Dependency
      这意味着"-SNAPSHOT"机制支持可能会有问题,即使this thread中的Mark Harrah详细信息:

    确实缓存可能会混淆,但Ivy不理解解析快照并不是真的 . Eugene在另一个帖子中解释了这一点,也许在管理员列表中 . sbt的自动更新存在问题,已在0.12中解决 . 据我所知,Ivy不支持以Maven的方式发布快照 . 我相信我已在其他地方说过这一点,但如果有人想要改善这种情况,我的意见是最好花费在Gradle团队上重用他们的依赖管理代码 .

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

    This tweet提到所有情况都可能在未来发展:

    Mark过去曾表示他有兴趣使用Gradle代替Ivy进行SBT .

    (这两个工具都可以learn from each other

  • -11

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

    • 快速编译(比 fsc 快) .

    • 连续编译/测试:命令 ~test 将在每次保存修改时重新编译并测试项目 .

    • 跨几个scala版本的交叉编译和交叉发布 .

    • 使用正确的scala版本兼容性自动检索依赖项 .

    缺点是:

    • 一种象形文字语法,往往会阻止新用户(特别是如果他们来自Java)

    • 没有简单的方法来定义"task":如果你需要一个特殊的构建过程,你需要找到一个插件,或者自己编写一个插件 .

  • 39

    sbt是一个Scala DSL,因为Scala是一流的公民,所以原则上它似乎是一个很好的选择 .

    但是sbt遭受了版本之间的主要不兼容的更改,这使得很难为任务找到正确的工作插件并使其工作 .

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

    去搞清楚 .

  • 59

    我是一个相当新的人,对于sbt来说是非常新的 - 到目前为止,我真正喜欢的是交互式控制台 . 它允许我使用'inspect'之类的命令来更好地了解正在发生的事情 . AFAIK gradle不提供像这样的atm .

  • 4

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

    • 更好的插件支持,特别是autoplugins

    • 任务创建和任务之间的依赖关系管理

    • sbt特别适合scala项目,因为它支持增量构建,大多数sbt本身都是用scala编写的,而sbt构建定义是用scala编写的

    • sbt具有许多有用的内置任务的interative shell支持

    • sbt默认生命周期非常有用,可以通过相当少的努力开始新手

相关问题