Build-Werkzeug: Gradle 7 zielt auf Apple Silicon und Java 16

Das Tool zum Automatisieren von Build-Prozessen Gradle ist in Version 7.0 erschienen. Das Release bietet eine native Anbindung an Apple Silicon und läuft stabil auf und für Java 16. Außerdem behält das Werkzeug nun standardmäßig die Informationen über die Ein- und Ausgabedateien bei inkrementellen Builds im Arbeitsspeicher, und Dependencies lassen sich zentral verwalten.

Für die DSL (Domain Specific Language) setzt Gradle nun auf das vor einem Jahr veröffentlichte Groovy 3. Grundsätzlich ist es aber weiterhin mit Groovy ab Version 1.5.8 kompatibel. Für die Java-Anbindung gilt JDK 8 als Mindestvoraussetzung und Version 16 als oberes Ende. Auf das für Herbst geplante Java 17 ist Gradle noch nicht ausgelegt. Im Zusammenspiel mit Kotlin ist Gradle auf die Versionen 1.3.72 bis 1.4.31 getestet.

Feinschliff für Apple und Java

Gradle konnte zwar in Version 6.x bereits Anwendungen für Apple Silicon erstellen, allerdings fehlten im Zusammenspiel mit dem nativen ARM JDK (Java Development Kit) einige Features, darunter das nun zum Standardvorgehen erhobene File System Watching. Wer die Anwendungen auf dem Intel JDK erstellt hat, konnte zwar alle Funktionen nutzen, musste dafür aber Performanceeinbußen aufgrund der Rosetta-2-Kompatibilitätsschicht hinnehmen. Das aktuelle Release bietet alle Funktionen für das ARM JDK, sodass der Build auf Macs mit Apple Silicon ohne Einschränkungen funktioniert.

Offensichtlich führte das Ausführen von Gradle 6.x auf Systemen mit Java 16 zu Fehlern. Das Erstellen von JVM-Projekten für Java 16 war zwar möglich, erforderte aber das Deaktivieren inkrementellen Builds. Mit Gradle 7 soll sowohl der Build für als auch auf Java 16 uneingeschränkt erfolgen.

Dateien unter Beobachtung

Das sogenannte File System Watching hielt als experimentelle Funktion in Gradle 6.5 Einzug und gilt seit Version 6.7 als stabil. Mit der neuen Hauptversion ist es standardmäßig aktiviert. Das Vorgehen soll inkrementelle Builds beschleunigen, indem es den Status der Ein- und Ausgabedateien im Speicher ablegt. Dadurch entfällt der I/O-Overhead, um festzustellen, welche Dateien bei einem inkrementellen Build zu aktualisieren sind.

Bisher als experimentell gekennzeichnet sind die sogenannten Version Catalogs zum einheitlichen Verwalten von Dependencies zwischen Projekten in Mulit-Projekt-Builds. Die Kataloge sollen die verschiedenen Ansätze zum Deklarieren von Abhängigkeiten in Build-Skripten, externen Dateien wie dependencies.gradle, innerhalb von buildSrc oder über spezielle Plug-ins vereinheitlichen.

Die Kataloge enthalten alle relevanten Informationen über externe Dependencies in einer zentralen Konfigurationsdatei, wie folgender Ausschnitt aus den Release Notes zu Gradle 7 zeigt:

[versions]
groovy = "3.0.5"

[libraries]
groovy-core = { module = "org.codehaus.groovy:groovy",
                version.ref = "groovy" }
groovy-json = { module = "org.codehaus.groovy:groovy-json",
                version.ref = "groovy" }
groovy-nio = { module = "org.codehaus.groovy:groovy-nio",
               version.ref = "groovy" }
commons-lang3 = { group = "org.apache.commons",
                  name = "commons-lang3",
              version = { strictly = "[3.8,4.0[", prefer="3.9" } }

[bundles]
groovy = ["groovy-core", "groovy-json", "groovy-nio"]

Anschließend lassen sich Dependencies über die definierten Libraries und Bundles in die tatsächlichen Build-Skripte integrieren:

dependencies {
  implementation libs.bundles.groovy
  implementation libs.commons.lang3
}

Die Methode soll zum einen das Definieren von Abhängigkeiten vereinfachen und zentralisieren und zum anderen Tippfehlern vorbeugen, die zu falschen oder fehlenden Dependency-Deklarationen führen können. Für diejenigen, die Plug-ins erstellen, steht mit Settings eine API für die Deklaration der Versionskataloge bereit.

Weitere Neuerungen in Gradle 7 lassen sich den Release Notes entnehmen. Die Installation ist über die Gradle-Site möglich, und der Sourcecode findet sich auf GitHub. (rme)