Ich entschuldige mich für die Länge dieses Beitrags, aber ich hatte Probleme, ihn prägnanter zu gestalten, ohne das Bild zu präsentieren. Ich habe kürzlich den Job eines Build-Masters für ein Maven 3.0-Projekt mit mehreren Modulen geerbt. Das Problem ist, dass die Struktur des Projekts / der Module eine Katastrophe ist. Von der Art und Weise, wie die Dinge derzeit in der Quellcodeverwaltung gespeichert sind (wir verwenden RTC), bis zur POM-Struktur der Module, reiße ich mir die Haare und versuche, jedes Mal einen vollständigen Erstellungszyklus abzuschließen.

In der Projekthierarchie werden alle Module "flach" gespeichert. dh: alles ist auf dem gleichen Niveau. Ich habe einen übergeordneten POM und alle Module hängen vom übergeordneten POM ab. Das übergeordnete Element befindet sich jedoch auf derselben Ebene wie alle meine anderen Module.

Ex:

<code>c:\dev\MyEarProject
 + parent-pom
   - pom.xml
 + module1
   - pom.xml (depends on parent-pom)
   - src
   -   main
   -     ...
 + module2
   - pom.xml (depends on parent-pom)
   - src
   -   main
   -     ...
 + module3
   - pom.xml (depends on parent-pom)
   - src
   -   main
   -     ...
</code>

Der übergeordnete POM definiert alle Module, die zum Erstellen des Projekts erforderlich sind, sowie eine Reihe von Eigenschaften für Artefaktversionsnummern, die in den verschiedenen Submodulen verwendet werden:

<code><modules>
  <module>../module1</module>
  <module>../module2</module>
  <module>../module3</module>
</modules>

<properties>
    <org.springframework.version>3.0.5.RELEASE</org.springframework.version>
    <slf4j.version>1.6.4</slf4j.version>
    <repositoryAddress>${snapshots.repo.url}</repositoryAddress>
    <my.hibernate-module.dao.impl>1.2.3</my.hibernate-module.dao.impl>
    <my.hibernate-module.dao.api>1.2.3</my.hibernate-module.dao.api>
</properties>
</code>

Der POM jedes Moduls hängt wiederum vom übergeordneten POM über die Artefaktnummer des POM ab:

<code><parent>
    <groupId>com.cws.cs.lendingsimulationservice</groupId>
    <artifactId>parent-pom</artifactId>
    <version>1.0.6</version>
</parent>
</code>

Um die Dinge noch verwirrender zu machen, kann der tatsächliche Artefaktname (je nach Modul) mit dem Modulpfad übereinstimmen oder auch nicht. Beispielsweise kann sich Modul1 im Pfad befindenc:\dev\MyEarProject\module1 aber haben Artefaktnamenhibernate-module. Aufgrund der Art der Speicherung in RTC wird das Verzeichnis jedoch aufgerufenmodule1 wenn es ausgecheckt ist.

Der einfachste Weg, alles zu bauen, ist natürlich, sich darauf einzulassenc:\dev\MyEarProject\parent-pom\ und Rennmvn clean deploy. Dies funktioniert problemlos im SNAPSHOT-Modus, da das SNAPSHOT-Repo mehrere Bereitstellungen derselben Artefaktversion ermöglicht. Im Release-Modus schlägt dies jedoch fehl.

Diese Struktur verursacht 2 Probleme für mich.

Jedes Mal, wenn ich eine Versionsänderung an einer Eigenschaft im übergeordneten Modul vornehmen muss, muss ich die Versionsnummer des übergeordneten POM sowie die Version des übergeordneten POM für alle untergeordneten Module und die Version aller untergeordneten Module selbst aktualisieren (seit der übergeordnete POM geändert wurde).Immer wenn ich einen Release-Zyklus bereitstellen muss, wird mvn einen Fehler auslösen, wenn sich eines der Module seit dem letzten Zyklus nicht geändert hat und folglich nicht auf dasselbe Repo erneut bereitgestellt werden kann (das Repo ermöglicht nicht das Überschreiben vorhandener Artefakte).

Daher suche ich nach dem besten Weg, dieses Projekt umzustrukturieren, um diese Probleme zu vermeiden. Ich weiß, dass ich für den übergeordneten POM einen relativen Pfad verwenden kann, um stattdessen auf den übergeordneten POM zu verweisen. Ist dies jedoch angesichts der "flachen" Struktur der Module ein empfohlener Ansatz (dh der relative Pfad des übergeordneten POM wäre ../parent-pom/pom.xml - scheint mir ein wenig seltsam)? Da die Versionskontrolle des übergeordneten Elements von den Modulen unabhängig ist, würde die Verwendung eines relativen Pfads nicht nur die Tür für zusätzliche Verwirrung öffnen (dh, es gibt keine Möglichkeit zu wissen, welche Version des übergeordneten POM mit welcher Version verknüpft ist des Submoduls).

Zweitens, wie kann ich das gesamte Ohr aufbauen, ohne auf die Bereitstellungsfehler zu stoßen, die ich habe? Da das Artefakt bereits im Repo vorhanden ist, muss es nicht erneut erstellt und bereitgestellt werden. Ich habe versucht, --projects zu verwenden, aber mit der Anzahl der beteiligten Module wird es extrem schwierig, es zu verwalten.