让我们说我有一些与子项目有关的构建，但这些子项目与构建通常知道的各种事物之间有一些逻辑分类。
例如，我可能有一个子项目集合
我知道Woof和Bar是我称之为服务器组件的一部分。 Baz是两者的共同依赖，而Foo，Quux和Oink在客户端。整个构建是各个子项目的集合，但有时我只是喜欢＆＃34;焦点＆＃34;在服务器端，或客户端，或其他什么。
一方面，我考虑过嵌套的聚合项目，但我不确定它与sbt的其他功能有多好。
另一方面，我正在考虑制作跨越子项目的自定义范围。我希望能够使用类似的密钥配置相关项目，因此能够说我想更新相关项目组的某个密钥是很方便的。
对于这类事情来说，什么是好方法？我在想错了吗？
答案 0 :(得分：0)
处理类似的情况。
我的解决方案是在sbt中将所有内容分解为子项目，并使用dependsOn链接子项目。这里非常出乎意料的结果是，依赖于dependsOn的子项目完全模仿Maven依赖。如果您发布其中一个，它将神奇地拥有其他的maven依赖项。像eclipse和intelli这样的工具通常也会很容易地看到这些依赖链。
这使您可以选择是否将事物保存在同一个SBT项目中，最终几乎没有差别。他们只是以“maven-style”的方式联系在一起。依赖。在这里使用本地maven仓库或远程仓库非常有效。此时，您可以根据代码管理而不是部署管理自由选择是否将内容分解为不同的SBT项目。
编辑：所以最后，如果你想将模块从多项目SBT中移出，你只需要将常规的maven deps添加到请求其他代码库的任何代码库中
答案 1 :(得分：-1)
我的意见：跳过子项目。当您将项目作为独立项目发布时，拆分项目很不错。但是多个项目也会遇到麻烦：在多个项目之间很难获得良好稳定的接口。
我会尽可能晚地将项目分成多个项目。只有一个大项目，依赖管理（尤其是循环依赖），重构（尤其是类的移动）和工具支持（特别是IDE集成）要好得多。
当覆盖范围跨越多个项目时，测量代码覆盖率等问题也会变得非常困难。
自定义范围和六个子项目：在我看来，这完全是过度设计的。继续使用一个项目，让整个项目运行并在以后拆分（如有必要）。