Wie sage ich Maven, dass er die neueste Version einer Abhängigkeit verwenden soll?

Lesezeit: 14 Minuten

Wie sage ich Maven dass er die neueste Version einer
Anders Sandvig

In Maven werden Abhängigkeiten normalerweise so eingerichtet:

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

Wenn Sie nun mit Bibliotheken arbeiten, die häufig veröffentlicht werden, kann das ständige Aktualisieren des -Tags etwas lästig sein. Gibt es eine Möglichkeit, Maven anzuweisen, immer die neueste verfügbare Version (aus dem Repository) zu verwenden?

  • @Martin Mir ist die xyz-SNAPSHOT-Konvention bekannt, aber ich habe über Bibliotheken nachgedacht, die in endgültigen Versionen im Repository veröffentlicht werden (dh von dream-library-1.2.3.jar zu dream-library-1.2.4.jar wechseln , und so weiter).

    – Anders Sandvig

    27. August 2008 um 16:50 Uhr

  • Ich empfehle diese Vorgehensweise (noch die Verwendung von Versionsbereichen) aus Gründen der Build-Reproduzierbarkeit wirklich nicht. Ein Build, der aus einem unbekannten Grund plötzlich fehlschlägt, ist viel ärgerlicher als das manuelle Aktualisieren einer Versionsnummer.

    – Pascal Thivent

    17. September 2009 um 22:52 Uhr

  • @PascalThivent Das manuelle Aktualisieren einer Veröffentlichungsnummer in einem Pom ist ein Problem, wenn Sie kontinuierliche Veröffentlichungen durchführen. Ich verwende das Versions-Plugin in Kombination mit dem SCM-Plugin, um dies zu umgehen (siehe meine Antwort).

    – Adam Gent

    9. Januar 2012 um 21:24 Uhr

  • @PascalThivent Beides nervt, aber auf unterschiedliche Weise. Ich möchte abhängig von meiner Situation zwischen beiden wählen und nicht gezwungen sein, eines zu verwenden, weil jemand anderes entschieden hat, dass dieses besser ist.

    – Tortenspiele

    2. Februar 2018 um 20:07 Uhr

  • Die Guava-Bibliothek ist ein gutes Beispiel für die neueste Version, bei der Klassen aus früheren Versionen entfernt wurden, wodurch der Build unterbrochen wird. Die Denkweise von Maven ist, dass jede neuere Version jede frühere ersetzen kann, was in der Praxis nicht gilt.

    – Thorbjørn Ravn Andersen

    25. November 2020 um 9:19 Uhr

Wie sage ich Maven dass er die neueste Version einer
Reicher Verkäufer

HINWEIS:

Das Erwähnte LATEST und RELEASE Metaversionen wurden fallen gelassen für Plugin-Abhängigkeiten in Maven 3 “im Interesse reproduzierbarer Builds”, vor über 6 Jahren. (Sie funktionieren immer noch einwandfrei für reguläre Abhängigkeiten.) Für Plugin-Abhängigkeiten lesen Sie bitte dies Maven 3-kompatible Lösung.


Wenn Sie immer die neueste Version verwenden möchten, bietet Maven 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 Plug-in 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 Methode, Software zu entwerfen, die von einer unspezifischen Version eines Artefakts abhängt. Wenn Sie Software entwickeln, möchten Sie möglicherweise 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 freigeben, 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 beeinflusst wird, die nicht unter Ihrer Kontrolle steht. Verwenden Sie LATEST und RELEASE mit Vorsicht, wenn überhaupt.

Siehe die POM-Syntax-Abschnitt des Maven-Buchs für mehr Details. Oder sehen Sie sich dieses Dokument an Abhängigkeitsversionsbereichewo:

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

Hier ist ein Beispiel, das die verschiedenen Optionen veranschaulicht. Im Maven-Repository hat com.foo:my-foo 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 (other Versionsbereiche können natürlich angegeben werden, zeigen Sie hier nur die relevanten):

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

<version>[1.0.1]</version>

Deklarieren Sie eine explizite Version (wird immer zu 1.0.1 aufgelöst, es sei denn, es tritt eine Kollision auf, wenn Maven eine passende Version auswählt):

<version>1.0.1</version>

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

[1.0.0,2.0.0)</version>

Declare an open-ended version range (will resolve to 2.0.0):

<version>[1.0.0,)</version>

Declare the version as LATEST (will resolve to 2.0.0) (removed from maven 3.x)

<version>LATEST</version>

