Il modo migliore per strutturare un repository Git per Maven

Ho bisogno di alcuni consigli su come strutturare i nostri progetti in Git. Usiamo Java e Maven è il nostro strumento di compilazione. Maven in qualche modo presume che tutti i tuoi progetti abbiano un antenato comune alla fine. Maven può anche essere una vera regina del dramma quando le cose non sono impostate esattamente nel modo in cui la fondazione Apache imposta i loro progetti (chiunque usi il plugin di rilascio probabilmente sa di cosa sto parlando).

Vogliamo un pom principale di livello superiore che controlli le versioni dei plugin e costruisca la configurazione (configurazione repo, quali artefatti costruire, convenzioni di denominazione, versioni dei plugin, ecc.). Maven vorrebbe che tutti i nostri progetti IT fossero nelle sottocartelle di quel progetto principale. Ciò implica un enorme repository Git per l'organizzazione.

Ciò renderà l'ambiente molto rumoroso. Se ci sono due team che lavorano su progetti non correlati, dovranno costantemente riunire le altre squadre. Idealmente, vorrei avere un repository per progetto.

Ma quel tipo di scontri con il modello estremamente gerarchico di Maven, che richiede che i sottoprogetti siano sottocartelle.

Ho bisogno di un consiglio su come le persone hanno riconciliato questi due modelli ... grazie!

Hai 2 opzioni:
1. per git way: usa i sottomoduli. Ecco una documentazione su come git gestisce i sottomoduli Git submodules . Personalmente non l'ho usato ma sembra adatto al tuo problema.
2. per via: in Maven non è obbligatorio che il tuo progetto di root (configurazione) sia gerarchicamente la directory principale di tutti i tuoi progetti. Puoi avere una struttura del genere:

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)

configurazione, progetto1 e progetto2 sono allo stesso livello di directory e ognuno potrebbe essere un repository git. Quando si genera project1 o project2 si esegue il comando maven dal livello project1 o project2 e maven proverà a recuperare il genitore (configurazione) dal repository maven non dalla directory padre. Dovresti prestare attenzione alle versioni. Consiglierei in project1 o project2 di mantenere un riferimento a un genitore (configurazione) con una versione di rilascio. Per effettuare un rilascio devi farlo in 2 passaggi: rilascia prima la configurazione e rilascia il secondo progetto. Project1 e project2 possono evolversi indipendentemente e non devono avere la stessa versione di configurazione di un genitore.

Solo per casi speciali quando si desidera avere sia la configurazione che i progetti come versioni SNAPSHOT, in project1 o project2 è possibile utilizzare il <relativePath>tag all'interno del <parent>tag per puntare al percorso di configurazione locale. Non lo consiglio perché creerà problemi nell'ambiente di sviluppo (almeno per me in Eclipse)

Mi scuso per il mio inglese.

Maven vorrebbe che tutti i nostri progetti IT fossero nelle sottocartelle di quel progetto principale

No, Maven vuole semplicemente essere in grado di recuperare gli artefatti di cui ha bisogno. Il modo migliore per farlo è con un repository di artefatti, come Nexus o Artifactory . Ogni progetto può avere il proprio repository Git.

Vogliamo un pom principale di livello superiore che controlli le versioni dei plugin e costruisca la configurazione (configurazione repo, quali artefatti costruire , convenzioni di denominazione, versioni dei plugin, ecc.

C'è il tuo vero problema. Ha senso usare un POM padre per imporre la configurazione, ma non c'è motivo di combinare la configurazione con il controllo di compilazione. Infatti, ad eccezione di un progetto multi-modulo autonomo, direi che è una pessima idea, solo per i motivi che affermi (oltre al fatto che dovresti costruire tutti i tuoi progetti, tutti il tempo).