SBT - Scala build tool - Unterschiede zu anderen Systemen

SBT ist das Build-Tool (nicht nur) für Scala. Es wurde um das Konzept der “Tasks” herum entwickelt, allerdings kennt es im Gegensatz zu Maven keine “Phasen” oder “Goals”. Abhängigkeiten zwischen Tasks müssen explizit über Abhängigkeiten formuliert werden. Damit arbeitet sbt ähnlich wie Ant, berücksichtigt aber eine standardisierte Struktur und ein standardisiertes Verzeichnis Layout wie es Maven hat.

Werden Ergebnisse eines Tasks in einem anderen benötigt, so kann man den Input entsprechend übergeben. Die Ausgabe ist stets ein Wert eines beliebigen Typs, daran erkennt man dann auch ob ein Task ausgeführt wurde oder eben nicht.

Standardmäßig werden alle Tasks parallel ausgeführt, gibt es Abhängigkeiten unter den Tasks, so werden diese entsprechend berücksichtigt. Das gibt es in Ant und Maven nicht, dort werden alle Tasks/Goals entsprechend sequenziell abgearbeitet.

sbt setzt bei der Auflösung von Abhängigkeiten auf Apache Ivy, Maven nutzt hier Aether und Gradle hat hierfür sogar ein eigenes System.

Der ‘compile’ Task übersetzt Scala und Java Code und das Layout ist vergleichbar dem von Maven.

Ein Task in sbt ist Scala Code, es gibt kein XML und man kann den Code ähnlich wie in Gradle mit Groovy direkt in der Buildkonfiguration i n Scala schreiben, womit man hier gleich die geballte Power von Scala zur Verfügung hat.

Neben den oben genannten Eigenschaften des sbt Build Tools gibt es noch die folgenden Vorteile zu nennen:

• Es ist deutlich schneller da es inkrementell arbeitet und zudem einen interaktiven Modus bietet.
• Arbeitet man im interaktiven Modus, so wird die JVM nur einmal gestartet - Ant und Maven starten jedesmal eine neue JVM pro Aufruf.
• sbt bietet mit dem console Task eine sogenannte REPL (Run Evaluate Print Loop) an mit der interaktiv Scala Code getestet werden kann, hierbei wird der Classpath des Projektes automatisch gesetzt, so das alle im Classpath verfügbaren APIs auch in der REPL verfügbar sind.
• Stellt man einem Kommando die Tilde voran, so wird diese im Hintergrund nach Dateiänderungen schauen und automatisch aktiv werden.
• Tests können z.B. so ausgeführt werden, das nur die fehlgeschlagenen bzw. die Tests ausgeführt werden, welche auch von Codeänderungen betroffen sind. ~testQuick zum Beispiel führt Tests aus, die entweder fehlgeschlagen sind, noch nicht ausgeführt wurden oder deren transitive Abhängigkeiten sich geändert haben.
• Multiproject Builds sind ebenfalls möglich und werden wo es möglich ist ebenfalls parallel ausgeführt.

Ich werde nach und nach Beispiele bringen, welche die Arbeitsweise nochmal näher erklären.

Bis dahin sei auf die Dokumentation auf der SBT-Website verwiesen.