Hierarchie von Maven-Projekten ohne Streuung der Versionsnummer

Question

Wenn Sie Maven2 als Build-System für ein Projekt verwenden, das viele Artefakte mit derselben Versionsnummer enthält, haben Sie die Version des resultierenden Builds in pom.xml verteilt. In vielen von ihnen sogar zweimal - in der Version des Artefakts selbst und in der Version des Elternteils. Daher müssen Sie alle Versionen von pom.xml auf jedem Versions-Switch ändern und einchecken. Das ist etwas nervig, besonders wenn man mehrere Bugfixes und eine Entwicklungsversion parallel programmieren muss. Gibt es einen Weg dahin?

CLARIFICATION: Meine Frage bezieht sich auf die vielen Versionen jeder einzelnen pom.xml, die Sie im Laufe der Zeit in Ihrem Quellcodeverwaltungssystem erhalten, die sich nur durch die Versionsnummer der Pom und/oder der Versionsnummer des Elternpom unterscheiden. Idealerweise sollten Sie den Pom nur ändern müssen, wenn Sie eine Abhängigkeit oder etwas hinzufügen.

Zum Beispiel hast du ein Projekt mit den Artefakten foo-pom (das Eltern-Pom zu allen), Foobar-jar, foobaz-jar und foo-war. In der ersten Version ist die Version 1.0 - die in jeder pom.xml erscheint. In der zweiten Version ist die Version 1.1 - die wiederum in jeder pom.xml erscheint. Du musst also jede pom.xml ändern - das nervt, wenn du so oft veröffentlichst wie du solltest.

AKTUALISIERUNG: Wenn Sie das für wichtig halten: die Angabe der Elternversion wird nicht in Erwägung gezogen. Bitte gehen Sie auf die maven JIRA issue und stimmen Sie dafür ab, damit es besser bemerkt wird und eher als Erweiterung in einer kommenden Version hinzugefügt wird. Sie müssen dafür ein JIRA-Login erstellen/haben.

Es gibt another Stackoverflow Question, die im Grunde über das gleiche Problem ist.

Answer 1

Es gibt another StackOverflow thread that also covers this topic that you might want to look at.

Kurz gesagt, müssen nicht die übergeordnete Version angeben, wenn Vererbung 10 verwendet wird, um es besser bemerkt und eher als eine Erweiterung in einer bevorstehenden Version hinzugefügt werden.

Answer 2

Auf meinem Projekt habe ich ein solches Problem. Zur Verringerung der Anzahl der Versionen, die ich in meiner Eltern definieren pom.xml einige Eigenschaften, die sich auf die Versionen der einzelnen Module entsprechen:

<properties> 
    <project-version>1.0.0</project-version> 
    <!-- Same version than the parent for the module 'commons' --> 
    <project-commons-version>${project-version}</project-commons-version> 
    <!-- A specific version for the 'business' module --> 
    <project-business-version>1.0.1</project-business-version> 
    ... 

Und dann, in der pom.xml jedes Moduls, verwende ich diese Eigenschaften. Das Problem ist, dass ich die Version des Eltern in dieser pom.xml deutlich eingeben muss. Zum Beispiel in meinem Geschäft pom.xml, ich habe:

<project> 
    <modelVersion>4.0.0</modelVersion> 
    <!-- I must indicate the version of the parent --> 
    <parent> 
    <groupId>my.project</groupId> 
    <artifactId>parent</artifactId> 
    <version>1.0.0</version> 
    </parent> 
    ... 
    <dependencies> 
    <!-- However, in my dependencies, I use directly the properties defined in the parent's pom.xml --> 
    <dependency> 
     <groupId>my.project</groupId> 
     <artifactId>project-persistence</artifactId> 
     <version>${project-persistence-version}</version> 
    </dependency> 

Allerdings empfehle ich wirklich, dass Sie einen Blick auf die release plugin haben, die Pflege zu modifizieren alle Versionsnummern für Sie brauchen.

Answer 3

Bietet diese article eine Lösung für Ihr Problem?

Die Idee ist, die Versionsnummer für das gesamte Projekt als eine Eigenschaft, nämlich "Aversion" (Wortspiel beabsichtigt), in der Elternpom zu deklarieren. Die Versionsnummer des Elternteils kann beliebig sein, solange sie mit "SNAPSHOT" endet.

Die Version der untergeordneten Module wird über die Eigenschaft $ {aversion} angegeben. Der Verweis von Kindern auf die Version ihrer Eltern ist fest codiert. Da die Version des Eltern-POM jedoch ein SNAPSHOT ist, sehen untergeordnete Module die Änderungen im Eltern-POM. Insbesondere, wenn der Eltern-Pom den Wert von $ {aversion} ändert, sehen die Kinder die Änderung.

Keine perfekte Lösung laut den Kommentaren.

Und das Release-Plugin löst das eigentliche Problem nicht: verschmelzen.
Endlose Kopien der Versionsnummer überall zu haben, bedeutet viele Konflikte, wenn Zweige wieder zusammengebracht werden.

Hinweis:

