Layout del repository per progetti Maven di grandi dimensioni

Question

Ho una grande applicazione (~50 moduli) che utilizza una struttura simile alla seguente:

• Applicazione
  • Moduli di comunicazione
    • Modulo di comunicazione a colori
    • Modulo di comunicazione SSN
    • eccetera.modulo di comunicazione
  • Modulo router
  • Moduli di servizio
    • Modulo servizio di voto
      • Sottomodulo di interfaccia web per la votazione
      • Sottomodulo di raccolta voti per la votazione
      • eccetera.per votare
    • Modulo di servizio quiz
    • eccetera.modulo

Vorrei importare l'applicazione in Maven e Subversion.Dopo alcune ricerche ho scoperto che esistono due approcci pratici per questo.

Uno utilizza una struttura ad albero proprio come la precedente.Lo svantaggio di questa struttura è che sono necessarie un sacco di modifiche/hack per far funzionare bene il reporting multi-modulo con Maven.Un altro svantaggio è che in Subversion l'approccio standard trunk/tag/rami aggiunge ancora più complessità al repository.

L'altro approccio utilizza una struttura piatta, in cui è presente un solo progetto principale e tutti i moduli, sottomoduli e parti dei sottomoduli sono figli diretti del progetto principale.Questo approccio funziona bene per il reporting ed è più semplice in Subversion, tuttavia sento di perdere un po' della struttura in questo modo.

Quale strada sceglieresti a lungo termine e perché?

Answer 1

Abbiamo un'applicazione di grandi dimensioni (oltre 160 bundle OSGi in cui ogni bundle è un modulo Maven) e la lezione che abbiamo imparato, e che continuiamo a imparare, è che flat è migliore.Il problema con la codifica della semantica nella gerarchia è che si perde flessibilità.Un modulo che al 100% dice "comunicazione" oggi potrebbe essere in parte "servizio" domani e quindi dovrai spostare le cose nel tuo repository e ciò interromperà tutti i tipi di script, documentazione, riferimenti, ecc.

Quindi consiglierei una struttura piatta e codificare la semantica in un altro posto (ad esempio uno spazio di lavoro o una documentazione IDE).

Ho risposto in dettaglio a una domanda sul layout del controllo di versione con esempi in un'altra domanda, potrebbe essere rilevante per la tua situazione.

Answer 2

Penso che faresti meglio ad appiattire la struttura delle directory.Forse vuoi trovare una convenzione di denominazione per le directory in modo tale che vengano ordinate bene quando si visualizzano tutti i progetti, ma alla fine non penso che tutta quella gerarchia aggiuntiva sia necessaria.

Supponendo che tu stia utilizzando Eclipse come IDE, tutti i progetti finiranno in un elenco piatto una volta importati comunque, quindi non otterrai davvero nulla dalle sottodirectory aggiuntive.Ciò, oltre al fatto che la configurazione è molto più semplice senza tutta la gerarchia aggiuntiva, rende la scelta abbastanza chiara nella mia mente.

Potresti anche prendere in considerazione la possibilità di combinare alcuni moduli.Non so nulla della tua app o del tuo dominio, ma sembra che molti di questi moduli di livello foglia potrebbero essere più adatti come semplici pacchetti o set di pacchetti all'interno di un altro modulo di livello superiore.Sono favorevole a mantenere i barattoli coesi, ma a volte si può spingersi troppo oltre.