it-swarm.com.de

Maven Eltern Pom Vs Module Pom

Es scheint mehrere Möglichkeiten zu geben, Eltern-Poms in einem Multiprojekt-Build zu strukturieren, und ich frage mich, ob jemand darüber nachgedacht hat, welche Vor-/Nachteile in jeder Hinsicht bestehen.

Die einfachste Methode, ein übergeordnetes POM zu haben, besteht darin, es im Stammverzeichnis eines Projekts abzulegen, d. H.

myproject/
  myproject-core/
  myproject-api/
  myproject-app/
  pom.xml

dabei ist die Datei pom.xml sowohl das übergeordnete Projekt als auch die Module -core -api und -app

Die nächste Methode besteht darin, das übergeordnete Element in ein eigenes Unterverzeichnis wie in zu unterteilen

myproject/
  mypoject-parent/
    pom.xml
  myproject-core/
  myproject-api/
  myproject-app/

Wenn der übergeordnete POM noch die Module enthält, diese aber relativ sind, z. ../myproject-core

Schließlich gibt es die Option, bei der die Moduldefinition und das übergeordnete Element wie in getrennt sind

myproject/
  mypoject-parent/
    pom.xml
  myproject-core/
  myproject-api/
  myproject-app/
  pom.xml

Wobei das übergeordnete pom eine "gemeinsame" Konfiguration enthält (DependencyManagement, Eigenschaften usw.) und das myproject/pom.xml die Liste der Module enthält.

Die Absicht ist, auf eine große Anzahl von Projekten und Artefakten skalierbar zu sein.

Ein paar Bonusfragen:

  • Wo ist der beste Ort, um die verschiedenen gemeinsam genutzten Konfigurationen wie Quellcodeverwaltung, Bereitstellungsverzeichnisse, allgemeine Plugins usw. zu definieren? eine gemeinsame).
  • Wie gehen das Maven-Release-Plugin, Hudson und Nexus mit der Einrichtung Ihrer Multi-Projekte um?

Bearbeiten: Jedes der Unterprojekte hat eine eigene pom.xml, ich habe sie weggelassen, um sie knapp zu halten.

277
Jamie McCrindle

Meiner Meinung nach müssen Sie zur Beantwortung dieser Frage den Projektlebenszyklus und die Versionskontrolle berücksichtigen. Mit anderen Worten, hat der Eltern-POM seinen eigenen Lebenszyklus, d. H. Kann er getrennt von den anderen Modulen freigegeben werden oder nicht?

Wenn die Antwort yes ist (und dies ist der Fall bei den meisten Projekten, die in der Frage oder in Kommentaren erwähnt wurden), dann braucht der Elternteil seine Ein eigenes Modul aus Sicht eines VCS und aus Sicht eines Maven, und Sie werden auf der Ebene des VCS ungefähr so ​​weit kommen:

root
|-- parent-pom
|   |-- branches
|   |-- tags
|   `-- trunk
|       `-- pom.xml
`-- projectA
    |-- branches
    |-- tags
    `-- trunk
        |-- module1
        |   `-- pom.xml
        |-- moduleN
        |   `-- pom.xml
        `-- pom.xml

Dies macht das Auschecken etwas schmerzhaft und ein üblicher Weg, damit umzugehen, ist die Verwendung von svn:externals. Fügen Sie beispielsweise ein trunks -Verzeichnis hinzu:

root
|-- parent-pom
|   |-- branches
|   |-- tags
|   `-- trunk
|       `-- pom.xml
|-- projectA
|   |-- branches
|   |-- tags
|   `-- trunk
|       |-- module1
|       |   `-- pom.xml
|       |-- moduleN
|       |   `-- pom.xml
|       `-- pom.xml
`-- trunks

Mit der folgenden externen Definition:

parent-pom http://Host/svn/parent-pom/trunk
projectA http://Host/svn/projectA/trunk

