Wie kann ich Maven anweisen, die neueste Version einer Abhängigkeit zu verwenden?

https://stackoverflow.com/questions/30571

09-06-2019
|

Frage

In Maven werden Abhängigkeiten normalerweise wie folgt eingerichtet:

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

Wenn Sie nun mit Bibliotheken arbeiten, die häufige Veröffentlichungen haben, kann die ständige Aktualisierung des <version>-Tags etwas lästig sein.Gibt es eine Möglichkeit, Maven anzuweisen, immer die neueste verfügbare Version (aus dem Repository) zu verwenden?

Lösung

NOTIZ:

Diese Antwort gilt nur für Maven 2!Das erwähnte LATEST Und RELEASE Metaversionen wurden in Maven 3 „aus Gründen reproduzierbarer Builds“ entfernt., vor über 6 Jahren.Bitte beziehen Sie sich hierauf Maven 3-kompatible Lösung.

Wenn Sie immer die neueste Version verwenden möchten, verfügt Maven über zwei Schlüsselwörter, die Sie alternativ zu Versionsbereichen verwenden können.Sie sollten diese Optionen mit Vorsicht verwenden, da Sie nicht mehr die Kontrolle über die von Ihnen verwendeten Plugins/Abhängigkeiten haben.

Wenn Sie von einem Plugin oder einer Abhängigkeit abhängig sind, können Sie den Versionswert LATEST oder RELEASE verwenden.LATEST bezieht sich auf die neueste veröffentlichte oder Snapshot-Version eines bestimmten Artefakts, das zuletzt bereitgestellte Artefakt in einem bestimmten Repository.RELEASE bezieht sich auf die letzte Nicht-Snapshot-Version im Repository.Im Allgemeinen ist es keine bewährte Vorgehensweise, Software zu entwerfen, die von einer unspezifischen Version eines Artefakts abhängt.Wenn Sie Software entwickeln, möchten Sie möglicherweise der Einfachheit halber RELEASE oder LATEST verwenden, damit Sie die Versionsnummern nicht aktualisieren müssen, wenn eine neue Version einer Bibliothek eines Drittanbieters veröffentlicht wird.Wenn Sie Software veröffentlichen, sollten Sie immer sicherstellen, dass Ihr Projekt von bestimmten Versionen abhängt, um die Wahrscheinlichkeit zu verringern, dass Ihr Build oder Ihr Projekt von einer Softwareversion betroffen ist, die nicht unter Ihrer Kontrolle steht.Verwenden Sie LATEST und RELEASE, wenn überhaupt, mit Vorsicht.

Siehe die Abschnitt zur POM-Syntax im Maven-Buch für mehr Details.Oder sehen Sie sich dieses Dokument an Abhängigkeitsversionsbereiche, Wo:

Eine eckige Klammer ( [ & ] ) bedeutet „geschlossen“ (einschließlich).
Eine Klammer ( ( & ) ) bedeutet „offen“ (exklusiv).

Hier ist ein Beispiel, das die verschiedenen Optionen veranschaulicht.Im Maven-Repository verfügt com.foo:my-foo über die folgenden Metadaten:

<?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>

Wenn eine Abhängigkeit von diesem Artefakt erforderlich ist, haben Sie die folgenden Optionen (andere). Versionsbereiche können natürlich spezifiziert werden, hier werden nur die relevanten angezeigt):

Deklarieren Sie eine genaue Version (wird immer auf 1.0.1 aufgelöst):

<version>[1.0.1]</version>

Deklarieren Sie eine explizite Version (wird immer in 1.0.1 aufgelöst, es sei denn, es kommt zu einer Kollision, bei der Maven eine passende Version auswählt):

<version>1.0.1</version>

Deklarieren Sie einen Versionsbereich für alle 1.x (wird derzeit in 1.1.1 aufgelöst):

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

Deklarieren Sie einen offenen Versionsbereich (wird in 2.0.0 aufgelöst):

<version>[1.0.0,)</version>

