Question Comment puis-je dire à Maven d'utiliser la dernière version d'une dépendance?


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>

Maintenant, si vous travaillez avec des bibliothèques qui ont des versions fréquentes, mettre à jour constamment la balise <version> peut être un peu ennuyeux. Est-il possible de dire à Maven de toujours utiliser la dernière version disponible (à partir du référentiel)?


653
2017-08-27 16:17


origine


Réponses:


REMARQUE: 

Cette réponse ne s'applique qu'à Maven 2! Le mentionné LATEST et RELEASE métaversions ont été lâchés dans Maven 3 "pour des constructions reproductibles", il y a plus de 6 ans. S'il vous plaît se référer à cette Solution compatible Maven 3


645
2017-07-23 14:58



Maintenant, je sais que ce sujet est vieux, mais en lisant la question et l'OP fourni réponse, il semble que le Maven Versions Plugin aurait pu être une meilleure réponse à sa question:

En particulier, les objectifs suivants pourraient être utiles:

  • versions: use-latest-versions recherche le pom pour toutes les versions qui ont été une version plus récente et les remplace par le dernier version.
  • versions: use-latest-releases recherche le pom pour tous les non-SNAPSHOT versions qui ont été plus récentes libérer et les remplace par le dernière version.
  • versions: update-properties met à jour les propriétés définies dans un projet de sorte qu'ils correspondent à la dernière version disponible de dépendances spécifiques. Cela peut être utile si une suite de dépendances Tout doit être verrouillé sur une version.

Les autres objectifs suivants sont également fournis:

  • versions: display-dependency-updates analyse les dépendances d'un projet et produit un rapport de ceux dépendances qui ont plus récent versions disponibles.
  • versions: display-plugin-updates analyse les plugins d'un projet et produit un rapport de ces plugins qui ont des versions plus récentes disponibles.
  • versions: mise à jour parent met à jour la section parent d'un projet qu'il fait référence à la plus récente version disponible. Par exemple, si vous utilisez un POM racine d'entreprise, ce objectif peut être utile si vous avez besoin de assurez-vous d'utiliser le dernier version de la racine de l'entreprise POM.
  • versions: update-child-modules met à jour la section parent de modules enfants d'un projet de sorte que le la version correspond à la version de Projet en cours. Par exemple, si vous avoir un pom agrégateur qui est aussi le parent pour les projets qu'il agrégats et les enfants et les versions parents sont désynchronisées, mojo peut aider à corriger les versions de modules enfants. (Notez que vous devrez peut-être invoquer Maven avec l'option -N dans afin d'exécuter cet objectif si votre projet est brisé si mal qu'il ne peut pas construire en raison de la version décalage).
  • versions: snapshots cherche le pom pour tout -SNAPSHOT versions et les remplace par le version de l'horodatage actuel de cette -SNAPSHOT, par ex. -20090327.172306-4
  • versions: unlock-snapshots recherche le pom pour tous les horodatages versions instantanées verrouillées et remplace les avec -SNAPSHOT.
  • versions: resolve-ranges recherche les dépendances à l'aide des plages de versions et résout la gamme à la spécifique version utilisée.
  • versions: use-releases recherche le pom pour toutes les versions -SNAPSHOT qui ont été libérés et remplace eux avec la libération correspondante version.
  • versions: use-next-releases recherche le pom pour tous les non-SNAPSHOT versions qui ont été plus récentes libérer et les remplace par le prochaine version.
  • versions: use-next-versions recherche le pom pour toutes les versions qui ont été une version plus récente et les remplace par la prochaine version.
  • versions: commit supprime les fichiers pom.xml.versionsBackup. Formes la moitié de la "Poor Man's" SCM ".
  • versions: rétablir restaure les fichiers pom.xml à partir du Fichiers pom.xml.versionsBackup. Formes la moitié de la "Poor Man's" SCM ".

Je pensais juste l'inclure pour toute référence future.


312
2017-07-23 16:03



S'il vous plaît jeter un oeil à cette page (section "Gammes de dépendances"). Ce que vous pourriez vouloir faire est quelque chose comme

<version>[1.2.3,)</version>

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


162
2017-08-27 16:56



Contrairement à d'autres, je pense qu'il y a beaucoup de raisons pour lesquelles vous pourriez veux toujours le dernier version. Surtout si vous effectuez un déploiement continu (nous avons parfois 5 versions par jour) et ne voulez pas faire un projet multi-module.

Ce que je fais, c'est que Hudson / Jenkins fasse ce qui suit pour chaque build:

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

C'est-à-dire que j'utilise le plugin versions et le plugin scm pour mettre à jour les dépendances et ensuite le vérifier dans le contrôle source. Oui, je laisse mon CI faire des checkins SCM (ce que vous devez faire de toute façon pour le plugin Maven Release).

Vous devrez configurer le plugin versions pour mettre à jour seulement 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 release 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 générations de snapshots et la dernière version pour les versions de versions. Vos builds seront également reproductibles.

Mettre à jour

J'ai remarqué quelques commentaires demandant quelques détails sur ce workflow. Je dirai que nous n'utilisons plus cette méthode et la grande raison pour laquelle le plugin maven versions est bogué et en général est intrinsèquement erroné.

Il est défectueux car pour exécuter le plugin versions pour ajuster les versions, toutes les versions existantes doivent exister pour que le pom fonctionne correctement. C'est le plugin versions ne peut pas mettre à jour vers la dernière version de n'importe quoi s'il ne peut pas trouver 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.

Vraiment, vous avez besoin d'un outil distinct de maven pour ajuster les versions (de sorte que vous ne dépendez pas du fichier pom pour fonctionner correctement). J'ai écrit un tel outil dans la langue humble qu'est Bash. Le script va mettre à jour les versions comme le plugin de version et vérifier le pom dans le contrôle de la source. Il fonctionne aussi comme 100x plus rapide que le plugin versions mvn. Malheureusement, il n'est pas écrit d'une manière à usage public, mais si les gens sont intéressés, je pourrais le faire ainsi et le mettre dans un gist ou un github.

Pour en revenir au workflow, certains commentaires ont demandé ce que nous faisons:

  1. Nous avons une vingtaine de projets dans leurs propres dépôts avec leurs propres emplois jenkins
  2. Lorsque nous publions le plugin Maven Release est utilisé. Le workflow de cela est couvert dans la documentation du plugin. Le plugin maven sorte de sucks (et je suis gentil) mais ça marche. Un jour, nous prévoyons de remplacer cette méthode par quelque chose de plus optimal.
  3. Quand l'un des projets est libéré, alors jenkins exécute un travail spécial que nous appellerons le travail de mise à jour de toutes les versions (comment jenkins sait que sa version est compliquée en partie parce que le plugin de maven jenkins est assez merdique).
  4. Le travail de mise à jour de toutes les versions connaît tous les 20 projets. Il s'agit en fait d'un agrégateur pom spécifique à tous les projets de la section modules dans l'ordre des dépendances. Jenkins exécute notre magie groovy / bash foo qui va tirer tous les projets mettre à jour les versions au plus tard et ensuite checkin les poms (encore une fois fait dans l'ordre de dépendance basé sur la section des modules).
  5. Pour chaque projet, si le pom a changé (en raison d'un changement de version de certaines dépendances), il est archivé et nous lançons immédiatement un ping vers jenkins pour exécuter le job correspondant pour ce projet (ceci afin de préserver l'ordre de dépendance). du planificateur du sondage SCM).

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