Declare the version as RELEASE (will resolve to 1.1.1) (removed from maven 3.x):

<version>RELEASE</version>

Note that by default your own deployments will update the “latest” entry in the Maven metadata, but to update the “release” entry, you need to activate the “release-profile” from the Maven super POM. You can do this with either “-Prelease-profile” or “-DperformRelease=true”


It’s worth emphasising that any approach that allows Maven to pick the dependency versions (LATEST, RELEASE, and version ranges) can leave you open to build time issues, as later versions can have different behaviour (for example the dependency plugin has previously switched a default value from true to false, with confusing results).

It is therefore generally a good idea to define exact versions in releases. As Tim’s answer points out, the maven-versions-plugin is a handy tool for updating dependency versions, particularly the versions:use-latest-versions and versions:use-latest-releases goals.

  • I think that LATEST/RELEASE is very important for plugins which provide deploy functionality. For example we use plugin which deploy new version of artifacts to the our servers. If servers will change we release new version of plugin and all projects that use this plugin must by manually updated to use new version of deploy plugin.

    – ATom

    Aug 17, 2012 at 14:09

  • @RichSeller hey Rich; I spent a bit of time on this before I figured out this is not available in Maven 3.0 anymore 😉 Would you consider editing the answer so it starts with an update stating the Maven 3.0 depreaction? Thanks a bunch!

    – Miquel

    Nov 29, 2013 at 15:48

  • I believe a good balance would be to lock the major version but get the latest minor (or patch) version (whichever is used for bug-fixes only in the artifcat you are depending on). With the current syntax this appears to be only possible with a range like (note: starts with brackets and ends with parens): [1.1,2.0)

    – Amr Mostafa

    Aug 4, 2014 at 22:15


  • FWIW… updated link to Maven3 Compatibility Notes: cwiki.apache.org/confluence/display/MAVEN/…

    – dyodji

    May 4, 2015 at 21:17

  • Worth to note that [1.0.0, 2.0.0] Der Bereich umfasst nicht 1.0-SNAPSHOT, aber 2.0-SNAPSHOT.

    – klatschen

    26. Januar 2017 um 22:53 Uhr

1646632633 917 Wie sage ich Maven dass er die neueste Version einer
Tim

Jetzt weiß ich, dass dieses Thema alt ist, aber wenn ich die Frage und die vom OP gelieferte Antwort lese, scheint es das zu sein Maven-Versions-Plugin wäre eigentlich eine bessere Antwort auf seine Frage gewesen:

Insbesondere die folgenden Ziele könnten von Nutzen sein:

  • Versionen:neueste-Versionen verwenden durchsucht das pom nach allen Versionen, die eine neuere Version waren, und ersetzt sie durch die neueste Version.
  • Versionen: Verwenden Sie die neuesten Versionen durchsucht das pom nach allen Nicht-SNAPSHOT-Versionen, die eine neuere Version waren, und ersetzt sie durch die neueste Release-Version.
  • Versionen: Update-Eigenschaften aktualisiert die in einem Projekt definierten Eigenschaften, sodass sie der neuesten verfügbaren Version bestimmter Abhängigkeiten entsprechen. Dies kann nützlich sein, wenn eine Reihe von Abhängigkeiten alle auf eine Version beschränkt werden müssen.