Deklarieren Sie die Version als LATEST (wird in 2.0.0 aufgelöst) (aus Maven 3.x entfernt)

<version>LATEST</version>

Deklarieren Sie die Version als RELEASE (wird in 1.1.1 aufgelöst) (aus Maven 3.x entfernt):

<version>RELEASE</version>

Beachten Sie, dass Ihre eigenen Bereitstellungen standardmäßig den „latest“-Eintrag in den Maven-Metadaten aktualisieren, aber um den „release“-Eintrag zu aktualisieren, müssen Sie das „release-profile“ aus aktivieren Maven super POM.Sie können dies entweder mit „-Prelease-profile“ oder „-DperformRelease=true“ tun.

Es ist hervorzuheben, dass jeder Ansatz, der es Maven ermöglicht, die Abhängigkeitsversionen (LATEST, RELEASE und Versionsbereiche) auszuwählen, Sie anfällig für Probleme mit der Erstellungszeit machen kann, da spätere Versionen ein anderes Verhalten aufweisen können (z. B. hat das Abhängigkeits-Plugin zuvor einen Standardwert geändert). Wert von wahr nach falsch, mit verwirrenden Ergebnissen).

Daher ist es grundsätzlich sinnvoll, in Releases genaue Versionen zu definieren.Als Tims Antwort weist darauf hin, dass Maven-Versions-Plugin ist ein praktisches Tool zum Aktualisieren von Abhängigkeitsversionen, insbesondere der Versionen:Verwenden Sie die neuesten Versionen Und Versionen:Verwenden Sie die neuesten Versionen Ziele.

Andere Tipps

Jetzt weiß ich, dass dieses Thema alt ist, aber wenn ich die Frage und die vom OP bereitgestellte Antwort lese, scheint es das zu sein Maven-Versions-Plugin hätte tatsächlich eine bessere Antwort auf seine Frage sein können:

Insbesondere könnten folgende Ziele von Nutzen sein:

Versionen:Verwenden Sie die neuesten Versionen Sucht das POM nach allen Versionen, die eine neuere Version waren, und ersetzt sie durch die neueste Version.
Versionen:Verwenden Sie die neuesten Versionen Sucht nach dem POM nach allen nicht-snapshot-Versionen, die eine neuere Version waren und sie durch die neueste Versionsversion ersetzt.
Versionen:Update-Eigenschaften Aktualisiert die in einem Projekt definierten Eigenschaften, damit sie der neuesten verfügbaren Version bestimmter Abhängigkeiten entsprechen.Dies kann nützlich sein, wenn eine Reihe von Abhängigkeiten auf eine Version gesperrt werden muss.

Darüber hinaus sind folgende weitere Ziele vorgesehen:

