it-swarm.com.de

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

Ich brauche einige Ratschläge zur Strukturierung unserer Projekte in Git. 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-Königin sein, wenn die Dinge nicht eingerichtet sind gena wie die Apache Foundation ihre Projekte einrichtet (jeder, der das Release-Plugin verwendet, weiß wahrscheinlich, wovon ich spreche).

Wir möchten einen übergeordneten POM der obersten Ebene, der die Plugin-Versionen und die Build-Konfiguration steuert (Repo-Konfiguration, zu erstellende Artefakte, Namenskonventionen, Plugin-Versionen usw.). Maven möchte, dass sich alle unsere IT-Projekte in Unterordnern dieses Hauptprojekts befinden. Dies impliziert ein massives 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.

Aber diese Art von Konflikten mit dem extrem hierarchischen Modell von Maven, das fordert Unterprojekte Unterordner sein.

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

19

Sie haben 2 Möglichkeiten:
1. per git way: Submodule verwenden. Hier ist eine Dokumentation, wie Git Submodule verwaltet Git Submodule . Ich persönlich habe es nicht benutzt, aber es scheint zu Ihrem Problem zu passen.
2. Maven-Methode: In Maven ist es nicht zwingend erforderlich, dass Ihr Stammprojekt (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 der Ebene von project1 oder project2 aus, und maven versucht, das übergeordnete Element (die Konfiguration) aus dem maven-Repository und nicht aus dem übergeordneten Verzeichnis abzurufen. Sie sollten auf Versionen achten. Ich würde in Projekt1 oder Projekt2 empfehlen, einen Verweis auf ein übergeordnetes Element (Konfiguration) mit einer Release-Version beizubehalten. Um eine Version zu erstellen, müssen Sie dies in zwei Schritten tun: zuerst die Konfiguration freigeben und dann das Projekt freigeben. Projekt1 und Projekt2 können sich unabhängig voneinander entwickeln und müssen nicht dieselbe Konfigurationsversion wie ein übergeordnetes Element haben.

Nur für spezielle Fälle, in denen Sie sowohl Konfiguration als auch Projekte als SNAPSHOT-Versionen haben möchten, können Sie in Projekt1 oder Projekt2 das Tag <relativePath> Innerhalb des Tags <parent> Verwenden, um auf Ihren lokalen Konfigurationspfad zu verweisen. Ich empfehle dies nicht, da dies zu Problemen in der Entwicklungsumgebung führen wird (zumindest für mich in Eclipse).

Ich entschuldige mich für mein Englisch.

20
catta

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. Der beste Weg, dies zu tun, ist mit einem Artefakt-Repository wie Nexus oder Artifactory . Jedes Projekt kann ein eigenes Git-Repository haben.

Wir wollen ein übergeordnetes POM der obersten Ebene, das die Plugin-Versionen steuert und die Konfiguration erstellt (Repo-Konfiguration, , welche Artefakte erstellt werden sollen , Namenskonventionen, Plugin-Versionen usw.

Da ist dein echtes Problem. Es ist sinnvoll, ein übergeordnetes POM zu verwenden, um die Konfiguration zu erzwingen, aber es gibt 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, alle die Zeit).

3
parsifal