Wenn Sie möchten, dass Maven die neueste Version einer Abhängigkeit verwendet, dann können Sie Versions Maven Plugin und wie man dieses Plugin verwendet, hat Tim bereits eine gute Antwort gegeben, folgen Sie seinem Antwort .
Aber als Entwickler werde ich diese Art von Praktiken nicht empfehlen. WARUM?
Die Antwort auf die Frage nach dem Warum ist bereits gegeben durch Pascal Thivent im Kommentar zur Frage
Ich empfehle diese Praxis (und die Verwendung von Versionsbereichen) nicht für um der Reproduzierbarkeit des Builds willen. Ein Build, der plötzlich anfängt zu aus einem unbekannten Grund fehlschlägt, ist weitaus ärgerlicher als das manuelle Aktualisieren einer Versionsnummer.
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 einfach zu pflegen und leicht zu debuggen. Sie können Ihr POM im Handumdrehen aktualisieren.
227 Stimmen
Ich empfehle diese Praxis (ebenso wie die Verwendung von Versionsbereichen) nicht, um die Reproduzierbarkeit der Builds zu gewährleisten. Ein Build, der plötzlich aus einem unbekannten Grund fehlschlägt, ist viel ärgerlicher als die manuelle Aktualisierung einer Versionsnummer.
17 Stimmen
@PascalThivent Manuelles Aktualisieren einer Versionsnummer in einem pom ist ein Schmerz, wenn Sie kontinuierliche Releases tun. Ich verwende das versions-Plugin in Kombination mit dem scm-Plugin, um dies zu umgehen (siehe meine Antwort).
5 Stimmen
@PascalThivent Beide sind ärgerlich, aber auf unterschiedliche Weise. Ich möchte je nach Situation zwischen beiden wählen können und nicht gezwungen werden, eines zu benutzen, weil jemand anderes entschieden hat, dass dieses besser ist.
0 Stimmen
Die Guava-Bibliothek ist ein gutes Beispiel dafür, dass in der neuesten Version Klassen aus früheren Versionen entfernt wurden, was zu einem Bruch im Build führt. Die Maven-Mentalität besagt, dass jede neuere Version jede frühere ersetzen kann, was in der Praxis nicht zutrifft.
0 Stimmen
@Martin Ich bin mir der x.y.z-SNAPSHOT-Konvention bewusst, aber ich dachte an Bibliotheken, die in endgültigen Versionen für das Repository freigegeben werden (d.h. von dream-library-1.2.3.jar zu dream-library-1.2.4.jar, und so weiter).