Versionen:display-dependency-updates scannt die Abhängigkeiten eines Projekts und erstellt einen Bericht über die Abhängigkeiten mit neueren Versionen.
Versionen:Display-Plugin-Updates scannt die Plugins eines Projekts und erstellt einen Bericht über die Plugins mit neueren Versionen.
Versionen:Update-Parent Aktualisiert den übergeordneten Abschnitt eines Projekts so, dass es auf die neueste verfügbare Version verweist.Wenn Sie beispielsweise einen Corporate Root POM verwenden, kann dieses Ziel hilfreich sein, wenn Sie sicherstellen müssen, dass Sie die neueste Version des Corporate Root POM verwenden.
Versionen:Update-Untermodule Aktualisiert den übergeordneten Abschnitt der untergeordneten Module eines Projekts, sodass die Version mit der Version des aktuellen Projekts übereinstimmt.Wenn Sie beispielsweise über einen Aggregator -Pom verfügen, der auch die Eltern für die Projekte ist, die IT -Aggregate und die Kinder- und Elternversionen aus der Synchronisierung herausholen, kann dieses Mojo dazu beitragen, die Versionen der Kindermodule zu beheben.(Beachten Sie möglicherweise, dass Sie Maven mit der Option -n aufrufen müssen, um dieses Ziel auszuführen, wenn Ihr Projekt so schlecht gebrochen ist, dass es aufgrund der Version des Fehlanpasses nicht erstellt werden kann.)
Versionen:Lock-Snapshots Sucht das POM für alle Versionen -Snapshot -Versionen und ersetzt sie durch die aktuelle Zeitstempelversion dieses -snapshots, z. B.-20090327.172306-4
Versionen:Unlock-Snapshots Sucht den POM nach allen Zeitstempelsperrversionen und ersetzt sie durch -snapshot.
Versionen:Auflösungsbereiche Findet Abhängigkeiten mithilfe von Versionsbereichen und löst den Bereich für die verwendete Version auf.
Versionen:Use-Releases Sucht das POM für alle veröffentlichten Versionen, die veröffentlicht wurden, und ersetzt sie durch die entsprechende Versionsversion.
Versionen:use-next-releases Sucht den POM nach allen nicht-snapshot-Versionen, die eine neuere Version waren und sie durch die nächste Versionsversion ersetzt.
Versionen:Nächste-Versionen verwenden Sucht das POM nach allen Versionen, die eine neuere Version waren und sie durch die nächste Version ersetzt.
Versionen:Commit Entfernt die pom.xml.versionsBackup-Dateien.Bildet eine Hälfte des eingebauten "SCM des armen Mannes".
Versionen:Zurücksetzen stellt die pom.xml -Dateien aus den Dateien pom.xml.versionbackups wieder her.Bildet eine Hälfte des eingebauten "SCM des armen Mannes".

Ich dachte nur, ich würde es für jede zukünftige Referenz hinzufügen.

Bitte werfen Sie einen Blick darauf diese Seite (Abschnitt „Abhängigkeitsversionsbereiche“).Was Sie vielleicht tun möchten, ist so etwas wie

<version>[1.2.3,)</version>

Diese Versionsbereiche sind in Maven2 implementiert.

Im Gegensatz zu anderen denke ich, dass es dafür viele Gründe gibt Ich will immer das Neueste Ausführung.Vor allem, wenn Sie eine kontinuierliche Bereitstellung durchführen (wir haben manchmal etwa 5 Releases an einem Tag) und kein Projekt mit mehreren Modulen durchführen möchten.

Ich lasse Hudson/Jenkins für jeden Build Folgendes tun:

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

Das heißt, ich verwende das Versions-Plugin und das SCM-Plugin, um die Abhängigkeiten zu aktualisieren und sie dann in die Quellcodeverwaltung einzuchecken.Ja, ich lasse mein CI SCM-Checkins durchführen (was Sie für das Maven-Release-Plugin sowieso tun müssen).

Sie sollten das Versions-Plugin so einrichten, dass nur das aktualisiert wird, was Sie möchten:

        <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>

Ich verwende für die Freigabe das Release-Plugin, das sich um -SNAPSHOT kümmert und überprüft, ob es eine Release-Version von -SNAPSHOT gibt (was wichtig ist).

Wenn Sie das tun, was ich tue, erhalten Sie die neueste Version für alle Snapshot-Builds und die neueste Release-Version für Release-Builds.Ihre Builds werden auch reproduzierbar sein.

Aktualisieren

Mir sind einige Kommentare aufgefallen, in denen nach Einzelheiten dieses Arbeitsablaufs gefragt wurde.Ich möchte sagen, dass wir diese Methode nicht mehr verwenden und der Hauptgrund dafür ist, dass das Maven-Versions-Plugin fehlerhaft und im Allgemeinen von Natur aus fehlerhaft ist.

Es ist fehlerhaft, da zum Ausführen des Versions-Plugins zum Anpassen von Versionen alle vorhandenen Versionen vorhanden sein müssen, damit der POM ordnungsgemäß ausgeführt wird.Das heißt, das Versions-Plugin kann nicht auf die neueste Version aktualisieren, wenn es die im POM referenzierte Version nicht finden kann.Das ist eigentlich ziemlich ärgerlich, da wir aus Speicherplatzgründen oft alte Versionen bereinigen.

