Utiliser la dernière version d'une dépendance dans Maven
1. Vue d'ensemble
La mise à niveau manuelle des dépendances Maven a toujours été un travail fastidieux, en particulier dans les projets avec de nombreuses librairies libérant fréquemment.
Dans ce tutoriel, nous allons apprendrehow to exploit the Versions Maven Plugin to keep our dependencies up-to-date.
Cela peut avant tout s'avérer extrêmement utile lorsque vous implémentez des pipelines d'intégration continue qui mettent automatiquement à niveau les dépendances, testent que tout fonctionne toujours correctement et valide ou annule le résultat, selon le cas.
2. Syntaxe de la plage de versions de Maven
À l'époque de Maven2, les développeurs pouvaient spécifier des plages de versions dans lesquelles les artefacts auraient été mis à niveau sans intervention manuelle.
Cette syntaxe est toujours valide, utilisée dans plusieurs projets et mérite donc d'être connue:
Néanmoins, nous devrions éviter cela autant que possible en faveur du plugin Versions Maven, car avancer des versions concrètes de l'extérieur nous donne nettement plus de contrôle que de laisser Maven gérer lui-même l'ensemble de l'opération.
2.1. Syntaxe obsolète
Maven2 a également fourni deux valeurs de métaversion spéciales pour obtenir le résultat:LATEST etRELEASE.
However, this legacy upgrade method was causing unpredictability where CI needed reproducibility. Par conséquent,they’ve been deprecated and completely removed dans Maven3:
Par souci de construction reproductible, Maven 3.x ne prend plus en charge l'utilisation de ces métaversions dans le POM.
3. Versions du plugin Maven
LeVersions Maven Plugin est le moyen standard de facto de gérer la gestion des versions de nos jours.
Des comparaisons de haut niveau entre les référentiels distants au verrouillage de timestamp de niveau inférieur pour les versions SNAPSHOT, sa liste exhaustive d’objectifs nous permet de prendre en charge tous les aspects de nos projets impliquant des dépendances.
Bien que beaucoup d’entre eux ne soient pas couverts par ce didacticiel, examinons de plus près ceux qui nous aideront dans le processus de mise à niveau.
3.1. Le cas de test
Avant de commencer, définissons notre scénario de test:
-
trois versions avec une version codée en dur
-
un RELEASE avec une version de propriété, et
-
un instantané
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
Enfin, excluons également un artefact du processus lors de la définition du plugin:
org.codehaus.mojo
versions-maven-plugin
2.7
org.apache.commons:commons-collections4
4. Affichage des mises à jour disponibles
Tout d'abord,to 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
Comme nous pouvons le voir,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.
En revanche, il a ignoré le SNAPSHOT, car il s'agit d'une version de développement dont la mise à jour automatique n'est souvent pas sûre.
5. Mettre à jour les dépendances
Lors de la première exécution d'une mise à jour, le plugin crée une sauvegarde despom.xml nomméspom.xml.versionsBackup.
Bien que chaque itération modifie lespom.xml, le fichier de sauvegarde conservera l'état d'origine du projet jusqu'au moment où l'utilisateur s'engagera (viamvn versions:commit) ou rétablira (viamvn versions:revert) le processus complet.
5.1. Conversion de SNAPSHOTs en RELEASEs
Il arrive parfois qu'un projet inclue un SNAPSHOT (une version en cours de développement intensif).
Nous pouvons utiliserversions:use-releases pour vérifier si le RELEASE correspondant a été publié, et encore plus pour convertir notre SNAPSHOT en ce RELEASE en même temps:
mvn versions:use-releases
5.2. Mise à jour vers la prochaine version
We can port every non-SNAPSHOT dependency to its nearest version avecversions:use-next-releases:
mvn versions:use-next-releases
Nous pouvons clairement voir que le plugin a mis à jourcommons-io,commons-lang3, et mêmecommons-beanutils, qui n'est plus un SNAPSHOT, vers leur prochaine version.
Plus important encore, il a ignorécommons-collections4, qui est exclu dans la configuration du plugin, etcommons-compress, qui a un numéro de version spécifié dynamiquement via une propriété.
5.3. Mise à jour vers la dernière version
La mise à jour de chaque dépendance non-SNAPSHOT vers sa dernière version fonctionne de la même manière, en changeant simplement l'objectif enversions:use-latest-releases:
mvn versions:use-latest-releases
6. Filtrer les versions indésirables
In case we want to ignore certain versions, the plugin configuration can be tuned pour charger dynamiquement des règles à partir d'un fichier externe:
org.codehaus.mojo
versions-maven-plugin
2.7
http://www.mycompany.com/maven-version-rules.xml
Plus remarquable,<rulesUri> peut également faire référence à un fichier local:
file:///home/andrea/maven-version-rules.xml 6.1. Ignorer les versions dans le monde
Nous pouvons configurer notre fichier de règles pour queit’ll ignore versions matching a specific Regular Expression:
.*-beta
6.2. Ignorer les versions sur une base par règle
Enfin, si nos besoins sont plus spécifiques, nous pouvons créer un ensemble de règles:
.*-RELEASE
2.1.0
7. Conclusion
Nous avons vu comment vérifier et mettre à jour les dépendances d'un projet de manière sûre, automatique et conforme à Maven3.
Comme toujours, le code source est disponibleover on GitHub, avec un script pour vous aider à tout présenter étape par étape et sans complexité.
Pour le voir en action, téléchargez simplement le projet et exécutez-le dans un terminal (ou dans Git Bash si vous utilisez Windows):
./run-the-demo.sh