Verwenden Sie die neueste Version einer Abhängigkeit in Maven
1. Überblick
Das manuelle Aktualisieren von Maven-Abhängigkeiten war immer eine mühsame Arbeit, insbesondere in Projekten mit vielen Bibliotheken, die häufig freigegeben werden.
In diesem Tutorial lernen wirhow to exploit the Versions Maven Plugin to keep our dependencies up-to-date.
Dies kann vor allem dann von großem Nutzen sein, wenn Continuous Integration-Pipelines implementiert werden, die die Abhängigkeiten automatisch aktualisieren, prüfen, ob alles noch ordnungsgemäß funktioniert, und das Ergebnis festschreiben oder zurücksetzen, je nachdem, was angemessen ist.
2. Maven-Versionsbereichssyntax
In den Maven2-Tagen konnten Entwickler Versionsbereiche angeben, in denen die Artefakte ohne manuellen Eingriff aktualisiert wurden.
Diese Syntax ist immer noch gültig, wird in verschiedenen Projekten verwendet und ist daher wissenswert:
Wir sollten es jedoch nach Möglichkeit zugunsten des Versions Maven Plugins vermeiden, da wir durch das Vorrücken konkreter Versionen von außen definitiv mehr Kontrolle haben, als wenn Maven den gesamten Vorgang alleine erledigt.
2.1. Veraltete Syntax
Maven2 lieferte auch zwei spezielle Metaversionswerte, um das Ergebnis zu erzielen:LATEST undRELEASE.
However, this legacy upgrade method was causing unpredictability where CI needed reproducibility. Daherthey’ve been deprecated and completely removed in Maven3:
Für reproduzierbare Builds unterstützt Maven 3.x die Verwendung dieser Metaversionen im POM nicht mehr
3. Versionen Maven Plugin
Versions Maven Plugin ist heutzutage de facto die Standardmethode für die Versionsverwaltung.
Angefangen beim Vergleich von Remote-Repositorys auf hoher Ebene bis hin zur Zeitstempelsperre auf niedriger Ebene für SNAPSHOT-Versionen können wir uns aufgrund der umfangreichen Liste von Zielen um jeden Aspekt unserer Projekte kümmern, der Abhängigkeiten umfasst.
Viele von ihnen sind nicht Gegenstand dieses Lernprogramms. Schauen wir uns jedoch diejenigen genauer an, die uns beim Upgrade helfen.
3.1. Der Testfall
Bevor wir beginnen, definieren wir unseren Testfall:
-
drei RELEASEs mit einer fest codierten Version
-
ein RELEASE mit einer Property-Version und
-
ein Schnappschuss
commons-io
commons-io
2.3
org.apache.commons
commons-collections4
4.0
org.apache.commons
commons-lang3
3.0
org.apache.commons
commons-compress
${commons-compress-version}
commons-beanutils
commons-beanutils
1.9.1-SNAPSHOT
1.15
Lassen Sie uns abschließend auch ein Artefakt aus dem Prozess ausschließen, wenn Sie das Plugin definieren:
org.codehaus.mojo
versions-maven-plugin
2.7
org.apache.commons:commons-collections4
4. Anzeigen verfügbarer Updates
Zunächstto simply know if and how we can update our project, the right tool for the job is versions:display-dependency-updates:
mvn versions:display-dependency-updates
Wie wir sehen können,the process included every RELEASE version. It even included commons-collections4 since the exclusion in the configuration refers to the update process, and not to the discovery one.
Im Gegensatz dazu wurde der SNAPSHOT ignoriert, da es sich um eine Entwicklungsversion handelt, deren automatische Aktualisierung häufig nicht sicher ist.
5. Aktualisieren der Abhängigkeiten
Wenn Sie zum ersten Mal ein Update ausführen, erstellt das Plugin eine Sicherungskopie derpom.xml mit dem Namenpom.xml.versionsBackup.
Während jede Iteration diepom.xml ändert, behält die Sicherungsdatei den ursprünglichen Status des Projekts bis zu dem Zeitpunkt bei, zu dem der Benutzer (durchmvn versions:commit) festschreibt (durchmvn versions:revert) oder zurücksetzt (durchmvn versions:revert) der ganze Ablauf.
5.1. Konvertieren von SNAPSHOTs in RELEASEs
Es kommt manchmal vor, dass ein Projekt einen SNAPSHOT enthält (eine Version, die sich noch in der Entwicklung befindet).
Wir könnenversions:use-releases verwenden, um zu überprüfen, ob die entsprechende RELEASE veröffentlicht wurde, und noch mehr, um unseren SNAPSHOT gleichzeitig in diese RELEASE zu konvertieren:
mvn versions:use-releases
5.2. Aktualisierung auf die nächste FREIGABE
We can port every non-SNAPSHOT dependency to its nearest version mitversions:use-next-releases:
mvn versions:use-next-releases
Wir können deutlich sehen, dass das Plugincommons-io,commons-lang3 und sogarcommons-beanutils, was kein SNAPSHOT mehr ist, auf die nächste Version aktualisiert hat.
Am wichtigsten ist, dasscommons-collections4 ignoriert wurde, was in der Plugin-Konfiguration ausgeschlossen ist, undcommons-compress, dessen Versionsnummer dynamisch über eine Eigenschaft angegeben wird.
5.3. Aktualisierung auf die neueste Version
Das Aktualisieren jeder Nicht-SNAPSHOT-Abhängigkeit auf die neueste Version funktioniert auf die gleiche Weise, indem einfach das Ziel inversions:use-latest-releases geändert wird:
mvn versions:use-latest-releases
6. Unerwünschte Versionen herausfiltern
In case we want to ignore certain versions, the plugin configuration can be tuned zum dynamischen Laden von Regeln aus einer externen Datei:
org.codehaus.mojo
versions-maven-plugin
2.7
http://www.mycompany.com/maven-version-rules.xml
Am bemerkenswertesten ist, dass<rulesUri> auch auf eine lokale Datei verweisen kann:
file:///home/andrea/maven-version-rules.xml 6.1. Versionen global ignorieren
Wir können unsere Regeldatei so konfigurieren, dassit’ll ignore versions matching a specific Regular Expression:
.*-beta
6.2. Versionen pro Regel ignorieren
Falls unsere Anforderungen spezifischer sind, können wir stattdessen eine Reihe von Regeln erstellen:
.*-RELEASE
2.1.0
7. Fazit
Wir haben gesehen, wie Sie die Abhängigkeiten eines Projekts auf sichere, automatische und Maven3-kompatible Weise überprüfen und aktualisieren können.
Wie immer ist der Quellcodeover on GitHub verfügbar, zusammen mit einem Skript, mit dem alles Schritt für Schritt und ohne Komplexität dargestellt werden kann.
Um es in Aktion zu sehen, laden Sie einfach das Projekt herunter und führen Sie es in einem Terminal aus (oder in Git Bash, wenn Sie Windows verwenden):
./run-the-demo.sh