Eigentlich benötigen Sie ein separates Tool von Maven, um die Versionen anzupassen (damit Sie nicht darauf angewiesen sind, dass die POM-Datei korrekt ausgeführt wird).Ich habe ein solches Tool in der einfachen Sprache Bash geschrieben.Das Skript aktualisiert die Versionen wie das Versions-Plugin und checkt die POM wieder in die Quellcodeverwaltung ein.Es läuft außerdem etwa 100x schneller als das MVN-Versions-Plugin.Leider ist es nicht für den öffentlichen Gebrauch geschrieben, aber wenn die Leute Interesse haben, könnte ich es so machen und es in einen Gist oder Github packen.

Zurück zum Workflow, da in einigen Kommentaren gefragt wurde, was wir tun:

Wir haben etwa 20 Projekte in ihren eigenen Repositories mit ihren eigenen Jenkins-Jobs
Bei der Veröffentlichung wird das Maven-Release-Plugin verwendet.Der Arbeitsablauf hierfür ist in der Dokumentation des Plugins beschrieben.Das Maven-Release-Plugin ist irgendwie scheiße (und ich bin nett), aber es funktioniert.Eines Tages planen wir, diese Methode durch etwas Optimaleres zu ersetzen.
Wenn eines der Projekte veröffentlicht wird, führt Jenkins dann einen speziellen Job aus, den wir den Job „Alle Versionen aktualisieren“ nennen (woher Jenkins weiß, dass es sich um eine Veröffentlichung handelt, ist kompliziert, zum Teil weil das Maven-Jenkins-Release-Plugin auch ziemlich beschissen ist).
Der Job „Alle Versionen aktualisieren“ kennt alle 20 Projekte.Um genau zu sein, handelt es sich um einen Aggregator-POM mit allen Projekten im Modulabschnitt in der Abhängigkeitsreihenfolge.Jenkins führt unser magisches Groovy/Bash-Foo aus, das alle Projekte abruft, die Versionen auf die neueste Version aktualisiert und dann die Poms eincheckt (wiederum in Abhängigkeitsreihenfolge basierend auf dem Modulabschnitt).
Wenn sich das POM für jedes Projekt geändert hat (aufgrund einer Versionsänderung in einer Abhängigkeit), wird es eingecheckt und dann senden wir sofort einen Ping an Jenkins, um den entsprechenden Job für dieses Projekt auszuführen (dies dient dazu, die Build-Abhängigkeitsreihenfolge beizubehalten, andernfalls sind Sie der Gnade ausgeliefert). des SCM Poll-Planers).

Zum jetzigen Zeitpunkt bin ich der Meinung, dass es sowieso eine gute Sache ist, die Release- und Auto-Version als separates Tool von Ihrem allgemeinen Build zu haben.

Nun denken Sie vielleicht, dass Maven aufgrund der oben aufgeführten Probleme irgendwie scheiße ist, aber das wäre tatsächlich ziemlich schwierig mit einem Build-Tool, das keine deklarative, einfach zu analysierende Funktion hat Erweiterbar Syntax (auch bekannt als XML).

Tatsächlich fügen wir benutzerdefinierte XML-Attribute über Namespaces hinzu, um Bash-/Groovy-Skripte (z. B.Aktualisieren Sie diese Version nicht).

Die Abhängigkeitssyntax befindet sich im Anforderungsspezifikation für Abhängigkeitsversionen Dokumentation.Hier ist es der Vollständigkeit halber:

Abhängigkeiten' version Element definiert Versionsanforderungen und wird zur Berechnung der effektiven Abhängigkeitsversion verwendet.Versionsanforderungen haben die folgende Syntax:

1.0:„Weiche“ Anforderung für 1.0 (nur eine Empfehlung, wenn sie mit allen anderen Bereichen für die Abhängigkeit übereinstimmt)

[1.0]:„Harte“ Anforderung auf 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 oder x >= 1,2;Mehrere Sätze werden durch Kommas getrennt

