Aktualisieren der Versionsnummern von Modulen in einem Maven-Projekt mit mehreren Modulen

Lesezeit: 8 Minuten

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

<parent>
    <artifactId>xyz-application</artifactId>
    <groupId>com.xyz</groupId>
    <version>2.50.0.g</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId>com.xyz</groupId>
<artifactId>xyz-Library</artifactId>
<version>2.50.0.g</version>

und das übergeordnete Hauptmodul hat die folgende Konfiguration

<modelVersion>4.0.0</modelVersion>
<groupId>com.xyz</groupId>
<artifactId>xyz-application</artifactId>
<version>2.50.0.g</version>
<packaging>pom</packaging>

  • 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


Benutzer-Avatar
Sean Patrick Floyd

Benutzen versions:set von dem Versionen-Maven-Plugin:

mvn versions:set -DnewVersion=2.50.1-SNAPSHOT

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

    – Michael Laffargue

    28. April 2014 um 9:52 Uhr

  • Ein neues Plugin löst das in dieser Frage beschriebene Problem anders: mojo.codehaus.org/flatten-maven-plugin/examples/…

    – Stefan

    12. Juni 2014 um 14:51 Uhr

  • @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:

https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Project_Inheritance_vs_Project_Aggregation

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:

mvn versions:set -DnewVersion=2.50.1-SNAPSHOT -DprocessAllModules

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:

mvn versions:set -DnewVersion=2.50.1-SNAPSHOT -DprocessAllModules -DgenerateBackupPoms=false

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

mvn build-helper:parse-version versions:set -DnewVersion=\${parsedVersion.majorVersion}.\${parsedVersion.minorVersion}.\${parsedVersion.nextIncrementalVersion} versions:commit

  • Danke, @Crummy, du hast meinen Tag gerettet

    – Maksim Kostromin

    30. Januar 2019 um 17:52 Uhr

  • mojohaus.org/build-helper-maven-plugin/parse-version-mojo.html

    – Siehe Lied

    1. Februar 2019 um 2:44 Uhr

  • Oder Sie können verwenden -DoldVersion='*'

    – Matthäus Wise

    23. Mai 2019 um 16:09 Uhr

  • 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

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

mvn versions:set -DnewVersion=1.2.3-SNAPSHOT

Benutzer-Avatar
khmarbaise

Ich ermutige Sie, die zu lesen Maven Buch über Multi-Modul (Reaktor) baut.

Ich meinte insbesondere folgendes:

<parent>
    <artifactId>xyz-application</artifactId>
    <groupId>com.xyz</groupId>
    <version>2.50.0.g</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId>com.xyz</groupId>
<artifactId>xyz-Library</artifactId>
<version>2.50.0.g</version>

geändert werden soll. Achten Sie hier auf die nicht definierte Version, nur im übergeordneten Teil ist sie definiert.

<modelVersion>4.0.0</modelVersion>

<parent>
    <artifactId>xyz-application</artifactId>
    <groupId>com.xyz</groupId>
    <version>2.50.0.g</version>
</parent>
<groupId>com.xyz</groupId>
<artifactId>xyz-Library</artifactId>

Das ist eine bessere Verbindung.

  • 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

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

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

1014580cookie-checkAktualisieren der Versionsnummern von Modulen in einem Maven-Projekt mit mehreren Modulen

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

Privacy policy