Ein Checkout von trunks würde dann die folgende lokale Struktur ergeben (Muster # 2):

root/
  parent-pom/
    pom.xml
  projectA/

Optional können Sie auch ein pom.xml im Verzeichnis trunks:

root
|-- parent-pom
|   |-- branches
|   |-- tags
|   `-- trunk
|       `-- pom.xml
|-- projectA
|   |-- branches
|   |-- tags
|   `-- trunk
|       |-- module1
|       |   `-- pom.xml
|       |-- moduleN
|       |   `-- pom.xml
|       `-- pom.xml
`-- trunks
    `-- pom.xml

Diese pom.xml ist eine Art "Fake" -Pom: Es wird niemals veröffentlicht, es enthält keine echte Version, da diese Datei niemals veröffentlicht wird, es enthält nur eine Liste von Modulen. Mit dieser Datei würde ein Checkout zu folgender Struktur führen (Muster 3):

root/
  parent-pom/
    pom.xml
  projectA/
  pom.xml

Dieser "Hack" ermöglicht es, einen Reaktor-Build nach einer Prüfung von der Wurzel aus zu starten und die Dinge noch handlicher zu machen. Eigentlich ist es so, wie ich gerne Maven-Projekte und ein VCS-Repository für große Builds einrichte : Es funktioniert einfach, es skaliert gut, es gibt alle Flexibilität Sie brauchen möglicherweise.

Wenn die Antwort nein ist (zurück zur Ausgangsfrage), dann können Sie mit Muster 1 leben (tun Sie das Einfachste, was möglicherweise funktionieren könnte) ).

Nun zu den Bonusfragen:

  • Wo ist der beste Ort, um die verschiedenen gemeinsam genutzten Konfigurationen wie Quellcodeverwaltung, Bereitstellungsverzeichnisse, allgemeine Plugins usw. zu definieren? eine gemeinsame).

Ehrlich gesagt, ich weiß nicht, wie ich hier keine allgemeine Antwort geben soll (wie "Nutze die Ebene, auf der es deiner Meinung nach Sinn macht, Dinge zu vergemeinschaften"). Außerdem können untergeordnete Poms geerbte Einstellungen immer überschreiben.

  • Wie gehen das Maven-Release-Plugin, Hudson und Nexus mit der Einrichtung Ihrer Multi-Projekte um?

Das Setup, das ich benutze, funktioniert gut, nichts Besonderes zu erwähnen.

Eigentlich frage ich mich, wie das Maven-Release-Plugin mit Pattern # 1 umgeht (besonders mit dem <parent> Abschnitt, da Sie zum Zeitpunkt der Veröffentlichung keine SNAPSHOT-Abhängigkeiten haben können). Das klingt nach einem Hühnchen- oder Ei-Problem, aber ich kann mich nicht erinnern, ob es funktioniert, und war zu faul, um es zu testen.

163
Pascal Thivent

Aus meiner Erfahrung und Maven Best Practices gibt es zwei Arten von "Eltern Poms"

  • Übergeordneter POM "Firma" - Dieser POM enthält Ihre firmenspezifischen Informationen und Konfigurationen, die jeden POM erben und nicht kopiert werden müssen. Diese Informationen sind:

    • repositories
    • vertriebsmanagement-Abschnitte
    • allgemeine Plugin-Konfigurationen (wie Quell- und Zielversionen von Maven-Compiler-Plugins)
    • organisation, Entwickler usw

    Die Vorbereitung dieses übergeordneten Poms muss mit Vorsicht erfolgen, da alle Poms Ihres Unternehmens davon erben, sodass dieser Pom ausgereift und stabil sein muss (die Veröffentlichung einer Version des übergeordneten Poms sollte sich nicht auf die Veröffentlichung aller Ihrer Unternehmensprojekte auswirken!).

  • die zweite Art von Eltern-POM ist ein Multimodul-Elternteil. Ich bevorzuge Ihre erste Lösung - dies ist eine Standardkonvention für Multimodul-Projekte, die sehr oft die VCS-Codestruktur darstellt

Die Absicht ist, auf eine große Anzahl von Projekten und Artefakten skalierbar zu sein.

Multiprojekte haben eine Baumstruktur - Sie sind also nicht auf eine Ebene des übergeordneten Poms beschränkt. Versuchen Sie ein passendes Projekt für Ihre Bedürfnisse zu finden - ein klassisches Beispiel ist das Verteilen von Mutimodul-Projekten

