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 bibliothèques publiées fréquemment.

Dans ce didacticiel, nous allons apprendre à exploiter le plug- in Versions Maven pour maintenir nos dépendances à jour .

Surtout, cela peut être extrêmement utile lors de la mise en œuvre de pipelines d'intégration continue qui mettent automatiquement à niveau les dépendances, testent que tout fonctionne toujours correctement et valident ou annulent 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 avoir besoin d'une intervention manuelle.

Cette syntaxe est toujours valide, utilisée dans plusieurs projets et vaut donc la peine d'être connue:

Néanmoins, nous devrions l'éviter en faveur du plugin Versions Maven lorsque cela est possible, car l'avancement des versions concrètes de l'extérieur nous donne certainement plus de contrôle que de laisser Maven gérer toute l'opération tout seul.

2.1. Syntaxe obsolète

Maven2 a également fourni deux valeurs de métaversion spéciales pour obtenir le résultat: LATEST et RELEASE .

LATEST recherche la dernière version possible, tandis que RELEASE vise la dernière version non-SNAPSHOT.

Ils sont, en effet, toujours absolument valables pour la résolution régulière des dépendances .

Cependant, cette méthode de mise à niveau héritée provoquait une imprévisibilité là où CI avait besoin de reproductibilité. Par conséquent, ils sont obsolètes pour la résolution des dépendances des plugins.

3. Versions du plugin Maven

Le plugin Versions Maven 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 d'horodatage de bas niveau pour les versions SNAPSHOT, sa liste massive d'objectifs nous permet de prendre en charge tous les aspects de nos projets impliquant des dépendances.

Bien que beaucoup d'entre eux sortent du cadre de 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 cas 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, pour savoir simplement si et comment nous pouvons mettre à jour notre projet, le bon outil pour le travail est versions: display-dependency-updates :

mvn versions:display-dependency-updates

Comme nous pouvons le voir, le processus comprenait chaque version de RELEASE. Il incluait même commons-collections4 puisque l'exclusion dans la configuration se réfère au processus de mise à jour, et non à celui de découverte.

En revanche, il a ignoré le SNAPSHOT, car il s'agit d'une version de développement qui n'est souvent pas sûre à mettre à jour automatiquement.

5. Mise à jour des dépendances

Lors de la première exécution d'une mise à jour, le plugin crée une sauvegarde du pom.xml nommée pom.xml.versionsBackup .

Bien que chaque itération modifie le pom.xml , le fichier de sauvegarde conservera l'état d'origine du projet jusqu'au moment où l'utilisateur s'engagera (via les versions mvn: commit ) ou rétablira (via les versions mvn: revert ) tout le processus.

5.1. Conversion de SNAPSHOTs en RELEASEs

Il arrive parfois qu'un projet comprenne un SNAPSHOT (une version qui est encore en développement intensif).

Nous pouvons utiliser des versions: 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

Nous pouvons porter chaque dépendance non-SNAPSHOT vers sa version la plus proche avec les versions: use-next-releases :

mvn versions:use-next-releases 

Nous pouvons clairement voir que le plugin a mis à jour commons-io , commons-lang3 , et même commons-beanutils , qui n'est plus un SNAPSHOT, vers leur prochaine version.

Plus important encore, il a ignoré c ommons-collections4 , qui est exclu dans la configuration du plugin, et commons-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 en versions: use-latest-releases :

mvn versions:use-latest-releases 

6. Filtering out Unwanted Versions

In case we want to ignore certain versions, the plugin configuration can be tuned to dynamically load rules from an external file:

 org.codehaus.mojo versions-maven-plugin 2.7  //www.mycompany.com/maven-version-rules.xml   

Most noteworthy, can also refer to a local file:

file:///home/andrea/maven-version-rules.xml 

6.1. Ignoring Versions Globally

We can configure our rules file so that it'll ignore versions matching a specific Regular Expression:

  .*-beta   

6.2. Ignoring Versions on a Per-Rule Basis

Finally, in case our needs are more specific, we can build a set of rules instead:

    .*-RELEASE 2.1.0     

7. Conclusion

We've seen how to check and update the dependencies of a project in a safe, automatic, and Maven3-compliant way.

As always, the source code is available over on GitHub, along with a script to help showcase everything step-by-step and without complexity.

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