在 Scala 项目中使用 sbt 与 maven 的利与弊

我们在工作中使用 Maven 来构建 Scala 项目，因为它与我们的 CI 服务器集成得很好。当然，我们可以运行一个 shell 脚本来开始构建，但是我们从 Maven 中得到了许多其他信息，我们想要进入 CI。这是我能想到的将 Maven 用于 Scala 项目的唯一原因。

否则，就用 SBT。您可以访问相同的依赖关系(真正关于 maven 最好的部分，恕我直言)。您还可以获得增量编译，这非常庞大。能够在项目内部启动 shell，这也很棒。

ScalaMock 只能与 SBT 一起工作，您可能希望使用 SBT 而不是 Java 模拟库。除此之外，很多更容易扩展 SBT，因为您可以在构建文件中编写完整的 scala 代码，所以您不必经历编写 Mojo 的所有繁琐工作。

简而言之，只使用 SBT，除非您确实需要与 CI 服务器紧密集成。

这个问题可能会产生很多意见; 最好是有一个清晰的需求列表或者对您的环境、以前的知识等的描述。

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，因为你用 Scala DSL 而不是 XML 来指定构建文件。Sbt 的格式从 v0.7改为 v0.10，有些人对此感到失望，但是显然，如果从头开始，迁移不会影响您。