Comment demander à Maven d'utiliser la dernière version d'une dépendance ?

Question

Dans Maven, les dépendances sont généralement configurées comme ceci :

<dependency>
  <groupId>wonderful-inc</groupId>
  <artifactId>dream-library</artifactId>
  <version>1.2.3</version>
</dependency>

Désormais, si vous travaillez avec des bibliothèques dont les versions sont fréquentes, la mise à jour constante de la balise <version> peut être quelque peu ennuyeuse.Existe-t-il un moyen de dire à Maven de toujours utiliser la dernière version disponible (à partir du référentiel) ?

Answer 1

NOTE:

Cette réponse s'applique uniquement à Maven 2 !Le mentionné LATEST et RELEASE métaversions ont été abandonnés dans Maven 3 "pour des raisons de builds reproductibles", il y a plus de 6 ans.Veuillez vous référer à ceci Solution compatible Maven 3.

---

Si vous souhaitez toujours utiliser la version la plus récente, Maven propose deux mots-clés que vous pouvez utiliser comme alternative aux plages de versions.Vous devez utiliser ces options avec précaution car vous ne contrôlez plus les plugins/dépendances que vous utilisez.

Lorsque vous dépendez d'un plugin ou d'une dépendance, vous pouvez utiliser la valeur de version LATEST ou RELEASE.LATEST fait référence à la dernière version publiée ou instantanée d'un artefact particulier, l'artefact le plus récemment déployé dans un référentiel particulier.RELEASE fait référence à la dernière version non instantanée du référentiel.En général, ce n’est pas une bonne pratique de concevoir un logiciel qui dépend d’une version non spécifique d’un artefact.Si vous développez un logiciel, vous souhaiterez peut-être utiliser RELEASE ou LATEST pour plus de commodité afin de ne pas avoir à mettre à jour les numéros de version lorsqu'une nouvelle version d'une bibliothèque tierce est publiée.Lorsque vous publiez un logiciel, vous devez toujours vous assurer que votre projet dépend de versions spécifiques afin de réduire les risques que votre build ou votre projet soit affecté par une version logicielle échappant à votre contrôle.Utilisez LATEST et RELEASE avec prudence, voire pas du tout.

Voir le Section Syntaxe POM du livre Maven pour plus de détails.Ou voir ce doc sur Plages de versions de dépendance, où:

• Un crochet ( [ & ] ) signifie « fermé » (inclus).
• Une parenthèse ( ( & ) ) signifie « ouvert » (exclusif).

Voici un exemple illustrant les différentes options.Dans le référentiel Maven, com.foo:my-foo contient les métadonnées suivantes :

<?xml version="1.0" encoding="UTF-8"?><metadata>
  <groupId>com.foo</groupId>
  <artifactId>my-foo</artifactId>
  <version>2.0.0</version>
  <versioning>
    <release>1.1.1</release>
    <versions>
      <version>1.0</version>
      <version>1.0.1</version>
      <version>1.1</version>
      <version>1.1.1</version>
      <version>2.0.0</version>
    </versions>
    <lastUpdated>20090722140000</lastUpdated>
  </versioning>
</metadata>

Si une dépendance sur cet artefact est requise, vous disposez des options suivantes (autres gammes de versions peuvent être précisés bien sûr, en montrant simplement ceux qui sont pertinents ici) :

Déclarez une version exacte (sera toujours résolue à 1.0.1) :

<version>[1.0.1]</version>

Déclarez une version explicite (sera toujours résolue en 1.0.1 sauf si une collision se produit, lorsque Maven sélectionnera une version correspondante) :

<version>1.0.1</version>

Déclarez une plage de versions pour tous les 1.x (sera actuellement résolue en 1.1.1) :

<version>[1.0.0,2.0.0)</version>

Déclarez une plage de versions ouverte (sera résolue à 2.0.0) :

<version>[1.0.0,)</version>

Déclarez la version comme DERNIÈRE (sera résolue en 2.0.0) (supprimée de maven 3.x)

<version>LATEST</version>

Déclarez la version comme RELEASE (sera résolue en 1.1.1) (supprimée de maven 3.x) :

<version>RELEASE</version>

Notez que par défaut vos propres déploiements mettront à jour l'entrée "latest" dans les métadonnées Maven, mais pour mettre à jour l'entrée "release", vous devez activer le "release-profile" depuis le Maven super POM.Vous pouvez le faire avec "-Prelease-profile" ou "-DperformRelease=true".

---

Il convient de souligner que toute approche permettant à Maven de choisir les versions de dépendance (LATEST, RELEASE et plages de versions) peut vous exposer à des problèmes de temps de construction, car les versions ultérieures peuvent avoir un comportement différent (par exemple, le plugin de dépendance a précédemment changé de version par défaut). valeur de vrai à faux, avec des résultats confus).

