Manchmal möchte man keine Versionsbereiche verwenden, weil es den Anschein hat, dass sie "langsam" sind, um Ihre Abhängigkeiten aufzulösen, besonders wenn es eine kontinuierliche Bereitstellung gibt und es tonnenweise Versionen gibt - hauptsächlich während der intensiven Entwicklung.
Eine Umgehung wäre die Verwendung der versions-maven-plugin . Sie können zum Beispiel eine Eigenschaft deklarieren:
<properties>
<myname.version>1.1.1</myname.version>
</properties>
und fügen Sie das versions-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 Ziele ausführen:
mvn versions:update-properties validate
Wenn es eine neuere Version als 1.1.1 gibt, wird Ihnen das angezeigt:
[INFO] Updated ${myname.version} from 1.1.1 to 1.3.2
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).