Aktualisieren der Versionsnummern von Modulen in einem Maven-Projekt mit mehreren Modulen
Lesezeit: 8 Minuten
sandeepkunkunuru
Ich habe ein Maven-Projekt mit mehreren Modulen. Wir beabsichtigen, alle diese Module zusammen zu versionieren. Aber ab sofort habe ich die hartkodierte Version in jedem Modul pom.xml wie unten
Ihre Frage ist falsch formuliert und verwirrt Personen, die echte POMs mit mehreren Modulen (“aggregiert”) haben. Aus Ihrem Beispiel und den Antworten geht hervor, dass Sie wirklich von einem übergeordneten POM sprechen, nicht von einem aggregierten POM mit mehreren Modulen. Sehen maven.apache.org/pom.html#Aggregation .
Es passt alle Pom-Versionen, Elternversionen und Abhängigkeitsversionen in einem Projekt mit mehreren Modulen an.
Wenn Sie einen Fehler gemacht haben, tun Sie es
mvn versions:revert
danach, bzw
mvn versions:commit
wenn Sie mit den Ergebnissen zufrieden sind.
Hinweis: Diese Lösung geht davon aus, dass alle Module das Aggregat-Pom auch als übergeordnetes Pom verwenden, ein Szenario, das zum Zeitpunkt dieser Antwort als Standard galt. Wenn dies nicht der Fall ist, gehen Sie zu Garret Wilsons Antwort.
Es wäre großartig gewesen, wenn es eine Lösung gäbe, bei der Sie nicht jedes Modul tatsächlich ändern müssen. Die einzige Alternative, die mir einfällt, ist, immer eine Snapshot-Version für das Eltern-Pom zu verwenden.
– AmanicA
2. Juli 2011 um 21:49 Uhr
Zusätzlich zu den versions:set kann man angeben -DgenerateBackupPoms=falseda dieses Plugin standardmäßig Original-POM-Dateien sichert.
– Maksim Sorokin
15. November 2012 um 8:49 Uhr
Das ist der Sinn der versions:commit : “Entfernt die ursprüngliche Sicherung des pom und akzeptiert dadurch die Änderungen.”
@MichaelLaffargue mvn versions:commit scheint die Sicherungsdateien zu entfernen, die von der vorherigen pom.xml generiert wurden
– Cris Rockwell
30. August 2015 um 17:39 Uhr
Die gegebene Antwort geht davon aus, dass das betreffende Projekt zusätzlich zur Modulaggregation die Projektvererbung verwendet. Tatsächlich sind dies unterschiedliche Konzepte:
Einige Projekte können eine Aggregation von Modulen sein, haben jedoch keine Eltern-Kind-Beziehung zwischen Aggregator-POM und den aggregierten Modulen. (Möglicherweise besteht überhaupt keine Eltern-Kind-Beziehung, oder die untergeordneten Module verwenden möglicherweise insgesamt ein separates POM als “Eltern”.) In diesen Situationen funktioniert die gegebene Antwort nicht.
Nach viel Lesen und Experimentieren stellt sich heraus, dass es eine Möglichkeit gibt, die zu verwenden Versionen des Maven-Plugins nicht nur das Aggregator-POM, sondern auch alle aggregierten Module zu aktualisieren; es ist der processAllModules Möglichkeit. Der folgende Befehl muss im Verzeichnis des Aggregator-Projekts ausgeführt werden:
Das Versions Maven Plugin aktualisiert nicht nur die Versionen aller enthaltenen Module, es aktualisiert auch die Abhängigkeiten zwischen den Modulen!!!! Dies ist ein großer Gewinn und wird viel Zeit sparen und alle möglichen Probleme vermeiden.
Vergessen Sie natürlich nicht, die Änderungen in allen Modulen zu committen, was Sie auch mit demselben Schalter tun können:
mvn versions:commit -DprocessAllModules
Sie können sich entscheiden, ganz auf das Backup-POMS zu verzichten und alles in einem Befehl zu erledigen:
Wie automatisieren wir die nächste Version ebenso wie das Build-Helper-Plugin?
– Übersetzungsverlust
14. September 2018 um 6:52 Uhr
Mit Maven 3.5.0 kann ich das nicht zum Laufen bringen. Ich habe eine Projektaggregation und nur der übergeordnete Pom wurde aktualisiert. Ich habe auch die Projektvererbung ausprobiert (zusammen mit der Aggregation – “alle drei Regeln” aus dem bereitgestellten Link), und wieder wurde nur das übergeordnete Pom aktualisiert.
– SiKing
17. Mai 2019 um 18:24 Uhr
Den geheimen Make-it-Work-Schalter gefunden: Die Startversion des übergeordneten Pom und der Module muss gleich sein! Mein übergeordneter Pom begann mit “1-SNAPSHOT” und die Module hatten “1.0.0-SNAPSHOT”. 🙂
– SiKing
17. Mai 2019 um 19:13 Uhr
Bei einem Aggregator-Projekt reichen die Version des Aggregators und die Versionen der Submodule aus nicht müssen gleich sein. (z. B. Ihr Aggregator-Pom kann sich nur selten ändern und auf einer bestimmten Version bleiben, während einzelne Submodule ihre eigenen Release-Zyklen haben können). Die Schlüsseleigenschaft, die für angegeben werden soll versions:set Plugin ist -DoldVersion='*'An mojohaus.org/versions-maven-plugin/set-mojo.html Es besagt ausdrücklich, dass diese Eigenschaft bei der Verarbeitung eines Aggregatorprojekts angegeben werden sollte.
– Matthäus Wise
23. Mai 2019 um 16:08 Uhr
Unter welchen Bedingungen tut -DprocessAllModules eigentlich funktionieren? Es funktioniert nicht für mich.
– Alex R
23. Juni 2019 um 17:59 Uhr
Wenn Sie den Vorgang vollständig automatisieren möchten (dh Sie möchten die Versionsnummer erhöhen, ohne die aktuelle Versionsnummer kennen zu müssen), können Sie dies tun:
Cool, danke!! Beispiel mit SNAPSHOT: mvn build-helper:parse-version versions:set -DnewVersion=\${parsedVersion.majorVersion}.\${parsedVersion.minorVersion}.\${parsedVersion.nextIncrementalVersion}-SNAPSHOT versions:commit
– oikonomopo
22. Oktober 2020 um 15:15 Uhr
Nishant
Vielleicht möchten Sie sich die Maven-Release-Plugins ansehen release:update-versionen Tor. Es aktualisiert die übergeordnete Version sowie alle darunter liegenden Module.
Update: Bitte beachten Sie, dass das obige das Release-Plugin ist. Wenn Sie nicht freigeben, möchten Sie vielleicht verwenden versions:set
+1 für das Aufrufen der richtigen Formatierung für pom.xml Dateien, aber ich stimme zu (mit @ThorbjørnRavnAndersen), dass es übertrieben ist, ein ganzes Buch für diese Informationen zu lesen. :p
– Priidu Neemre
27. Januar 2016 um 9:09 Uhr
Leider entlastet das Vererben von Versionsinformationen vom übergeordneten Element nicht die Last, Änderungen vornehmen zu müssen alle pom-Dateien im Projekt – weil sie alle auf das übergeordnete Element verweisen Ausführung Anzahl.
– Steven der Leicht Amüsierte
5. August 2016 um 21:41 Uhr
Sie könnten Versionen-Maven-Plugin verwenden, das all diese Dinge handhabt, oder Sie können das Maven-Release-Plugin verwenden, sodass Sie dies nicht manuell handhaben müssen …
– khmarbaise
6. August 2016 um 9:45 Uhr
Es verwirrt mich immer noch, dass die Leute hier immer noch Links hinterlassen, ohne dass der Link jemals abläuft. Dies macht diese Antwort im Wesentlichen nutzlos.
– TheRealChx101
28. Juni 2021 um 8:39 Uhr
Yu Jiao
Der beste Weg ist, da Sie beabsichtigen, Ihre Module zu bündeln, können Sie angeben <dependencyManagement> Tag in den äußersten pom.xml (Elternmodul) direkt darunter <project> Schild. Es steuert die Version und den Gruppennamen. In Ihrem individuellen Modul müssen Sie nur die angeben <artifactId> tag in deinem pom.xml. Es wird die Version aus der übergeordneten Datei übernommen.
und was genau suchen?
– Thorbjørn Ravn Andersen
3. Januar 2013 um 15:56 Uhr
+1 für das Aufrufen der richtigen Formatierung für pom.xml Dateien, aber ich stimme zu (mit @ThorbjørnRavnAndersen), dass es übertrieben ist, ein ganzes Buch für diese Informationen zu lesen. :p
– Priidu Neemre
27. Januar 2016 um 9:09 Uhr
Leider entlastet das Vererben von Versionsinformationen vom übergeordneten Element nicht die Last, Änderungen vornehmen zu müssen alle pom-Dateien im Projekt – weil sie alle auf das übergeordnete Element verweisen Ausführung Anzahl.
– Steven der Leicht Amüsierte
5. August 2016 um 21:41 Uhr
Sie könnten Versionen-Maven-Plugin verwenden, das all diese Dinge handhabt, oder Sie können das Maven-Release-Plugin verwenden, sodass Sie dies nicht manuell handhaben müssen …
– khmarbaise
6. August 2016 um 9:45 Uhr
Es verwirrt mich immer noch, dass die Leute hier immer noch Links hinterlassen, ohne dass der Link jemals abläuft. Dies macht diese Antwort im Wesentlichen nutzlos.
– TheRealChx101
28. Juni 2021 um 8:39 Uhr
Buhake Sindi
versions:update-child-modules klingt nach dem, was du suchst. Sie könnten Versionen:set wie erwähnt ausführen, aber dies ist eine einfache Möglichkeit, die übergeordneten Versionsnummern zu aktualisieren. Für die untergeordneten Module sollten Sie meiner Meinung nach die entfernen <version> Definitionen, da sie die Versionsnummer des übergeordneten Moduls erben.
Ist es ein guter Ansatz, untergeordnete Module die Version eines übergeordneten Moduls erben zu lassen? Was ist, wenn sich nur die untergeordneten Module ändern?
– TheRealChx101
28. Juni 2021 um 8:32 Uhr
Dies setzt voraus, dass das Root-Modul das übergeordnete Modul ist, was nicht der Fall sein muss.
– Blechmann
10. Februar um 3:01 Uhr
10145800cookie-checkAktualisieren der Versionsnummern von Modulen in einem Maven-Projekt mit mehreren Modulenyes
Ihre Frage ist falsch formuliert und verwirrt Personen, die echte POMs mit mehreren Modulen (“aggregiert”) haben. Aus Ihrem Beispiel und den Antworten geht hervor, dass Sie wirklich von einem übergeordneten POM sprechen, nicht von einem aggregierten POM mit mehreren Modulen. Sehen maven.apache.org/pom.html#Aggregation .
– Garret Wilson
16. Dezember 2016 um 17:05 Uhr