Folgende weitere Ziele sind ebenfalls vorgesehen:

  • Versionen: Display-Abhängigkeits-Updates scannt die Abhängigkeiten eines Projekts und erstellt einen Bericht über die Abhängigkeiten, für die neuere Versionen verfügbar sind.
  • Versionen: Display-Plugin-Updates scannt die Plugins eines Projekts und erstellt einen Bericht über die Plugins, für die neuere Versionen verfügbar sind.
  • Versionen: update-parent aktualisiert den übergeordneten Abschnitt eines Projekts, sodass er auf die neueste verfügbare Version verweist. Wenn Sie beispielsweise ein Unternehmens-Root-POM verwenden, kann dieses Ziel hilfreich sein, wenn Sie sicherstellen müssen, dass Sie die neueste Version des Unternehmens-Root-POM verwenden.
  • Versionen: Update-Kind-Module aktualisiert den übergeordneten Abschnitt der untergeordneten Module eines Projekts, sodass die Version mit der Version des aktuellen Projekts übereinstimmt. Wenn Sie beispielsweise ein Aggregator-Pom haben, das auch das übergeordnete Element für die Projekte ist, die es aggregiert, und die untergeordneten und übergeordneten Versionen nicht mehr synchron sind, kann dieses Mojo helfen, die Versionen der untergeordneten Module zu korrigieren. (Beachten Sie, dass Sie Maven möglicherweise mit der Option -N aufrufen müssen, um dieses Ziel auszuführen, wenn Ihr Projekt so stark beschädigt ist, dass es aufgrund der nicht übereinstimmenden Version nicht erstellt werden kann).
  • Versionen: Lock-Schnappschüsse durchsucht das pom nach allen -SNAPSHOT-Versionen und ersetzt sie durch die aktuelle Zeitstempelversion dieses -SNAPSHOT, zB -20090327.172306-4
  • Versionen:Unlock-Snapshots durchsucht das pom nach allen Snapshot-Versionen mit Zeitstempel und ersetzt sie durch -SNAPSHOT.
  • Versionen:Auflösungsbereiche findet Abhängigkeiten anhand von Versionsbereichen und löst den Bereich in die spezifische Version auf, die verwendet wird.
  • Versionen:Verwendungsfreigaben durchsucht den pom nach allen veröffentlichten -SNAPSHOT-Versionen und ersetzt sie durch die entsprechende Release-Version.
  • Versionen:Nächste-Releases verwenden durchsucht den Pom nach allen Nicht-SNAPSHOT-Versionen, die eine neuere Version waren, und ersetzt sie durch die nächste Release-Version.
  • Versionen:Nächste-Versionen verwenden durchsucht das pom nach allen Versionen, die eine neuere Version waren, und ersetzt sie durch die nächste Version.
  • Versionen: Commit entfernt die pom.xml.versionsBackup-Dateien. Bildet die eine Hälfte des eingebauten “Poor Man’s SCM”.
  • Versionen: zurücksetzen stellt die pom.xml-Dateien aus den pom.xml.versionsBackup-Dateien wieder her. Bildet die eine Hälfte des eingebauten “Poor Man’s SCM”.

