在 Scala 项目中使用 sbt vs maven 的优缺点 [关闭]

Posted 2023-02-26

【中文标题】在 Scala 项目中使用 sbt vs maven 的优缺点 [关闭]

【英文标题】：Pros and cons of using sbt vs maven in Scala project [closed]

【发布时间】：2012-07-01 22:34:00

【问题描述】：

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

【问题讨论】：

我为 Scala 项目从 Maven 过渡到 Gradle，因为它对多模块构建的出色支持。带有 SBT 的 Twitter experience 被他们描述为“令人眼花缭乱的痛苦”，他们正试图摆脱它（Maven 作为该过程中的权宜之计）。

另一个很酷的封闭问题...

我看到这么多好问题刚刚结束；我不知道是谁赋予这些人任意决定是否结束问题的权力。我什至不关心他们是否已经接近了。

同意。幸运的是，在这个问题结束之前我们有 2 个答案。对于那些投票结束这个问题的人来说很糟糕......

【参考方案1】：

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

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

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

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

【讨论】：

我不反对以上任何观点，只是想指出我正在编写ScalaMock 3，其主要目标之一是支持其他更轻松地构建系统。

为了完整起见，值得一提的是，只要您不需要使用生成的模拟（即只要你只需要模拟特征/接口）。

scala-maven-plugin provides the save incremental compilation as SBT

他们为什么不直接为 maven 编写增量编译？恕我直言，sbt 是未经治疗的 NIH 综合征的典型例子......

为什么 SBT 会导致 CI​​ 出现问题？

【参考方案2】：

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

FWIW，this scala mailing list thread有更多意见。

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

对于简单的项目，完全不费吹灰之力（您甚至不需要构建文件，直到您拥有依赖项） 它在 Scala 开源项目中普遍使用。您可以通过查看其他人的项目轻松了解配置。此外，许多项目假设您使用 sbt 并为您提供 ready-made copy+paste instruction 以将它们作为依赖项添加到您的项目中。 如果您使用 IntelliJ IDEA，它可以完全集成。你可以have IDEA use sbt不断编译你的项目，反之亦然你可以使用sbt快速generate IDEA projects。如果您处于“快照”周期中，最后一个非常有用，这取决于您自己的其他库，这些库从次要版本到次要版本 - 只需关闭项目，更新构建文件中的版本，重新运行gen-idea 任务，然后重新打开项目：更新完成。 准备好您需要的大多数任务（compile、test、run、doc、publish-local、console）——console 是最好的功能之一。 有些人强调了依赖可以是直接从GitHub抓取的源代码库的特性。我没用过，所以不能在这里评论。

有些人讨厌 sbt，因为它使用 Ivy 进行依赖管理（我无法评论它的优缺点，但大多数时候这不是问题），有些人讨厌 sbt，因为您在Scala DSL 而不是 XML 的术语。有些人对 sbt 的格式从 v0.7 更改为 v0.10 感到失望，但显然，如果您从头开始，迁移不会影响您。

【讨论】：

我讨厌 sbt，因为它滥用符号运算符和一些愚蠢的决定，例如同时支持 .sbt 和 .scala 定义格式但将它们放在不同的位置，并且 .sbt 中的语句必须用 at 分隔最少空行等。 sbt 的文档正在改进，但目前还不够好。我最想念的是一些完整的（最小到现实世界的复杂）.sbt/.scala 示例文件逐行解释，涵盖所有 sbt 功能。也就是说，我每天都使用 sbt，因为 Maven 更糟糕。

太糟糕了，这个问题被关闭了，我相信也存在事实差异：例如曼宁关于 SBT 的书的摘录：“如果 Maven 目标之间存在依赖关系（假设一个目标产生一个文件被另一个使用）然后你不能用 Maven 并行化你的构建。使用 sbt，你必须指定任务之间的显式依赖关系。这使 sbt 可以默认并行运行任务。如果任务 A 依赖于 B，而 C 也依赖于 B，然后 sbt 运行任务 B，然后并行运行 A 和 C。”希望此评论对一些读者有所帮助。

我发现这个线程非常有用。我经常认为 *** 版主过于急切地关闭线程。当他们经常正是用户正在寻找的东西（并通过网络搜索找到）时，谁在乎他们是否“离题”。就好像 *** 模组试图故意重新创建 xkcd 979。

@Ville 我的想法也是。投票、编辑和关闭已变得过于激进。

对于现在看到这个的任何人，@xiefei 的投诉已经得到解决。 SBT 删除了很多更自定义的运算符/语法，/sbt 文件中的语句不再需要空格分隔。