Maintenant, vous pourriez penser maven sorte de sucks en raison des problèmes énumérés ci-dessus, mais cela serait en fait assez difficile avec un outil de construction qui n'a pas un déclaratif facile à analyser extensible syntaxe (aka XML).

En fait, nous ajoutons des attributs XML personnalisés par le biais d'espaces de noms pour aider à suggérer des scripts bash / groovy (par exemple, ne mettez pas à jour cette version).


72
2018-01-09 21:21



La syntaxe de dépendances est située à Spécification de l'exigence de version de dépendance Documentation. Ici c'est pour l'exhaustivité:

Dépendances version élément définir les exigences de version, utilisé pour calculer la version de dépendance efficace. Les exigences de version ont la syntaxe suivante:

  • 1.0: "Soft" exigence sur 1.0 (juste une recommandation, si elle correspond à toutes les autres plages pour la dépendance)
  • [1.0]: "Hard" exigence 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,): ceci exclut 1.1 (par exemple si l'on sait ne pas   travailler en combinaison avec cette bibliothèque)

Dans votre cas, vous pourriez faire quelque chose comme <version>[1.2.3,)</version>


27
2017-07-22 16:21



Est-ce que vous dépendez des 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 d'instantané que vous remplacez si nécessaire, ce qui signifie que vous ne devrez pas modifier la balise de version à chaque modification mineure. Quelque chose comme 1.0-SNAPSHOT ...

Mais peut-être que vous essayez d'accomplir autre chose;)


14
2017-08-27 16:30



Si jamais vous utilisez LATEST, veuillez vous assurer que vous avez bien -U sinon le dernier snapshot ne sera pas retiré.

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

6
2017-08-03 08:38



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


5
2018-04-03 16:00



La vérité est même en 3.x ça marche toujours, étonnamment les projets se construisent et se déploient. Mais le mot-clé LATEST / RELEASE causant des problèmes dans m2e et éclipse partout, projets ALSO dépend de la dépendance qui a déployé à travers le LATEST / RELEASE ne parviennent pas à reconnaître la version.

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

Donc, la conclusion est d'utiliser le versions-maven-plugin si tu peux.


3
2018-06-26 15:53



Parfois, vous ne voulez pas utiliser les gammes de versions, car il semble qu'elles soient "lentes" pour résoudre vos dépendances, particulièrement quand il y a une livraison continue en place et qu'il y a des tonnes de versions - principalement pendant le développement lourd.

Une solution de contournement consisterait à 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-plugin à 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 y a une version plus récente que 1.1.1, elle vous dira:

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

2
2018-05-08 15:59



Si vous voulez que Maven utilise la dernière version d'une dépendance, vous pouvez utiliser Versions Maven Plugin 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?

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

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

Je vais recommander 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 facile à déboguer. Vous pouvez mettre à jour votre POM en un rien de temps.


0
2018-04-18 09:10