Ich dachte nur, ich würde es für zukünftige Referenzen aufnehmen.

  • Was ist in diesem Zusammenhang der Unterschied zwischen “Release” und “Version”.

    – Ben Noland

    23. Dezember 2012 um 15:39 Uhr

  • @BenNoland, ich glaube, der Unterschied in diesem Fall besteht darin, dass die nächste Version möglicherweise kein Release-Artefakt sein muss. Wenn beispielsweise ein Artefakt mit den Versionen 1.0.0-SNAPSHOT, 1.0.0 und 1.0.1-SNAPSHOT und ein Pom-Verweis auf 1.0.0-SNAPSHOT gegeben sind, werden Versionen:Nächste-Versionen und Versionen:Nächste-Versionen zu 1.0.0 aufgelöst , wohingegen Versionen:Neueste-Versionen und Versionen:Neueste-Versionen jeweils in 1.0.1-SNAPSHOT und 1.0.0 aufgelöst werden.

    – Ryan Beesley

    17. Juni 2014 um 19:14 Uhr

  • Das Drucken aller möglichen und nicht zusammenhängenden Ziele ist nicht hilfreich.

    – MariuszS

    25. August 2015 um 9:53 Uhr

  • Was ich suche, ist etwas, das das Gegenteil von Versionen macht: Auflösungsbereiche. Ich habe ein Pom, das gelöst wurde und das ich wieder für neuere Versionen öffnen möchte (dh von 1.2.3-4 zu wechseln[1.2,)</version>.

    – fmpdmb

    Feb 25, 2016 at 20:23

  • I would think versions:use-latest-versions solves most of the OP’s problems.

    – Alex R

    May 31, 2018 at 0:07

1646632634 231 Wie sage ich Maven dass er die neueste Version einer
Martin Klinke

Please take a look at this page (section “Dependency Version Ranges”). What you might want to do is something like

<version>[1.2.3,)</version>

These version ranges are implemented in Maven2.

  • You may want to have a closer look at how Maven compare version numbers – if you do not conform to a strict pattern Maven compares as strings and not numbers.

    – Thorbjørn Ravn Andersen

    Feb 25, 2013 at 13:19

  • That page is on Codehaus, and describes itself as things “that have not yet been implemented for Maven 2.0″… The Maven documentation itself doesn’t say anything about version ranges. Am I missing something? When were version ranges introduced? Where are they described in the official documentation?

    – Shannon

    Aug 1, 2014 at 21:37

  • You are wrong, version range means that all versions are OK from 1.2.3 to higher. This is not the latest version at all.

    – MariuszS

    Aug 24, 2015 at 7:43

1646632635 738 Wie sage ich Maven dass er die neueste Version einer
Adam Gent

Unlike others I think there are many reasons why you might always want the latest version. Particularly if you are doing continuous deployment (we sometimes have like 5 releases in a day) and don’t want to do a multi-module project.

What I do is make Hudson/Jenkins do the following for every build:

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

That is I use the versions plugin and scm plugin to update the dependencies and then check it in to source control. Yes I let my CI do SCM checkins (which you have to do anyway for the maven release plugin).

You’ll want to setup the versions plugin to only update what you want:

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

I use the release plugin to do the release which takes care of -SNAPSHOT and validates that there is a release version of -SNAPSHOT (which is important).

If you do what I do you will get the latest version for all snapshot builds and the latest release version for release builds. Your builds will also be reproducible.

Update

I noticed some comments asking some specifics of this workflow. I will say we don’t use this method anymore and the big reason why is the maven versions plugin is buggy and in general is inherently flawed.

It is flawed because to run the versions plugin to adjust versions all the existing versions need to exist for the pom to run correctly. That is the versions plugin cannot update to the latest version of anything if it can’t find the version referenced in the pom. This is actually rather annoying as we often cleanup old versions for disk space reasons.

Really you need a separate tool from maven to adjust the versions (so you don’t depend on the pom file to run correctly). I have written such a tool in the the lowly language that is Bash. The script will update the versions like the version plugin and check the pom back into source control. It also runs like 100x faster than the mvn versions plugin. Unfortunately it isn’t written in a manner for public usage but if people are interested I could make it so and put it in a gist or github.

Going back to workflow as some comments asked about that this is what we do:

  1. We have 20 or so projects in their own repositories with their own jenkins jobs
  2. When we release the maven release plugin is used. The workflow of that is covered in the plugin’s documentation. The maven release plugin sort of sucks (and I’m being kind) but it does work. One day we plan on replacing this method with something more optimal.
  3. When one of the projects gets released jenkins then runs a special job we will call the update all versions job (how jenkins knows its a release is a complicated manner in part because the maven jenkins release plugin is pretty crappy as well).
  4. The update all versions job knows about all the 20 projects. It is actually an aggregator pom to be specific with all the projects in the modules section in dependency order. Jenkins runs our magic groovy/bash foo that will pull all the projects update the versions to the latest and then checkin the poms (again done in dependency order based on the modules section).
  5. For each project if the pom has changed (because of a version change in some dependency) it is checked in and then we immediately ping jenkins to run the corresponding job for that project (this is to preserve build dependency order otherwise you are at the mercy of the SCM Poll scheduler).

At this point I’m of the opinion it is a good thing to have the release and auto version a separate tool from your general build anyway.

Now you might think maven sort of sucks because of the problems listed above but this actually would be fairly difficult with a build tool that does not have a declarative easy to parse extendable syntax (aka XML).

In fact we add custom XML attributes through namespaces to help hint bash/groovy scripts (e.g. don’t update this version).

The dependencies syntax is located at the Dependency Version Requirement Specification documentation. Here it is is for completeness:

Dependencies’ version element define version requirements, used to compute effective dependency version. Version requirements have the following syntax:

  • 1.0: “Soft” requirement on 1.0 (just a recommendation, if it matches all other ranges for the dependency)
  • [1.0]: “Hard”-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 or x >= 1.2; multiple sets are comma-separated
  • (,1.1),(1.1,): this excludes 1.1 (for example if it is known not to
    work in combination with this library)

In your case, you could do something like <version>[1.2.3,)</version>

1646632634 231 Wie sage ich Maven dass er die neueste Version einer
Martin Klinke

Are you possibly depending on development versions that obviously change a lot during development?

Instead of incrementing the version of development releases, you could just use a snapshot version that you overwrite when necessary, which means you wouldn’t have to change the version tag on every minor change. Something like 1.0-SNAPSHOT…

But maybe you are trying to achieve something else 😉

1646632636 813 Wie sage ich Maven dass er die neueste Version einer
trung

Who ever is using LATEST, please make sure you have -U otherwise the latest snapshot won’t be pulled.

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

  • This does not pulls latest snapshot from local m2 repo

    – c.sankhala

    Feb 12, 2021 at 9:42

963360cookie-checkWie sage ich Maven, dass er die neueste Version einer Abhängigkeit verwenden soll?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy