Najlepszy sposób na zorganizowanie repozytorium Git dla Maven

Potrzebuję porady, jak ustrukturyzować nasze projekty w Git. Używamy Java, a Maven jest naszym narzędziem do budowania. Maven zakłada, że ​​wszystkie twoje projekty mają w końcu wspólnego przodka. Maven może być także prawdziwą królową dramatów, gdy rzeczy nie są skonfigurowane dokładnie tak, jak fundacja Apache konfiguruje swoje projekty (każdy, kto korzysta z wtyczki wydania, prawdopodobnie wie o czym mówię).

Chcemy nadrzędnego pom-rodzica, który kontroluje wersje wtyczek i konfigurację kompilacji (konfiguracja repo, jakie artefakty budować, konwencje nazewnictwa, wersje wtyczek itp.). Maven chciałby, aby wszystkie nasze projekty informatyczne znajdowały się w podfolderach tego głównego projektu. Oznacza to jedno ogromne repozytorium Git dla organizacji.

To zapewni bardzo głośne środowisko. Jeśli dwa zespoły pracują nad niepowiązanymi projektami, będą musiały stale dokonywać fuzji z drugiego zespołu. Idealnie chciałbym mieć jedno repo na projekt.

Ale tego rodzaju konflikty z niezwykle hierarchicznym modelem Maven, który wymaga , aby podprojekty były podfolderami.

Potrzebuję porady, jak ludzie pogodzili te dwa modele ... dziękuję!

Masz 2 opcje:
1. Git Way: użyj submodułów. Oto dokumentacja, w jaki sposób git zarządza submodułami git submoduły . Ja osobiście go nie użyłem, ale wygląda na to, że pasuje do twojego problemu.
2. drogą maven: w maven nie jest obowiązkowe, aby Twój projekt główny (konfiguracja) był hierarchicznie katalogiem nadrzędnym wszystkich twoich projektów. Możesz mieć taką strukturę:

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)

konfiguracja, projekt1 i projekt2 znajdują się na tym samym poziomie katalogu i każdy z nich może być repozytorium git. Podczas budowania projektu 1 lub projektu 2 uruchom polecenie maven z poziomu projektu 1 lub projektu 2, a maven spróbuje pobrać element nadrzędny (konfigurację) z repozytorium maven, a nie z katalogu nadrzędnego. Powinieneś zwrócić uwagę na wersje. Polecam w project1 lub project2, aby zachować odniesienie do elementu nadrzędnego (konfiguracji) z wersją wydania. Aby zrobić wydanie, musisz zrobić to w 2 krokach: najpierw zwolnij konfigurację, a następnie zwolnij projekt. Project1 i project2 mogą ewoluować niezależnie i nie muszą mieć tej samej wersji konfiguracji co rodzic.

Tylko w szczególnych przypadkach, gdy chcesz mieć zarówno konfigurację, jak i projekty jako wersje SNAPSHOT, w project1 lub project2 możesz użyć <relativePath>znacznika wewnątrz <parent>znacznika, aby wskazać lokalną ścieżkę konfiguracji. Nie polecam tego, ponieważ spowoduje to problemy w środowisku programistycznym (przynajmniej dla mnie w Eclipse)

Przepraszam za mój angielski.

Maven chciałby, aby wszystkie nasze projekty informatyczne znajdowały się w podfolderach tego głównego projektu

Nie, Maven chce po prostu móc odzyskać potrzebne artefakty. Najlepszym sposobem na to jest repozytorium artefaktów, takie jak Nexus lub Artifactory . Każdy projekt może mieć własne repozytorium Git.

Chcemy nadrzędnego pom-rodzica, który kontroluje wersje wtyczek i konfigurację kompilacji (konfiguracja repo, jakie artefakty budować , konwencje nazewnictwa, wersje wtyczek itp.

To twój prawdziwy problem. Sensowne jest użycie nadrzędnej POM do wymuszenia konfiguracji, ale nie ma powodu, aby łączyć konfigurację z kontrolą kompilacji. W rzeczywistości, z wyjątkiem niezależnego projektu wielomodułowego, powiedziałbym, że jest to bardzo zły pomysł, tylko z powodów, które podajesz (plus fakt, że musiałbyś zbudować wszystkie swoje projekty, wszystkie czas).