(,1.1),(1.1,):Dies schließt 1.1 aus (zum Beispiel, wenn bekannt ist, dass es nicht in Kombination mit dieser Bibliothek funktioniert)

In Ihrem Fall könnten Sie so etwas tun <version>[1.2.3,)</version>

Sind Sie möglicherweise auf Entwicklungsversionen angewiesen, die sich während der Entwicklung offensichtlich stark ändern?

Anstatt die Version von Entwicklungsversionen zu erhöhen, können Sie einfach eine Snapshot-Version verwenden, die Sie bei Bedarf überschreiben. Dies bedeutet, dass Sie nicht bei jeder geringfügigen Änderung das Versions-Tag ändern müssen.So etwas wie 1.0-SNAPSHOT ...

Aber vielleicht versuchst du etwas anderes zu erreichen ;)

Wer LATEST verwendet, stellt bitte sicher, dass -U vorhanden ist, da sonst der neueste Snapshot nicht abgerufen wird.

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

Als diese Frage gestellt wurde, gab es einige Probleme mit den Versionsbereichen in Maven, diese wurden jedoch in neueren Versionen von Maven behoben.In diesem Artikel wird sehr gut beschrieben, wie Versionsbereiche funktionieren und welche Best Practices es gibt, um besser zu verstehen, wie Maven Versionen versteht: https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN8855

Die Wahrheit ist, dass es sogar in 3.x immer noch funktioniert, überraschenderweise werden die Projekte erstellt und bereitgestellt.Aber das Schlüsselwort LATEST/RELEASE verursacht überall Probleme in m2e und Eclipse, ALSO-Projekte hängen von der Abhängigkeit ab, die durch das Schlüsselwort LATEST/RELEASE bereitgestellt wird, die Version nicht erkennen.

Es verursacht auch Probleme, wenn Sie versuchen, die Version als Eigenschaft zu definieren und an anderer Stelle darauf zu verweisen.

Die Schlussfolgerung lautet also: Verwenden Sie das Versionen-Maven-Plugin Wenn du kannst.

Manchmal möchten Sie keine Versionsbereiche verwenden, da es den Anschein hat, dass sie Ihre Abhängigkeiten „langsam“ auflösen, insbesondere wenn Continuous Delivery vorhanden ist und es Unmengen von Versionen gibt – hauptsächlich während intensiver Entwicklung.

Eine Problemumgehung wäre die Verwendung von Versionen-Maven-Plugin.Sie können beispielsweise eine Eigenschaft deklarieren:

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

und fügen Sie das Versionen-Maven-Plugin zu Ihrer POM-Datei hinzu:

<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>

Um die Abhängigkeit zu aktualisieren, müssen Sie dann die folgenden Ziele ausführen:

mvn versions:update-properties validate

Wenn es eine neuere Version als 1.1.1 gibt, wird Folgendes angezeigt:

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

Wenn Sie möchten, dass Maven die neueste Version einer Abhängigkeit verwendet, können Sie diese verwenden Versionen des Maven-Plugins und wie man dieses Plugin verwendet, Tim hat bereits eine gute Antwort gegeben, folgen Sie seiner Antwort.

Aber als Entwickler werde ich diese Art von Vorgehensweise nicht empfehlen.WARUM?

Die Antwort auf das Warum ist bereits gegeben von Pascal Thivent im Kommentar der Frage

Ich empfehle diese Praxis (noch Verwendung von Versionsbereichen), um die Reproduzierbarkeit zu erstellen.Ein Build, der aus einem unbekannten Grund plötzlich fehlschlägt, ist viel nerviger, als eine Versionsnummer manuell zu aktualisieren.

Ich werde diese Art von Praxis empfehlen:

<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>

Es ist leicht zu warten und leicht zu debuggen.Sie können Ihr POM im Handumdrehen aktualisieren.

MEINE Lösung in Maven 3.5.4, verwende Nexus in Eclipse:

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

dann in Eclipse: atl + F5, und wählen Sie das aus force update of snapshots/release

Für mich geht das.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow