在Scala项目中使用sbt vs maven的利弊[关闭]

哪种构建工具最适合Scala？它们各自的优缺点是什么？如何确定在项目中使用哪一个？

我们正在使用Maven在工作中构建Scala项目，因为它与我们的CI服务器很好地集成在一起。当然，我们可以运行一个shell脚本来启动构建，但是我们从Maven中获得了很多其他信息，我们希望将它们纳入CI中。这是我想到可以将Maven用于Scala项目的唯一原因。

否则，只需使用SBT。您可以访问相同的依赖项（真正是有关Maven的最佳部分，恕我直言）。您还将获得增量编译，这是巨大的。在项目内部启动Shell的能力也很棒。

ScalaMock仅适用于SBT，您可能要使用它而不是Java模拟库。最重要的是，扩展SBT 更加容易，因为您可以在构建文件中编写完整的Scala代码，因此您不必经历编写Mojo的所有繁琐工作。

简而言之，除非确实需要紧密集成到CI服务器中，否则请使用SBT。

这个问题有可能引起很多意见。最好有明确的需求列表或环境描述，以前的知识等。

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感到失望，但是很明显，如果您从头开始，迁移不会影响您。