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.
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.
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).
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)
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
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
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
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:
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:
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:
We have 20 or so projects in their own repositories with their own jenkins jobs
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.
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).
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).
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).
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>
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 😉
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
9633600cookie-checkWie sage ich Maven, dass er die neueste Version einer Abhängigkeit verwenden soll?yes
@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