C'est donc généralement une bonne idée de définir des versions exactes dans les versions.Comme La réponse de Tim le souligne, le plugin-versions-maven est un outil pratique pour mettre à jour les versions de dépendances, en particulier la versions:utiliser les dernières versions et versions:utiliser les dernières versions objectifs.

Answer 2

Maintenant, je sais que ce sujet est ancien, mais en lisant la question et la réponse fournie par OP, il semble que Plugin de versions Maven aurait pu en fait être une meilleure réponse à sa question :

En particulier, les objectifs suivants pourraient être utiles :

• versions:utiliser les dernières versions recherche le POM pour toutes les versions qui ont été une version plus récente et les remplace par la dernière version.
• versions:utiliser les dernières versions Recherche le POM pour toutes les versions non snapshot qui ont été une version plus récente et les remplace par la dernière version de version.
• versions:propriétés de mise à jour met à jour les propriétés définies dans un projet afin qu'ils correspondent à la dernière version disponible de dépendances spécifiques.Cela peut être utile si une suite de dépendances doit toutes être verrouillées sur une version.

Les autres objectifs suivants sont également fournis :

• versions:mises à jour des dépendances d'affichage Analyse les dépendances d'un projet et produit un rapport des dépendances qui ont des versions plus récentes disponibles.
• versions : mises à jour du plug-in d'affichage Analyse les plugins d'un projet et produit un rapport des plugins qui ont des versions plus récentes disponibles.
• versions: mise à jour-parent met à jour la section parent d'un projet afin qu'il fait référence à la dernière version disponible.Par exemple, si vous utilisez un POM de racine d'entreprise, cet objectif peut être utile si vous devez vous assurer que vous utilisez la dernière version du Pom de la racine d'entreprise.
• versions : mise à jour des modules enfants met à jour la section parent des modules enfants d'un projet afin que la version correspond à la version du projet actuel.Par exemple, si vous avez un POM d'agrégateur qui est également le parent des projets qu'il agrége et que les enfants et les versions parents se synchronisent, ce mojo peut aider à réparer les versions des modules enfants.(Remarque Vous devrez peut-être invoquer Maven avec l'option -N afin d'exécuter cet objectif si votre projet est si mal brisé qu'il ne peut pas construire en raison de la version de la version).
• versions:instantanés de verrouillage recherche le pom pour toutes les versions-snapshot et les remplace par la version horodatrice actuelle de ce -snapshot, par exemple-20090327.172306-4
• versions:instantanés de déverrouillage recherche au POM pour toutes les versions instantanées verrouillées à horodatage et les remplace par -snapshot.
• versions:plages de résolution Finds les dépendances à l'aide de plages de version et résout la plage de la version spécifique utilisée.
• versions:versions d'utilisation Recherche le POM pour toutes les versions -snapshot qui ont été publiées et les remplace par la version de version correspondante.
• versions:utiliser les prochaines versions Recherche le POM pour toutes les versions non snapshot qui ont été une version plus récente et les remplace par la prochaine version de version.
• versions:utiliser les versions suivantes Recherche le POM pour toutes les versions qui ont été une version plus récente et les remplace par la prochaine version.
• versions:validation supprime les fichiers pom.xml.versionsBackup.Forme la moitié du "SCM du pauvre homme" intégré.
• versions:rétablir Restaure les fichiers pom.xml à partir des fichiers pom.xml.versionsbackup.Forme la moitié du "SCM du pauvre homme" intégré.

Je pensais juste que je l'inclurais pour toute référence future.

Answer 3

Veuillez jeter un oeil à cette page (section « Plages de versions des dépendances »).Ce que vous voudrez peut-être faire, c'est quelque chose comme

<version>[1.2.3,)</version>

Ces plages de versions sont implémentées dans Maven2.

Answer 4

Contrairement à d'autres, je pense qu'il existe de nombreuses raisons pour lesquelles vous pourriez je veux toujours la dernière version.Surtout si vous effectuez un déploiement continu (nous avons parfois environ 5 versions par jour) et que vous ne souhaitez pas réaliser un projet multi-modules.

Ce que je fais, c'est demander à Hudson/Jenkins de faire ce qui suit pour chaque build :

mvn clean versions:use-latest-versions scm:checkin deploy -Dmessage="update versions" -DperformRelease=true

Autrement dit, j'utilise le plugin versions et le plugin scm pour mettre à jour les dépendances, puis les archiver dans le contrôle de source.Oui, je laisse mon CI effectuer les enregistrements SCM (ce que vous devez faire de toute façon pour le plugin de version Maven).

