Идиоматический способ написания многопроектных сборников с .sbt файлами в sbt 0.13

Я слышал, что файлы .sbt были улучшены различными способами в 0.13, и теперь я могу указать в них многопроектные сборки.

http://www.scala-sbt.org/0.13.0/docs/Community/ChangeSummary_0.13.0.html#sbt-format-enhancements упоминает, что теперь мы можем определить подпроекты в файле .sbt. Я также знаю, что несколько файлов .sbt в корне будут объединены в один концептуальный файл.

Мне бы очень хотелось, чтобы не загрязнять мой корень дюжинами подпроектов .sbt файлов. Есть ли способ, который я могу передать файлы subproject build.sbt в их соответствующие подкаталоги, сохранить некоторый общий код между ними где-то совместно, а затем создать root build.sbt для всего проекта, который объединяет подпроекты? У меня аналогичная настройка в файлах .scala прямо сейчас, но, по возможности, предпочитаю использовать файлы .sbt.

Если это невозможно, каков "правильный" способ построения больших многопроектных сборников с файлами .sbt?

Ответы

Ответ 1

В 0.12 уже должно быть, что вы можете поместить файлы .sbt в базовый каталог подпроекта, а настройки там будут включены в эту область проекта.

Код повторно используется между .sbt файлами, создавая обычный .scala файл в project/. Код в project/ будет доступен для использования в файлах .sbt. Определения в одном .sbt не отображаются в других файлах .sbt, по крайней мере, в 0,13. Это в основном ограничение реализации, и не определено, будет ли оно отменено в будущих версиях.

Корневой проект по умолчанию будет агрегировать все подпроекты, включая те, которые идут из проектов, определенных в subProject/build.sbt.

Текущая трудность делает ее явной. Например, следующий build.sbt в корневом каталоге определит подпроект в sub/. Это полное определение, определяющее ID, базовый каталог и т.д. Для проекта.

<root>/build.sbt

lazy val sub = project

Однако он не может ссылаться на что-либо, определенное в <sub>/build.sbt. (Существование sub/build.sbt неизвестно до тех пор, пока <root>/build.sbt не будет скомпилирован и не оценен.) Итак, чтобы явно определить, какие агрегаты sub, вам понадобится что-то вроде:

sub/build.sbt

lazy val sub = project.in(file(".")).aggregates(subSub)
//or: lazy val sub = project in file(".") aggregate subSub

lazy val subSub = project

Однако это дублирует определение sub.

Возможное решение в будущем - сделать определение корня просто ссылкой, например:

<root>/build.sbt

lazy val sub = LocalProject("sub")