distibution/
documentation/
myproject/
  myproject-core/
  myproject-api/
  myproject-app/
  pom.xml
pom.xml

Ein paar Bonusfragen:

  • Wo ist der beste Ort, um die verschiedenen gemeinsam genutzten Konfigurationen wie Quellcodeverwaltung, Bereitstellungsverzeichnisse, allgemeine Plugins usw. zu definieren? eine gemeinsame).

Diese Konfiguration muss mit Bedacht in einen "Firmen" -Eltern-POM und einen Projekt-Eltern-POM aufgeteilt werden. Alles, was mit Ihrem Projekt zu tun hat, geht an das übergeordnete Unternehmen.

  • Wie gehen das Maven-Release-Plugin, Hudson und Nexus mit der Einrichtung Ihrer Multi-Projekte um?

Das Mutterunternehmen muss zuerst freigelassen werden. Für Multiprojekte gelten Standardregeln. CI-Server müssen alle wissen, um das Projekt korrekt zu erstellen.

33
cetnar
  1. Ein unabhängiges übergeordnetes Element ist die beste Methode, um Konfiguration und Optionen für ansonsten nicht gekoppelte Komponenten freizugeben. Apache hat ein übergeordnetes POM-Projekt, um rechtliche Hinweise und einige gängige Verpackungsoptionen zu teilen.

  2. Wenn in Ihrem Projekt der obersten Ebene echte Arbeit steckt, z. B. das Aggregieren von Javadoc oder das Packen einer Version, treten Konflikte zwischen den dafür erforderlichen Einstellungen und den Einstellungen auf, die Sie über das übergeordnete Element freigeben möchten. Ein Projekt nur für Eltern vermeidet dies.

  3. Ein gängiges Muster (das momentan die Nummer 1 ignoriert) ist, dass die Projekte mit Code ein übergeordnetes Projekt als übergeordnetes Projekt verwenden und die oberste Ebene als übergeordnetes Projekt verwenden. Dies ermöglicht die gemeinsame Nutzung von Kernelementen, umgeht jedoch das in Nummer 2 beschriebene Problem.

  4. Das Site-Plugin wird sehr verwirrt, wenn die übergeordnete Struktur nicht mit der Verzeichnisstruktur übereinstimmt. Wenn Sie eine aggregierte Site erstellen möchten, müssen Sie ein wenig fummeln, um dies zu umgehen.

  5. Apache CXF ist ein Beispiel für das Muster in # 2.

22
bmargulies

Beim dritten Ansatz gibt es einen kleinen Haken. Da aggregierte POMs (myproject/pom.xml) normalerweise überhaupt keine übergeordneten POMs haben, teilen sie keine Konfiguration. Das bedeutet, dass alle diese aggregierten POMs nur Standardrepositorys haben.

Dies ist kein Problem, wenn Sie nur Plugins von Central verwenden. Dies schlägt jedoch fehl, wenn Sie das Plugin mit dem Format plugin: goal aus Ihrem internen Repository ausführen. Beispielsweise kann foo-maven-plugin Mit der groupId von org.example Als Ziel generate-foo Angegeben werden. Wenn Sie versuchen, es mit einem Befehl wie mvn org.example:foo-maven-plugin:generate-foo Aus dem Projektstamm auszuführen, kann es auf den Aggregatmodulen nicht ausgeführt werden (siehe Kompatibilitätshinweis ).

Es sind mehrere Lösungen möglich:

  1. Plugin für Maven Central bereitstellen (nicht immer möglich).
  2. Geben Sie in allen aggregierten POMs den Repository-Abschnitt an (Pausen TROCKENES Prinzip).
  3. Lassen Sie dieses interne Repository in der settings.xml konfigurieren (entweder in den lokalen Einstellungen unter ~/.m2/settings.xml oder in den globalen Einstellungen unter /conf/settings.xml). Scheitert die Erstellung ohne settings.xml (ist möglicherweise in Ordnung für große interne Projekte, die niemals außerhalb des Unternehmens erstellt werden sollen).
  4. Verwenden Sie die übergeordneten Einstellungen mit Repositorys in Ihren aggregierten POMs (könnten zu viele übergeordnete POMs vorhanden sein?).
9
Ivan Dubrov