在Scala项目中使用sbt vs maven的优缺点

Question

哪种构建工具最适合Scala？每个人的利弊是什么？如何确定在项目中使用哪一个？

Answer 1

我们正在使用Maven来构建Scala项目,因为它与我们的CI服务器很好地集成.当然,我们可以运行一个shell脚本来启动构建,但是我们还有一些来自Maven的其他信息,我们想要进入CI.这是我能想到将Maven用于Scala项目的唯一原因.

否则,只需使用SBT.你可以访问相同的依赖项(真的是关于maven,恕我直言的最佳部分).您还可以获得增量编译,这是巨大的.能够在项目内部启动shell,这也很棒.

ScalaMock仅适用于SBT,您可能希望使用它而不是Java模拟库.最重要的是,扩展SBT 要容易得多,因为你可以在构建文件中编写完整的scala代码,因此你不必经历编写Mojo的所有麻烦.

简而言之,只需使用SBT,除非您确实需要紧密集成到CI服务器中.

Answer 2

这个问题有可能产生很多意见; 最好有清晰的要求清单或环境描述,以前的知识等.

FWIW,这个scala邮件列表主题中有更多的意见.

我的2c是:如果你没有具体要求,请选择sbt

• 对于简单的项目,它完全没有任何意义(除非你有依赖项,否则你甚至不需要构建文件)
• 它通常用于Scala开源项目.您可以通过窥视其他人的项目轻松了解配置.此外,许多项目都假设您使用sbt并为您提供现成的复制+粘贴指令,以将它们添加为项目的依赖项.
• 如果您使用IntelliJ IDEA,它可以完全集成.您可以让IDEA使用sbt来连续编译您的项目,反之亦然,您可以使用sbt快速生成IDEA项目.如果您处于"快照"循环中,并且依赖于您自己的其他库从次要版本到次要版本,那么最后一个非常有用 - 只需关闭项目,更新构建文件中的版本,重新运行gen-idea任务,并重新打开项目:完成更新.
• 谈到准备与你最需要的任务(compile,test,run,doc,publish-local,console) -该console是最好的功能之一.
• 有些人强调了依赖关系可以直接从GitHub获取的源存储库的功能.我没有用过这个,所以不能在这里发表评论.

有些人讨厌sbt,因为它使用Ivy进行依赖管理(我不能评论它的优点和缺点,但大多数时候它不是问题),有些人讨厌sbt因为你用a指定构建文件Scala DSL而不是XML.有些人对sbt的格式从v0.7更改为v0.10感到失望,但显然,如果从头开始,迁移不会影响你.