Java Gradle Einführung

Gradle ist ein Build-Automatisierungswerkzeug für die JVM (und darüber hinaus), das Ihren Code kompiliert, Tests ausführt, Abhängigkeiten verwaltet und das Ergebnis verpackt — alles gesteuert durch ein Build-Skript, das Sie in Groovy oder Kotlin schreiben. Wo Maven ein Projekt mit festem XML beschreibt, beschreibt Gradle es mit Code: ein Build-Skript, das einen Graphen aus Tasks konfiguriert. Dieser Wechsel zu einem programmierbaren Modell, zusammen mit einem inkrementellen Build-Cache, der bereits erledigte Arbeit überspringt, ist der Grund, warum Gradle Android und viele große Java-Projekte antreibt.

Gradle vs. Maven

Beide Werkzeuge lösen dasselbe Problem — wiederholbare Builds mit verwalteten Abhängigkeiten — treffen aber unterschiedliche Kompromisse. Falls Sie Maven bereits kennen, ist dies die Übersicht:

Keines ist streng besser. Mavens Starrheit macht Builds vorhersehbar; Gradles Flexibilität macht komplexe Builds ausdrückbar. Dieser Teil vermittelt Gradle; die Maven-Einführung behandelt die andere Seite.

Ein minimales Java-Build-Skript

Ein Gradle-Java-Projekt besteht aus einer build.gradle und einem konventionellen Quellverzeichnis-Layout (src/main/java, src/test/java). Das Anwenden des eingebauten java-Plugins lehrt Gradle, wie es kompilieren, testen und jar-Dateien erstellen soll:

plugins {
    id 'java'
}

group = 'com.example'
version = '1.0.0'

repositories {
    mavenCentral()
}

dependencies {
    implementation 'com.google.guava:guava:33.0.0-jre'
    testImplementation 'org.junit.jupiter:junit-jupiter:5.10.0'
}

Die Kotlin-DSL (build.gradle.kts) drückt dasselbe mit typsicheren Accessors aus:

plugins {
    java
}

dependencies {
    implementation("com.google.guava:guava:33.0.0-jre")
    testImplementation("org.junit.jupiter:junit-jupiter:5.10.0")
}

Tasks sind die Arbeitseinheit

Alles, was Gradle tut, ist ein Task — compileJava, test, jar, build. Tasks deklarieren Abhängigkeiten von anderen Tasks und bilden so einen gerichteten azyklischen Graphen (DAG). Wenn Sie gradle build ausführen, durchläuft Gradle diesen Graphen und führt jede Voraussetzung genau einmal in der richtigen Reihenfolge aus. Sie können auch eigene definieren:

task hello {
    doLast {
        println 'Hello from a custom Gradle task'
    }
}

task release {
    dependsOn 'build', 'hello'
}

Das java-Plugin verdrahtet für Sie einen Standardgraphen: classes hängt von compileJava und processResources ab; jar hängt von classes ab; test hängt von classes und compileTestJava ab; und build hängt von jar und test ab. Die Anforderung von build führt daher alle in Abhängigkeitsreihenfolge aus.

Der Wrapper und die Kommandozeile

Der Gradle Wrapper (gradlew / gradlew.bat) ist ein eingechecktes Skript, das die genaue Gradle-Version herunterlädt und ausführt, die ein Projekt erwartet, sodass Mitwirkende Gradle nicht global installiert haben müssen:

./gradlew build          # compile, test, and package
./gradlew test           # run tests only
./gradlew clean build    # wipe outputs, then rebuild from scratch
./gradlew tasks          # list available tasks
./gradlew dependencies   # print the resolved dependency tree

Die Verwendung von ./gradlew anstelle eines System-gradle ist die empfohlene Vorgehensweise — sie macht den Build auf allen Maschinen und in CI reproduzierbar.

Ein praktisches Beispiel: ein Task-Graph, aufgelöst wie Gradle es tut

Auf dem Runner dieser Seite ist kein Gradle verfügbar, daher modellieren wir anstelle eines echten Builds Gradles Kernengine in reinem Java: ein Graph von Tasks mit Abhängigkeiten, aufgelöst in eine Ausführungsreihenfolge mit einem topologischen Sortieralgorithmus — genau das, was Gradle tut, wenn Sie gradle build eingeben. Der zweite Durchlauf zeigt, wie aktuelle Tasks übersprungen werden, was Gradles Trick für inkrementelle Builds ist.

Was man aus dem Durchlauf mitnehmen kann:

• Der Build deklariert 7 Tasks, aber Sie geben niemals eine Reihenfolge von Hand an — Sie fragen nach build und der Graph berechnet den Rest. Diese Umkehrung (Abhängigkeiten deklarieren, das Werkzeug ordnet sie) ist das Herzstück von Gradles Task-Modell.
• Die aufgelöste Reihenfolge gibt zuerst compileJava und processResources aus, dann classes, jar, compileTestJava, test und schließlich build. Ein Task läuft erst, nachdem jeder Task, von dem er abhängt, abgeschlossen ist — deshalb geht die Kompilierung der Verpackung voraus und Tests gehen build voraus.
• classes wird über zwei Pfade erreicht (über jar und über test), erscheint aber einmal in der Reihenfolge — die done-Menge stellt sicher, dass jeder Task nur einmal ausgeführt wird, genau wie Gradle dieselben Quellen in einem Aufruf nie zweimal kompiliert.
• Beim zweiten Durchlauf geben die drei als aktuell markierten Tasks (UP-TO-DATE) aus und werden nicht gezählt; nur jar, compileTestJava, test und build zeigen (EXEC). Das ist Gradles inkrementeller Build: Tasks, deren Eingaben unverändert sind, werden übersprungen.
• Die letzte Zeile meldet 4 of 7 ausgeführte Tasks. Unverändertes Werk zu überspringen ist genau der Grund, warum ein zweites gradle build viel schneller ist als das erste, und warum der Build-Cache bei großen Projekten wichtig ist.

Was der Rest dieses Teils behandelt

Das Schreiben echter build.gradle-Skripte, das Deklarieren und Auflösen von Abhängigkeiten aus Maven Central, das Anwenden und Konfigurieren von Plugins, das Definieren benutzerdefinierter Tasks und die Verwendung des Wrappers in CI. Das nächste Kapitel, Ein Gradle-Java-Projekt erstellen, richtet ein vollständiges Gradle-Java-Projekt aus einem leeren Verzeichnis ein.

Übungen