Idiomatische Art, Multiprojekt-Builds mit .SBT-Dateien in sbt 0.13 zu schreiben

Question

Ich höre .SBT-Dateien wurden in 0.13 auf verschiedene Arten verbessert, und das kann ich nun Multi-Projekt-Builds in ihnen angeben.

http://www.scala-sbt.org/0.13.0/docs/Community/ChangeSummary_0.13.0.html#sbt-format-enhancements erwähnt, dass wir nun Teilprojekte in einer .SBT-Datei definieren können. Ich weiß auch, dass mehrere .SBT-Dateien im Stamm in einer einzigen konzeptionellen Datei aggregiert werden.

Was ich wirklich möchte, ist, meine Wurzel nicht mit einem Dutzend Unterprojekt-.sbt-Dateien zu verschmutzen. Gibt es eine Möglichkeit, das Unterprojekt build.sbt-Dateien in ihre jeweiligen Unterverzeichnisse zu werfen, irgendwo zwischen ihnen einen gemeinsamen Code zu behalten und dann ein root build.sbt für das gesamte Projekt zu haben, das die Unterprojekte aggregiert? Ich habe ein ähnliches Setup in .scala-Dateien jetzt, würde aber lieber .sbt-Dateien verwenden, wenn möglich.

Wenn das nicht möglich ist, was ist der "richtige" Weg, große Multi-Projekt-Builds mit .SBT-Dateien zu erstellen?

Answer 1

Es sollte bereits in 0.12 der Fall sein, dass Sie .sbt Dateien in das Basisverzeichnis eines Unterprojekts setzen können und die Einstellungen dort in den Anwendungsbereich dieses Projekts aufgenommen werden.

Der Code wird zwischen .sbt Dateien wiederverwendet, indem eine normale .scala Datei in project/ erstellt wird. Der Code in project/ wird für die Verwendung in den .sbt Dateien verfügbar sein. Die Definitionen in einem .sbt sind für andere .sbt Dateien zumindest in 0.13 nicht sichtbar. Dies ist hauptsächlich eine Implementierungsbeschränkung, und es ist unbestimmt, ob dies in zukünftigen Versionen aufgehoben wird.

Das Standard-Root-Projekt aggregiert alle Teilprojekte, einschließlich derer, die aus Projekten kommen, die in subProject/build.sbt definiert sind.

Die aktuelle Schwierigkeit macht es explizit. Zum Beispiel würde das folgende build.sbt im Stammverzeichnis ein Unterprojekt in sub/ definieren. Dies ist eine vollständige Definition, die die ID, das Basisverzeichnis usw. für das Projekt definiert.

<root>/build.sbt

lazy val sub = project 

Er kann aber nichts in <sub>/build.sbt definiert verweisen. (Die Existenz von sub/build.sbt wird, bis nicht bekannt nach <root>/build.sbt zusammengestellt und ausgewertet wird.) also explizit zu definieren, was sub Aggregate, müssen Sie so etwas wie:

sub/build.sbt

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

lazy val subSub = project 

jedoch diese Duplikate die Definition von sub.

Eine mögliche Lösung geht nach vorn ist die Wurzel Definition nur einen Verweis zu machen, wie:

<root>/build.sbt

lazy val sub = LocalProject("sub")