Das Open-Source-Build-Tool sbt 1.3.0 erschien am 9. September 2019 und bringt einen grundlegenden Wechsel beim Dependency-Management mit: Statt Apache Ivy kommt nun Coursier als Standard-Resolver zum Einsatz. Coursier wurde in Scala neu geschrieben und soll vor allem durch höhere Geschwindigkeit beim Auflösen von Bibliotheksabhängigkeiten punkten. sbt ist das Standardwerkzeug für Scala-Entwicklung und wird darüber hinaus von zahlreichen Java-Projekten genutzt; es lässt sich am ehesten mit Maven oder Ant in der Java-Welt vergleichen.
Coursier ersetzt Apache Ivy
Bisherige sbt-Versionen setzten beim Library Management primär auf Apache Ivy als Dependency Resolver. In bestimmten Situationen löst Coursier Abhängigkeiten nicht identisch zu Ivy auf, etwa wenn Remote-Snapshots standardmäßig 24 Stunden im Cache verbleiben. Wer das alte Ivy-Verhalten benötigt, kann in der build.sbt zurückkehren:
ThisBuild / useCoursier := falseCoursier selbst geht auf eine längere Entwicklungsgeschichte zurück: Leonard Ehrenfried begann Anfang 2018 mit der Coursier-gestützten LM-API-Implementierung, Andrea Peruffo erweiterte sie im Herbst desselben Jahres, und schließlich arbeitete Eugene Yokota die nötigen Änderungen ein, um die LM-Engine in sbt auszutauschen. Der Resolver-Wechsel ist damit das Ergebnis koordinierter Community-Arbeit über mehrere Monate.
ClassLoader-Layering und Super Shell
Eine zweite wesentliche Neuerung ist die erweiterte classLoaderLayeringStrategy. sbt hat bisher zweischichtige ClassLoader beim Ausführen der Run- und Test-Tasks erstellt. Die oberste Schicht bewahrte die Scala-Library-JARs, damit Klassen aus dem Scala-Paket über mehrere Auswertungen hinweg wiederverwendet werden können. sbt 1.3.0 führt nun experimentell ClassLoaderLayeringStrategy.AllLibraryJars ein: ein dreischichtiger ClassLoader, der zusätzlich Bibliotheksabhängigkeiten vorhält. Das soll die Startlatenz von Run- und Test-Tasks innerhalb einer Session deutlich senken und den GC-Druck durch das wiederholte Laden von Library-JARs reduzieren. Ethan Atkins, der maßgeblich an diesen IO-Verbesserungen beteiligt war, zeigt in seinen Performance-Tests, dass der sbt-1.3.0-Edit-Compile-Test-Zyklus selbst für 5.000 Quelldateien schneller läuft als vergleichbare Szenarien mit sbt 0.13, Gradle oder anderen Build-Tools mit nur drei Dateien.
Neu ist außerdem die Super Shell: In einem ANSI-kompatiblen Terminal zeigt sbt parallel verarbeitete Tasks und die Aufgabenverteilung innerhalb des Builds in Echtzeit an. Zusätzlich erkennt sbt 1.3.0 automatisch Änderungen an Build-Definition-Quelldateien und gibt eine Warnung aus, wenn ein Task ohne vorheriges Reload gestartet wird. Lightbend, die Firma hinter der Programmiersprache Scala, gehört zu den prominentesten Unterstützern des Projekts. An sbt 1.3.0 und dem zugehörigen Zinc-Compiler-Plugin beteiligten sich 45 Contributors; die vollständigen Release Notes sind auf der offiziellen sbt-Dokumentationsseite verfügbar.
Ähnlich wie JVM-Streaming-Frameworks, etwa Apache Flink, entwickelt sich auch das sbt-Ökosystem kontinuierlich weiter. Für Spieleentwickler und Studios, die auf JVM-basierte Toolchains setzen, senkt sbt 1.3 die Build-Zeiten spürbar.