Der beste Weg, ein Git-Repository für Maven zu strukturieren

Ich brauche Ratschläge, wie wir unsere Projekte in Git strukturieren können. Wir verwenden Java und Maven ist unser Build-Tool. Maven geht davon aus, dass alle Ihre Projekte irgendwann einen gemeinsamen Vorfahren haben. Maven kann auch eine echte Drama-Queen sein, wenn die Dinge nicht genau so eingerichtet sind, wie die Apache-Stiftung ihre Projekte erstellt (jeder, der das Release-Plugin verwendet, weiß wahrscheinlich, wovon ich spreche).

Wir wollen einen übergeordneten POM auf oberster Ebene, der die Plugin-Versionen steuert und die Konfiguration erstellt (repo config, welche Artefakte erstellt werden müssen, Namenskonventionen, Plugin-Versionen usw.). Maven möchte, dass sich alle unsere IT-Projekte in Unterordnern dieses Hauptprojekts befinden. Dies impliziert einen massiven Git-Repo für die Organisation.

Dies führt zu einer sehr lauten Umgebung. Wenn zwei Teams an nicht verwandten Projekten arbeiten, müssen sie ständig Zusammenschlüsse mit dem anderen Team vornehmen. Idealerweise hätte ich gerne ein Repo pro Projekt.

Diese Art von Konflikten kollidiert jedoch mit dem extrem hierarchischen Modell von Maven, das verlangt, dass Unterprojekte Unterordner sind.

Ich brauche einen Rat, wie die Leute diese beiden Modelle in Einklang gebracht haben ... Danke!

Sie haben 2 Möglichkeiten:
1. Mit Git Way: Verwenden Sie Submodule. Hier ist eine Dokumentation, wie Git Submodule verwalten Git Submodule . Ich persönlich habe es nicht benutzt, aber es scheint zu Ihrem Problem zu passen.
2. per maven way: in maven ist es nicht zwingend erforderlich, dass ihr root-projekt (konfiguration) hierarchisch das übergeordnete verzeichnis aller ihrer projekte ist. Sie können eine solche Struktur haben:

configuration
 +-- pom.xml (configuration:XXX)
project1
 +-- pom.xml (project1:1.0-SNAPSHOT)
 !
 +-- module11 
 !     +-- pom.xml (1.0-SNAPSHOT)
 +-- module12
       +-- pom.xml (1.0-SNAPSHOT)
project2
 +-- pom.xml (project2:2.0-SNAPSHOT)
 !
 +-- module21 
 !     +-- pom.xml (2.0-SNAPSHOT)
 +-- module22
       +-- pom.xml (2.0-SNAPSHOT)

Konfiguration, Projekt1 und Projekt2 befinden sich auf derselben Verzeichnisebene und jedes kann ein Git-Repository sein. Wenn Sie project1 oder project2 erstellen, führen Sie den Befehl maven auf Projekt1- oder Projekt2-Ebene aus, und maven versucht, das übergeordnete Element (die Konfiguration) aus dem Maven-Repository abzurufen, nicht aus dem übergeordneten Verzeichnis. Sie sollten auf Versionen achten. Ich würde in project1 oder project2 empfehlen, einen Verweis auf ein übergeordnetes Element (Konfiguration) mit einer Release-Version beizubehalten. Um ein Release zu erstellen, müssen Sie dies in zwei Schritten tun: Zuerst die Konfiguration freigeben und dann das Projekt freigeben. Projekt1 und Projekt2 können unabhängig voneinander entwickelt werden und müssen nicht dieselbe Konfigurationsversion wie ein übergeordnetes Element haben.

Nur in besonderen Fällen, wenn Sie sowohl Konfiguration als auch Projekte als SNAPSHOT-Versionen haben möchten, können Sie in Projekt1 oder Projekt2 das <relativePath>Tag inside- <parent>Tag verwenden, um auf Ihren lokalen Konfigurationspfad zu verweisen. Ich empfehle dies nicht, da dies Probleme in der Entwicklungsumgebung verursacht (zumindest für mich in Eclipse).

Ich entschuldige mich für mein Englisch.

Maven möchte, dass sich alle unsere IT-Projekte in Unterordnern dieses Hauptprojekts befinden

Nein, Maven möchte einfach nur die benötigten Artefakte abrufen können. Dies geschieht am besten mit einem Artefakt-Repository wie Nexus oder Artifactory . Jedes Projekt kann ein eigenes Git-Repository haben.

Wir wollen einen übergeordneten POM auf oberster Ebene, der die Plugin - Versionen steuert und die Konfiguration erstellt (repo config, welche Artefakte erstellt werden müssen , Namenskonventionen, Plugin - Versionen usw.)

Da ist dein echtes Problem. Es ist sinnvoll, ein übergeordnetes POM zu verwenden, um die Konfiguration zu erzwingen. Es gibt jedoch keinen Grund, die Konfiguration mit der Build-Steuerung zu kombinieren. Abgesehen von einem eigenständigen Projekt mit mehreren Modulen würde ich sagen, dass dies eine äußerst schlechte Idee ist, und zwar nur aus den von Ihnen angegebenen Gründen (plus der Tatsache, dass Sie alle Ihre Projekte erstellen müssten, allesamt die Zeit).