146

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

4

2 回答 2

91

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

否则，只需使用 SBT。您可以访问相同的依赖项（真的是关于 maven 的最好的部分，恕我直言）。您还将获得巨大的增量编译。能够在项目中启动 shell，这也很棒。

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

简而言之，除非您真的需要紧密集成到 CI 服务器中，否则只需使用 SBT。

于 2012-07-01T03:08:42.747 回答
21

这个问题有产生大量意见的危险；最好有一份清晰的需求清单或对您的环境、以前的知识等的描述。

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

于 2012-07-01T12:25:06.190 回答