Abhängigkeiten in Maven auf dem neuesten Stand halten

In modernen Projekten ist es wichtiger denn je, dass Sie Ihre Abhängigkeiten aktuell halten. Alles ist mit dem Internet verbunden und muss sicher sein. Neue Sicherheitslücken in Bibliotheken werden innerhalb weniger Tage gefunden, ausgenutzt und gepatcht. Wir verwenden eine Vielzahl von Abhängigkeiten, und aufgrund der kontinuierlichen Bereitstellung müssen einige Ihrer Abhängigkeiten täglich aktualisiert werden. Ein solides Abhängigkeitsmanagement ist eine Grundvoraussetzung für gute Software. In diesem Blogbeitrag beschreibe ich, wie Sie ein Maven-Projekt mit dem Versions-Plugin auf dem neuesten Stand halten können. Die Verwendung des Versions-Plugins hat viele Vorteile und seine Konfiguration dauert weniger als eine Stunde. Daher empfehle ich, es für alle Maven-Projekte zu verwenden.

Das Maven-Ziel, mit dem Sie dies erreichen, lautet:

mvn versions:display-dependency-updates

Standardmäßig wird eine Liste aller veralteten Abhängigkeiten in der Eingabeaufforderung erstellt. Diese Liste enthält jedoch Fehlalarme und um sie in einer Umgebung für kontinuierliche Integration zu verwenden, sind weitere Konfigurationen erforderlich. Dieses Beispiel geht von einem typischen Maven-Projekt aus, mit einem übergeordneten pom, das alle Abhängigkeiten mithilfe des Maven-Abhängigkeitsverwaltungsmechanismus konfiguriert. Die von mir verwendete Plugin-Konfiguration lautet:

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>versions-maven-plugin</artifactId>
<inherited>false</inherited>
<configuration>
<outputFile>outdated-dependencies.txt</outputFile>
<rulesUri>file:///${session.executionRootDirectory}/maven-version-rules.xml</rulesUri>
</configuration>
</plugin>

Hier enthält <outputFile> die Datei, in die die Ergebnisse geschrieben werden. <inherited>false</inherited> verhindert, dass das Plugin in Ihren untergeordneten Projekten ausgeführt wird. Wenn alle Ihre Abhängigkeiten im übergeordneten pom definiert sind, werden die Ergebnisse nur unübersichtlich.

Die interessanteste Einstellung ist das Tag <rulesUri>. Dieses Tag verweist auf eine Datei, in der Sie Regeln festlegen können, die definieren, was als Update gilt. Manchmal schlägt das Versions-Plugin ein Abhängigkeitsupdate vor, das Sie nicht wünschen. Die meisten Projekte verwenden nur stabile Bibliotheken und vermeiden die verschiedenen Versionen Alpha, Beta, Release Candidate und Milestone. Es gibt auch einige ungerade Versionsnummern, die das Plugin durcheinander bringen. commons-collections hat zum Beispiel eine Versionsnummer 20031027.000000, die 2005 veröffentlicht wurde. Sie wollen wahrscheinlich die Version 3.2.2, die 2015 veröffentlicht wurde. Das Plugin schlägt jedoch 20031027.000000 vor, weil 20031027 größer als 3 ist.

Und schließlich möchten Sie manchmal eine Abhängigkeit nicht aktualisieren, weil die API nicht kompatibel ist oder weil sich der Aufwand für ein Upgrade nicht lohnt. Um dies zu berücksichtigen, benötigen Sie Vergleichsregeln. Diese werden in einer XML-Datei beschrieben und sagen dem Plugin, welche Versionen es auswählen soll. Die Beschreibung finden Sie hier: https://www.mojohaus.org/versions-maven-plugin/rule.html. Für unser Projekt habe ich die folgende Datei verwendet:

<?xml version="1.0" encoding="UTF-8"?>
<ruleset  xmlns_xsi="https://www.w3.org/2001/XMLSchema-instance" comparisonMethod="maven" xsi_schemaLocation="https://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0 https://mojo.codehaus.org/versions-maven-plugin/xsd/rule-2.0.0.xsd">
<ignoreVersions>
<!-- Ignore Alpha's, Beta's, release candidates and milestones -->
<ignoreVersion type="regex">(?i).*Alpha(?:-?d+)?</ignoreVersion>
<ignoreVersion type="regex">(?i).*Beta(?:-?d+)?</ignoreVersion>
<ignoreVersion type="regex">(?i).*-B(?:-?d+)?</ignoreVersion>
<ignoreVersion type="regex">(?i).*RC(?:-?d+)?</ignoreVersion>
<ignoreVersion type="regex">(?i).*CR(?:-?d+)?</ignoreVersion>
<ignoreVersion type="regex">(?i).*M(?:-?d+)?</ignoreVersion>
</ignoreVersions>
<rules>
<!-- Obvious mismatches -->
<rule groupId="commons-collections" artifactId="commons-collections">
<ignoreVersions>
<ignoreVersion type="regex">^200.*$</ignoreVersion>
</ignoreVersions>
</rule>
<rule groupId="commons-logging" artifactId="commons-logging">
<ignoreVersions>
<ignoreVersion>99.0-does-not-exist</ignoreVersion>
</ignoreVersions>
</rule>
<rule groupId="org.hamcrest">
<ignoreVersions>
<ignoreVersion>1.4-atlassian-1</ignoreVersion>
</ignoreVersions>
</rule>
<!-- Version 5 of hibernate requires javax.validation 1.1.0. This is a new api and a lot of effort to upgrade -->
<rule groupId="org.hibernate" artifactId="hibernate-validator" comparisonMethod="maven">
<ignoreVersions>
<ignoreVersion type="regex">^5.*$</ignoreVersion>
</ignoreVersions>
</rule>
<rule groupId="javax.validation" artifactId="validation-api">
<ignoreVersions>
<ignoreVersion type="regex">1.1.0.Final</ignoreVersion>
</ignoreVersions>
</rule>
</rules>
</ruleset>

Wie Sie sehen können, habe ich die Entscheidungen, die ich bei der Auswahl der Versionen getroffen habe, kommentiert: Ich habe alle nicht-stabilen Versionen verworfen. Ich habe einige merkwürdige Versionierungen in commons-collections und commons-logging gelöst. Ich habe die Atlassian-spezifische Version von Hamcrest ignoriert. Außerdem habe ich Hibernate 5 deaktiviert, da 4 für uns gut funktioniert und wir die neue API nicht verwenden wollen. Beachten Sie, dass diese Datei ein sehr guter Ort ist, um diese Abhängigkeitsentscheidungen zu dokumentieren.

Sie können Jenkins jetzt so einrichten, dass es regelmäßig ausgeführt wird (wir lassen es jeden Sonntag einmal laufen) und die erzeugte Datei per E-Mail an outdated-dependencies.txt senden. So können Sie Ihre Projekte ganz einfach auf dem neuesten Stand halten. Sie können unsere Regeldatei gerne als Ausgangspunkt für Ihr Projekt verwenden.