mit Maven 2.0.9 (spätestens eine - April 2008) Ich habe einfach das Versionselement aus den einzelnen Modulen wurde weggelassen, da sie die Version von ihren Eltern erben. Dies funktioniert auch mit der GroupId, wenn Ihre Module die gleiche groupId wie ihre Eltern haben.

Answer 4

Dies ist eine Idee für eine mögliche Erweiterung von Maven, die das Problem lösen würde. Derzeit müssen Sie eine Version des Artefakts und des Eltern-Pom in der pom.xml schreiben. Es gibt bereits eine Möglichkeit, um eine absolute Position für die Eltern pom zu geben:

<parent> 
    <groupId>org.codehaus.mojo</groupId> 
    <artifactId>my-parent</artifactId> 
    <version>2.0</version> 
    <relativePath>../my-parent</relativePath> 
</parent> 

Wenn Sie Weglassen von erlauben sowohl die Version der Eltern und der pom iff Maven Lage ist, die Mutter pom durch den relativen Pfad für den Zugriff auf , du bist fertig. Die Version wird nur im Eltern-Pom und nirgendwo sonst erwähnt.

Answer 5

ich in ähnliche Probleme ausgeführt haben, während auf einem großen System mit Maven 2.

Meiner Meinung nach ist der Nachteil des typischen Multi-Modul-Struktur aufgebaut arbeiten, ist, dass alle Module die gleiche Version teilen . Das ist in der Tat nervig: Auch wenn Ihr nächstes nur in einem Bugfix in foobar-jar besteht, müssen Sie die globale Version überall ändern (sei es manuell oder mit maven-release-plugin) und eine neue Version jeder Komponente rollen. In meinem Fall habe ich verschiedene WAR/EAR-Anwendungen erstellt, so dass mein Kunde mich fragt, warum ich eine neue Version von app1 und app2 geliefert habe, obwohl nur betroffen sein sollte.

Der gegenteilige Ansatz besteht darin, jede Komponente als unabhängiges Projekt mit einer eigenen unabhängigen Version zu verwalten. Dies ist flexibler, da es Teilfreigaben erlaubt, aber Sie müssen nun alle diese Versionen manuell verfolgen (wissen, welche Versionen Ihre nächste Lieferung bestehen wird, machen sicher interne Abhängigkeiten sind konsistent, etc.). Dies kann schnell zu einem Albtraum in einer großen Anwendung werden.

Ich habe lange über eine Möglichkeit nachgedacht, beide Ansätze zu kombinieren: die Flexibilität von unabhängigen Versionen, ohne die globale Kohärenz des Systems aufzugeben. Ich versuchte den gleichen Ansatz wie romaintaz und stieß auf das gleiche Problem. Schließlich kam ich auf diese Idee: http://out-println.blogspot.com/2008/10/maven-modules-with-independent-versions.html.

Betrachten Sie es als "experimentell", wie ich es am Ende nicht live (aus nichttechnischen Gründen) versuchen konnte. Aber ich denke, dass es den Trick machen würde.

Answer 6

Hier ist eine weitere leichte Abhilfe, bis die maven issue gelöst ist. In einem großen Projekt wird die pom.xml selbst nicht mehr in die Versionskontrolle aufgenommen, sondern in eine pom-template.xml, die nur einen Platzhalter für die Versionsnummer enthält.Nach dem Aktualisieren der Projektstruktur von der Versionskontrolle müssen Sie ein kleines Ameisen-Skript ausführen, das die tatsächliche pom.xml in jedem Verzeichnis generiert. Das ist ärgerlich, aber weniger ärgerlich, als all die lästigen Pom-Versionen ertragen zu müssen.

Answer 7

Wir haben genau dieses Problem. Wir haben eine große Anzahl (etwa 10) verschiedener Projekte, von denen einige voneinander abhängig sind. Der Ordner, der die Projekte enthält, hat einen übergeordneten Pom für den gesamten Satz von Projekten. Jedes Mal, wenn wir einen neuen Zweig erstellten, mussten wir in jede einzelne Pom-Datei gehen, um das < Version> -Element und auch die < Version für den Elternteil zu ändern, und all diese Bearbeitung war ärgerlich.

Nach dem Lesen dieser Frage und der Antworten hier erkannte ich, dass die Situation hoffnungslos war. Jedes Projekt könnte das < Version> Element vom Elternpom erben, so dass eines leicht zu eliminieren war, aber wir konnten natürlich die < Version> für das < Parent> nicht erben.

Leider habe ich vergessen, meinem Kollegen zu sagen, dass es unmöglich war, also hat er es behoben. Seine Lösung war eine Eigenschaft der Mutter pom-Datei hinzuzufügen:

<properties><currentVersion>2.6.1-SNAPSHOT</currentVersion></properties> 

Dann in den pom Kind Dateien, die wir die übergeordnete Version Tag wie folgt erklärt:

<version>${currentVersion}</version> 

Ich weiß nicht, warum das funktioniert . Ich sehe nicht, wie es den richtigen Elternteil finden kann, ohne die Versionsnummer anzugeben. Aber für mich (Maven Version 1.5.0_22) ist es ist arbeiten.