在Scala项目中使用sbt vs maven的优缺点
哪个构build工具对Scala来说是最好的？ 他们每个人的优点和缺点是什么？ 如何确定在项目中使用哪一个？
我们使用Maven在工作中构buildScala项目，因为它与我们的CI服务器很好地集成在一起。 当然，我们可以运行一个shell脚本来启动一个构build，但是我们还有很多来自Maven的信息，我们希望进入CI。 这就是我能想到在Scala项目中使用Maven的唯一原因。
否则，只需使用SBT。 你可以访问相同的依赖关系（真正的最好的部分关于maven，恕我直言）。 你也得到了增量编译，这是巨大的。 能够在你的项目中启动一个shell，这也很棒。
ScalaMock只适用于SBT，你可能会想要使用它，而不是Java模拟库。 最重要的是，扩展SBT 要容易得多 ，因为你可以在构build文件中编写完整的scala代码，所以你不必经历编写Mojo的所有困难。
总之，只要使用SBT，除非您真的需要紧密集成到您的CI服务器。
这个问题正在产生很多意见的危险。 最好有清晰的要求清单或对环境的描述，以前的知识等等。
FWIW，在这个scala邮件列表中有更多的意见。
我的2c是：如果你没有特定的要求，请与sbt一起去
- 对于简单的项目，这是完全毫不费力（你甚至不需要一个构build文件，直到你有依赖）
- 它通常在Scala开源项目中使用。 通过窥视他人的项目，您可以轻松了解configuration。 此外，许多项目假设您使用sbt并为您提供现成的复制+粘贴指令 ，将它们作为依赖项添加到项目中。
- 如果你使用IntelliJ IDEA，它可以完全集成。 您可以让IDEA使用sbt来持续编译您的项目，反之亦然，您可以使用sbt来快速生成IDEA项目 。 最后一个是非常有用的，如果你在一个'快照'周期取决于你自己的其他库从小版本到次要版本的碰撞 – 只需closures项目，更新构build文件中的版本，重新运行
gen-idea任务，然后重新打开项目：完成更新。 - 随时准备好您需要的大部分任务（
compile，test，run，doc，publish-local，console） –console是最好的function之一。 - 有些人强调了依赖可以直接从GitHub获取的源代码库的function。 我没有用过，所以不能在这里评论。
有些人讨厌sbt，因为它使用Ivy来进行依赖pipe理（我不能评论它的优点和缺点，但大多数情况下这不是问题），有些人讨厌sbt，因为你指定了构build文件Scala DSL而不是XML。 有些人对sbt的格式从v0.7改为v0.10感到失望，但显然如果从头开始，迁移不会影响到你。