Vous souhaiterez configurer le plugin de versions pour mettre à jour uniquement ce que vous voulez :

        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>versions-maven-plugin</artifactId>
            <version>1.2</version>
            <configuration>
                <includesList>com.snaphop</includesList>
                <generateBackupPoms>false</generateBackupPoms>
                <allowSnapshots>true</allowSnapshots>
            </configuration>
        </plugin>

J'utilise le plugin release pour faire la version qui prend en charge -SNAPSHOT et valide qu'il existe une version release de -SNAPSHOT (ce qui est important).

Si vous faites ce que je fais, vous obtiendrez la dernière version pour toutes les versions d'instantanés et la dernière version pour les versions release.Vos builds seront également reproductibles.

Mise à jour

J'ai remarqué certains commentaires demandant des détails sur ce flux de travail.Je dirai que nous n'utilisons plus cette méthode et la principale raison pour laquelle le plugin des versions Maven est bogué et en général est intrinsèquement défectueux.

Il est défectueux car pour exécuter le plugin versions afin d'ajuster les versions, toutes les versions existantes doivent exister pour que le pom fonctionne correctement.Autrement dit, le plugin de versions ne peut pas mettre à jour vers la dernière version de quoi que ce soit s'il ne trouve pas la version référencée dans le pom.C'est en fait plutôt ennuyeux car nous nettoyons souvent les anciennes versions pour des raisons d'espace disque.

En réalité, vous avez besoin d'un outil distinct de Maven pour ajuster les versions (vous ne dépendez donc pas du fichier pom pour fonctionner correctement).J'ai écrit un tel outil dans le langage modeste qu'est Bash.Le script mettra à jour les versions comme le plugin de version et réarchivera le pom dans le contrôle de source.Il fonctionne également 100 fois plus vite que le plugin des versions mvn.Malheureusement, il n'est pas écrit de manière à être utilisé par le public, mais si les gens sont intéressés, je pourrais le faire ainsi et le mettre dans un résumé ou un github.

Pour en revenir au flux de travail, certains commentaires le demandent, voici ce que nous faisons :

