在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，this scala mailing list thread中有更多意见。

我的2c是：如果您没有特定要求，请与sbt一起使用

• 对于简单的项目，它完全没有用（在你有依赖项之前你甚至不需要构建文件）
• 它通常用于Scala开源项目。您可以通过窥视其他人的项目轻松了解配置。此外，许多项目都假设您使用sbt并为您提供ready-made copy+paste instruction，以便将它们作为项目的依赖项添加。
• 如果您使用IntelliJ IDEA，它可以完全集成。您可以have IDEA use sbt继续编译项目，反之亦然，您可以快速使用sbt generate IDEA projects。如果您处于“快照”循环中，并且依赖于您自己的其他库从次要版本到次要版本，那么最后一个非常有用 - 只需关闭项目，更新构建文件中的版本，重新运行gen-idea任务，并重新打开项目：已完成更新。
• 准备好了您需要的大多数任务（compile，test，run，doc，publish-local，console） - console是最好的功能之一。
• 有些人强调依赖关系可以直接从GitHub获取的源存储库的功能。我没有用过这个，所以不能在这里发表评论。

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