Gradle Versions Plugin 0.61.0: veraltete Abhängigkeiten aufspüren
Gradle-Plugin zum Erkennen von Abhängigkeitsaktualisierungen. Gradle-Versions-Plugin Dieses Plugin meldet im Sinne des Maven-Versions-Plugins, welche Abhängigkeiten, Plugins und Gradle selbst Ihres Builds über neuere Versionen verfügen.
Auf einen Blick
- Was ist das?
- Ein Gradle-Plugin, das für Abhängigkeiten, Plugins und Gradle selbst neuere Versionen meldet, mit Revisionsfilter, JSON- und XML-Berichten sowie Multi-Projekt-Unterstützung. Es berichtet nur und ändert keine Build-Dateien.
- Für wen ist es gedacht?
- Das Gradle Versions Plugin passt zu Teams, die eine wiederholbare, build-eigene Sicht auf veraltete Abhängigkeiten wollen, ohne dass ein Werkzeug Build-Dateien anfasst. Wer automatische Updates per Pull Request sucht, braucht zusätzlich eines der im Abschnitt Related Plugins genannten Werkzeuge.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Groovy, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Was das Gradle Versions Plugin meldet und was es anfasst
Jeder längere JVM-Build entwickelt ein blindes Fenster: Dutzende Abhängigkeiten, mehrere Plugins, dazu Gradle selbst, und niemand prüft von Hand, ob es neuere Versionen gibt. Das Gradle Versions Plugin von Ben Manes adressiert genau dieses Fenster. Es erstellt einen Bericht, der aufzeigt, welche Abhängigkeiten, welche Plugins und welche Gradle-Version hinter dem neuesten Stand zurückliegen, im Geiste des Maven Versions Plugin für mojohaus.
Der entscheidende Designpunkt steht im README als klarer Satz: Das Plugin berichtet nur, es bearbeitet niemals Build-Dateien oder einen Versionskatalog. Auch Abhängigkeiten, die über einen Version Catalog deklariert sind, landen im Bericht, aber der Katalog bleibt unberührt. Für Werkzeuge, die Updates automatisch anwenden, verweist das README auf einen eigenen Abschnitt Related Plugins. Damit ist die Rolle des Plugins als Prüfwerkzeug definiert, nicht als Umsetzungsautomat.
dependencyUpdates über das Settings-Plugin von io.github.ben-manes.versions
Der empfohlene Weg zur Einbindung läuft über das Settings-Plugin, einmal angewendet in der settings.gradle.kts mit dem Block plugins { id("io.github.ben-manes.versions.settings") version "..." }. Diese Variante hat einen handfesten Vorteil gegenüber dem klassischen Projekt-Plugin: Sie erfasst auch die Plugins und Buildscript-Abhängigkeiten, die das Settings-Skript selbst deklariert, und deckt in einem Multi-Projekt-Build automatisch jedes Unterprojekt ab. Alternativ beschreibt das README die Legacy-Anwendung, ein Contributor-Plugin und einen Initialisierungsskript-Weg für Builds, die die Konfiguration nicht anfassen dürfen.
Ausgeführt wird die Aufgabe mit ./gradlew dependencyUpdates. Die Ausgabe erscheint auf der Konsole und zusätzlich in der Datei build/dependencyUpdates/report.txt. Das README zeigt das Format an einem Beispiel: Einträge wie com.google.inject:guice [2.0 -> 7.0.0] mit Repository-Link, darunter eine eigene Kategorie für Gradle-Release-Kandidaten, etwa den Sprung von 8.4 auf 9.7.0. Konfiguriert wird die Aufgabe im Build-Skript des Root-Projekts über tasks.named<DependencyUpdatesTask>("dependencyUpdates") oder, bei Builds ohne Root-Skript, über gradle.rootProject in der Settings-Datei.
revision, rejectVersionIf und der Stabilitätsfilter
Ohne Filter meldet ein Update-Werkzeug schnell Unbrauchbares, eine Alpha, einen Kandidaten, einen Nightly-Build. Die Eigenschaft revision steuert die Ivy-Auflösungsstrategie, Gradle unterstützt dafür nativ die Werte release, milestone (Voreinstellung) und integration. Das README weist aber auf eine Grenze der Maven-Welt hin: Repositories kennzeichnen Vorabversionen nicht als solche, darum kann eine Kandidatenversion unter jeder Strategie als neueste Version auftauchen.
Für echte Stabilität sorgt deshalb die Eigenschaft rejectVersionIf mit einer eigenen Prädikatsfunktion oder eine vollständige componentSelection-Strategie. Das README liefert vier Beispiele: das Zurückweisen aller nicht stabilen Versionen, das Zurückweisen von Kandidaten nur bei stabiler aktueller Version sowie einen reifegradbasierten Filter, der Qualifizierer wie alpha, beta und rc vergleicht. Empfohlen ist eine Kombination aus Stabilitätsfilter und Versionsgrenze, damit ein Update, das der Build bewusst ausgeschlossen hat, nicht erneut vorgeschlagen wird. Der Gradle-Release-Kanal lässt sich über gradleReleaseChannel auf current, release-candidate oder nightly beschränken.
Berichtsformate und die Falle der beigetragenen Abhängigkeiten
Die Eigenschaft outputFormatter akzeptiert plain als Voreinstellung, dazu json, xml und html sowie einen eigenen Formatierer als Closure oder Action. outputDir verweist standardmäßig auf build/dependencyUpdates, reportfileName auf report. Mehrere Eigenschaften, darunter revision, outputFormatter und gradleReleaseChannel, lassen sich auch als Systemeigenschaften übergeben, um einen einzelnen Lauf ohne Änderung der Build-Skripte umzukonfigurieren. Die JSON- und XML-Berichte decken alle drei Gradle-Kanäle ab und führen Felder dafür mit, ob eine Prüfung fehlgeschlagen ist und warum.
Ein Detail verdient Aufmerksamkeit, weil es Berichte verfälschen kann, wenn man es nicht kennt: Der Bericht schließt Abhängigkeiten ein, die Plugins beitragen, ohne dass der Build sie deklariert, etwa die Kotlin-Standardbibliothek oder die Werkzeugversionen von jacoco, checkstyle und pmd. Lässt der Build eine Werkzeugversion ungesetzt, meldet das Plugin die Standardversion, die mit Gradle gebündelt ist, eine Version, die im Build-Skript nirgends auftaucht. Der Klartextbericht kennzeichnet solche Einträge mit einer Zusatzzeile, damit sie nicht als Auflösungsfehler gelesen werden.
Multi-Projekt-Builds, Composite-Builds und isolierte Projekte
In einem Multi-Projekt-Build läuft die Aufgabe in jedem Projekt und wird zu einem zusammengeführten Bericht aggregiert. Weil jedes Projekt seine eigene Auflösung beisteuert, funktioniert das Muster mit paralleler Ausführung, Konfigurationscache und Konfiguration bei Bedarf. Jedes Projekt übernimmt die Einstellungen vom nächstgelegenen übergeordneten Projekt, das sie gesetzt hat, eine Konfiguration im Root-Projekt genügt also für alle Unterprojekte. Bei aktivierten Isolated Projects wendet das Settings-Plugin bei der Auswertung jedes Projekts ein Plugin an, sodass die empfohlene Einrichtung unverändert funktioniert.
Eingebundene Builds sind nach README eine eigene Kategorie: Sie sind separate Builds und benötigen das Plugin in ihrem eigenen Settings-Skript. Das README zeigt, wie eine Lebenszyklusaufgabe registriert wird, die von der dependencyUpdates-Aufgabe jedes eingebundenen Builds abhängt. Für Builds, die das Settings-Plugin nicht anwenden können, existiert das Contributor-Plugin, das nur den Produzenten registriert, der den aggregierten Bericht speist.
Kompatibilität ab Gradle 8.4 und das Tempo bis v0.61.0
Das Plugin verlangt Gradle 8.4 oder höher, was beim Anwenden geprüft wird. Es zielt auf Java-8-Bytecode und läuft damit auf jeder JVM, die Gradle selbst ausführen kann. Die Migrationshinweise im README dokumentieren Verhaltensänderungen ab v0.54.0, etwa die Attributionszeile in v0.59.0 und die Meldung teilweise aufgelöster Abhängigkeiten in v0.58.0.
Die Release-Historie der letzten Monate zeigt ein dichtes Tempo: v0.59.0 erschien am 3. August 2026, v0.60.0 am 7. August 2026, v0.61.0 am 9. August 2026. Wer das Plugin in einem Build festnagelt, sollte diese Dichte einkalkulieren, denn zwischen Nebenversionen hat es im README dokumentierte Verhaltensänderungen gegeben. Eine Pinning-Strategie über den Versionskatalog ist hier sachgerechter als ein gleitender Versionsbereich.
Grenzen des Berichtsmodells und der Weg über Related Plugins
Die größte Grenze ist zugleich das Designprinzip: Das Plugin ändert nichts. Ein Team mit hundert Abhängigkeiten erhält einen sauberen Bericht, aber jede Aktualisierung bleibt Handarbeit, samt Changelog-Lektüre und Testlauf. Für Teams, die automatische Update-Pull-Requests wollen, verweist das README auf verwandte Plugins, die Updates anwenden statt nur zu melden. Auch die Vorabversionen-Problematik bleibt ein Mehraufwand: Ohne eigenen rejectVersionIf-Filter muss man mit Kandidatenvorschlägen rechnen, je nach Repository-Mix.
Als konkrete Alternative bietet sich die Kombination aus diesem Plugin als Melder und einem automatisierenden Werkzeug aus dem Related-Plugins-Abschnitt an. Der Unterschied ist klar geschnitten: dependencyUpdates liefert die Entscheidungsgrundlage im Build selbst, das automatische Werkzeug setzt die Entscheidung in Commits um. Beide zusammen decken den Zyklus ab, jeweils mit klarer Verantwortung.
Redaktionelles Fazit
Das Gradle Versions Plugin passt zu Teams, die eine wiederholbare, build-eigene Sicht auf veraltete Abhängigkeiten wollen, ohne dass ein Werkzeug Build-Dateien anfasst. Wer automatische Updates per Pull Request sucht, braucht zusätzlich eines der im Abschnitt Related Plugins genannten Werkzeuge. Vor dem Rollout lohnt ein Lauf von ./gradlew dependencyUpdates mit outputFormatter = "json" in der build.gradle.kts, um zu prüfen, wie viele Alpha- und Kandidatenversionen der Standardfilter für den eigenen Repository-Mix durchlässt.
Community-Notizen