1. Nous avons une vingtaine de projets dans leurs propres référentiels avec leurs propres tâches Jenkins
2. Lorsque nous publions, le plugin Maven Release est utilisé.Le flux de travail est couvert dans la documentation du plugin.Le plugin Maven Release est un peu nul (et je suis gentil) mais il fonctionne.Nous prévoyons un jour de remplacer cette méthode par quelque chose de plus optimal.
3. Lorsqu'un des projets est publié, Jenkins exécute ensuite un travail spécial, nous appellerons le travail de mise à jour de toutes les versions (la manière dont Jenkins sait qu'il s'agit d'une version est compliquée, en partie parce que le plugin de version Maven Jenkins est également assez merdique).
4. Le travail de mise à jour de toutes les versions connaît les 20 projets.Il s'agit en fait d'un agrégateur pom pour être précis avec tous les projets de la section modules par ordre de dépendance.Jenkins exécute notre foo magique groovy/bash qui extraira tous les projets, mettra à jour les versions avec la dernière version, puis archivera les poms (encore une fois dans l'ordre des dépendances en fonction de la section des modules).
5. Pour chaque projet, si le pom a changé (en raison d'un changement de version dans certaines dépendances), il est archivé, puis nous pingons immédiatement jenkins pour exécuter le travail correspondant pour ce projet (c'est pour préserver l'ordre des dépendances de construction, sinon vous êtes à la merci du planificateur de sondage SCM).

À ce stade, je suis d'avis que c'est de toute façon une bonne chose que la version et la version automatique soient un outil distinct de votre version générale.

Maintenant, vous pourriez penser que Maven est en quelque sorte nul à cause des problèmes énumérés ci-dessus, mais cela serait en réalité assez difficile avec un outil de construction qui n'a pas de déclaratif facile à analyser. extensible syntaxe (alias XML).

En fait, nous ajoutons des attributs XML personnalisés via des espaces de noms pour aider à indiquer les scripts bash/groovy (par ex.ne mettez pas à jour cette version).

Answer 5

La syntaxe des dépendances se trouve au niveau du Spécification des exigences de version de dépendance Documentation.Le voici pour être complet :

Dépendances version L'élément définit les exigences de version, utilisées pour calculer la version de dépendance effective.Les exigences de version ont la syntaxe suivante :

• 1.0:Exigence "Soft" sur 1.0 (juste une recommandation, si elle correspond à toutes les autres plages pour la dépendance)
• [1.0]:Exigence "difficile" sur 1.0
• (,1.0]:x <= 1,0
• [1.2,1.3]:1,2 <= x <= 1,3
• [1.0,2.0):1,0 <= x < 2,0
• [1.5,):x >= 1,5
• (,1.0],[1.2,):x <= 1,0 ou x >= 1,2 ;plusieurs ensembles sont séparés par des virgules
• (,1.1),(1.1,):Cela exclut 1.1 (par exemple s'il est connu pour ne pas fonctionner en combinaison avec cette bibliothèque)

Dans ton cas, tu pourrais faire quelque chose comme <version>[1.2.3,)</version>

Answer 6

Êtes-vous éventuellement dépendant de versions de développement qui changent évidemment beaucoup au cours du développement ?

Au lieu d'incrémenter la version des versions de développement, vous pouvez simplement utiliser une version instantanée que vous écrasez si nécessaire, ce qui signifie que vous n'aurez pas à modifier la balise de version à chaque modification mineure.Quelque chose comme 1.0-SNAPSHOT...

Mais peut-être que vous essayez de réaliser autre chose ;)

Answer 7

Quiconque utilise LATEST, assurez-vous d'avoir -U sinon le dernier instantané ne sera pas extrait.

mvn -U dependency:copy -Dartifact=com.foo:my-foo:LATEST
// pull the latest snapshot for my-foo from all repositories

Answer 8

Au moment où cette question a été posée, il y avait quelques problèmes avec les plages de versions dans maven, mais ceux-ci ont été résolus dans les versions plus récentes de maven.Cet article décrit très bien le fonctionnement des plages de versions et les meilleures pratiques pour mieux comprendre comment maven comprend les versions : https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN8855

Answer 9

La vérité est que même dans 3.x, cela fonctionne toujours, étonnamment, les projets sont construits et déployés.Mais le mot clé LATEST/RELEASE causant des problèmes dans m2e et Eclipse partout, les projets dépendent AUSSI de la dépendance qui déployée via LATEST/RELEASE ne parvient pas à reconnaître la version.

Cela posera également des problèmes si vous essayez de définir la version en tant que propriété et de la référencer ailleurs.

La conclusion est donc d'utiliser le versions-maven-plugin si vous le pouvez.

Answer 10

Parfois, vous ne souhaitez pas utiliser les plages de versions, car il semble qu'elles soient " lentes " à résoudre vos dépendances, en particulier lorsqu'une livraison continue est en place et qu'il existe des tonnes de versions - principalement lors d'un développement intensif.

Une solution de contournement serait d'utiliser le versions-maven-plugin.Par exemple, vous pouvez déclarer une propriété :

<properties>
    <myname.version>1.1.1</myname.version>
</properties>

et ajoutez le plugin versions-maven à votre fichier pom :

<build>
    <plugins>
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>versions-maven-plugin</artifactId>
            <version>2.3</version>
            <configuration>
                <properties>
                    <property>
                        <name>myname.version</name>
                        <dependencies>
                            <dependency>
                                <groupId>group-id</groupId>
                                <artifactId>artifact-id</artifactId>
                                <version>latest</version>
                            </dependency>
                        </dependencies>
                    </property>
                </properties>
            </configuration>
        </plugin>
    </plugins>
</build>

Ensuite, afin de mettre à jour la dépendance, vous devez exécuter les objectifs :

mvn versions:update-properties validate

S'il existe une version plus récente que la 1.1.1, elle vous dira :

[INFO] Updated ${myname.version} from 1.1.1 to 1.3.2

Answer 11

Si vous souhaitez que Maven utilise la dernière version d'une dépendance, vous pouvez utiliser Versions du plugin Maven et comment utiliser ce plugin, Tim a déjà donné une bonne réponse, suivez son répondre.

Mais en tant que développeur, je ne recommanderai pas ce type de pratiques.POURQUOI?

la réponse au pourquoi est déjà donnée par Pascal Thivent dans le commentaire de la question

Je ne recommande vraiment pas cette pratique (ni l'utilisation de gammes de versions) pour la reproductibilité de la construction.Une version qui commence à échouer soudainement pour une raison inconnue est beaucoup plus ennuyeuse que de mettre à jour manuellement un numéro de version.

Je recommanderai ce type de pratique :

<properties>
    <spring.version>3.1.2.RELEASE</spring.version>
</properties>

<dependencies>

    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-core</artifactId>
        <version>${spring.version}</version>
    </dependency>

    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context</artifactId>
        <version>${spring.version}</version>
    </dependency>

</dependencies>

il est facile à entretenir et à déboguer.Vous pouvez mettre à jour votre POM en un rien de temps.

Answer 12

MA solution dans maven 3.5.4, utilisez Nexus, dans Eclipse :

<dependency>
    <groupId>yilin.sheng</groupId>
    <artifactId>webspherecore</artifactId>
    <version>LATEST</version> 
</dependency>

puis en éclipse : atl + F5, et choisissez le force update of snapshots/release

ça marche pour moi.