在 Scala 项目中使用 sbt 与 maven 的优缺点

Pros and cons of using sbt vs maven in Scala project

提问by Konstantin Solomatov

Which build tool is the best for Scala? What are the pros and cons of each of them? How to I determine which one of them to use in a project?

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

采纳答案by mblinn

We're using Maven to build Scala projects at work because it integrates well with our CI server. We could just run a shell script to kick off a build, of course, but we've got a bunch of other information coming out of Maven that we want to go into CI. That's about the only reason I can think of to use Maven for a Scala project.

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

Otherwise, just use SBT. You get access to the same dependencies (really the best part about maven, IMHO). You also get the incremental compilation, which is huge. The ability to start up a shell inside of your project, which is also great.

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

ScalaMock only works with SBT, and you're probably going to want to use that rather than a Java mocking library. On top of that, it's mucheasier to extend SBT since you can write full scala code in the build file, so you don't have to go through all the rigamarole of writing a Mojo.

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

In short, just use SBT unless you really need tight integration into your CI server.

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

回答by 0__

The question is in danger of just generating lots of opinions; it would be better to have a clear list of requirements or a description of your environment, previous knowledge, etc.

这个问题有产生大量意见的危险；最好有一个明确的要求列表或对您的环境、先前知识等的描述。

FWIW, there are more opinions in this scala mailing list thread.

FWIW，在这个 Scala 邮件列表线程中有更多的意见。

My 2c are: Go with sbt if you don't have specific requirements

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

• for simple projects, it's totally effortless (you don't even need a build file until you have dependencies)
• it is commonly used across Scala open source projects. You can easily learn about configuration by peeking into other people's projects. Plus many projects assume you use sbt and provide you with ready-made copy+paste instructionfor adding them as a dependency to your project.
• if you use IntelliJ IDEA, it can be totally integrated. You can have IDEA use sbtto continuously compile your project, and vice versa you can use sbt to quickly generate IDEA projects. The last is extremely useful if you are in a 'snapshot' cycle with depending on other of your own libraries which are bumped from minor version to minor version -- just close the project, update the version in the build file, re-run the gen-ideatask, and re-open the project: updates done.
• comes ready with most tasks you will need (compile, test, run, doc, publish-local, console) -- the consoleis one of the best features.
• some people highlight the feature that dependencies can be source repositories directly grabbed from GitHub. I haven't used this so can't comment here.

• 对于简单的项目，它完全不费吹灰之力（在拥有依赖项之前，您甚至不需要构建文件）
• 它通常用于 Scala 开源项目。您可以通过查看其他人的项目轻松了解配置。此外，许多项目假设您使用 sbt 并为您提供现成的复制+粘贴指令，以便将它们作为依赖项添加到您的项目中。
• 如果您使用 IntelliJ IDEA，它可以完全集成。你可以让 IDEA 使用 sbt来持续编译你的项目，反之你可以使用 sbt 快速生成 IDEA 项目。如果您处于“快照”循环中，并且依赖于从次要版本到次要版本的其他库，则最后一个非常有用——只需关闭项目，更新构建文件中的版本，重新运行gen-idea任务，然后重新打开项目：更新完成。
• 准备好您需要的大多数任务（compile, test, run, doc, publish-local, console）——这console是最好的功能之一。
• 有些人强调依赖项可以是直接从 GitHub 抓取的源存储库的功能。我没有用过这个，所以不能在这里发表评论。

Some people hate sbt because it uses Ivy for dependency management (I can't comment on its pros and cons, but most of the time it is a non-issue), some people hate sbt because you specify the build file in terms of a Scala DSL instead of XML. Some people were disappointed that sbt's format changed from v0.7 to v0.10, but obviously, migration won't affect you if you start from scratch.

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