终极子项目sbt设置

Question

我正在处理一些代码，这些代码包含多个子项目，其中许多子项目彼此依赖。例如，有一个utils项目，包含各种实用程序，一个queueing项目，其中包含一些用于管理事物队列的代码，然后是mainApp项目。 queueing项目取决于utils，mainApp取决于utils和queueing。此外还有更多的项目，但希望你能得到一般的想法。

我们使用一个标准的sbt子模块设置，包含一个根构建文件，许多子项目以及标准的aggregate和dependsOn内容。这有效，但有问题：

• 构建和运行项目测试可能会非常缓慢。建立每一个大约需要15分钟，单元测试一切都需要更长的时间。
• 由于聚合的工作方式，单元测试mainApp导致utils和queuing中的所有测试都运行，即使它们没有发生变化。没错，你可以快速测试＆＃34;但是当你改变git分支时它会停止工作，所以你仍然经常运行整个测试套件。
• 虽然sbt确实允许你只构建一个子项目，但你必须在根目录中并记住要对构建进行限定。例如，您必须记住运行sbt utils/compile而不是sbt compile。

所以我们切换到完全独立的项目和单独的git repos。每个项目都会构建，然后将工件部署到Nexus。因此，要构建和测试mainApp，您只需构建它，它就会从nexus服务器中为其他项目提取已编译的.jar文件。这使得在一个项目中工作变得更容易，但是对例如utils进行更改变得更加困难，然后在mainApp中使用它。具体来说，您经常需要做一些事情，例如向utils添加方法，然后立即在mainApp中测试该方法，以便在推送新版utils之前查看它是否有效。但是现在，要做到这一点，你必须：

• 将您的代码添加到utils
• 将版本号压缩为utils
• 运行＆＃34; sbt publish-loca＆＃34;
• 在mainApp中修改build.sbt并将-SNAPSHOT添加到utils依赖关系
• 运行sbt update
• 构建并测试mainApp

如果一切正常，那么您必须按正确的顺序将utils和mainApp推送到持续构建服务器，并确保在您之前等待utils构建完成推mainApp。

更糟糕的是，维护版本控制变得非常复杂。假设我们从版本1.0的所有项目开始，并取决于其他项目的1.0版本。现在假设我们在utils中发现了一个影响mainApp的错误。因此我们修复utils，将其版本号更改为1.1，更新mainApp以依赖于1.1并重新构建。假设修复mainApp中的错误的代码在queue中引入了一个错误。问题是，如果你去queue并运行它的测试，它们将对utils的版本1.0运行（即使你使用范围作为sbt只是定期重新检查它们）。但是，当您构建mainApp时，utils上将存在依赖冲突，sbt将解析该冲突。无论它如何解决它，它都将是错误的＆＃34;至少一个项目。我们可以将解析器设置为＆＃34; strict＆＃34;但是，在10多个项目中，管理版本变得非常耗费人力。

我真正想要的是一个两全其美的构建设置。具体做法是：

• 每个项目都有一个带有子目录的根目录
• 如果pwd是其中一个子目录，则所有sbt命令仅指该项目。因此，如果pwd为queue，则sbt test仅编译并测试 queue。
• 如果在Nexus中有一个工件的版本，则会从那里提取，但如果磁盘上有更新的代码，那么依赖项将在本地构建，而是用于代替。

或类似的东西。有没有人对如何用sbt进行设置提出任何建议？