Maven Multi-Module Project Structure

Question

Sto costruendo un'applicazione distribuita basata su un'API HTTP front-end (leggi: web-facing) che chiama in sottostanti (leggi: non rivolti sul Web) Servizi di risparmio.

Come esempio, posso avere:

• autenticazione-service (contiene il codice per l'autenticazione)
• core-service (contiene fonti di risparmio generati ed alcune classi comuni come il rilevamento dei servizi e logica di inizializzazione

Tutti i singoli servizi dipendono dai servizi di base, così come l'API HTTP sul Web. Ho questo come progetto multi-modulo in questo momento, ma vorrei che ognuno di essi fosse separato (e rintracciato nei propri repository - anche se so che potrei comunque farlo con una build multi-modulo).

tl; dr -

È una pratica configurazione comune per avere un modulo (core-service) che è costruito individualmente e poi spinto ad un repo maven (e quindi incluso come un vaso nell'altro progetti), o sarebbe meglio in questo caso fare un progetto multi-modulo?

Answer 1

Personalmente, provo a evitare i progetti multi-modulo poiché, se si utilizza lo Maven Release Plugin, si è bloccati nel rilasciare tutti i moduli insieme.

Mentre questo può sembrare comodo, il problema sorge quando è necessario eseguire la correzione di bug su uno dei moduli - si finisce col rilasciare tutti i moduli, non solo il modulo con la correzione del bug, incrementando la loro versione anche se non sono cambiati.

Anche se stai eseguendo CI con progetti multi-modulo, anche tu esegui un colpo: di solito stai eseguendo su tutti i moduli da root, ma se stai lavorando in un particolare modulo, finisci per prendere il colpire di costruire quelli che non sono cambiati, in effetti perdere alcuni dei benefici che la modularizzazione avrebbe dovuto fornire.

Quindi, andare con i moduli indipendenti ma, e questo è il bit importante, creare un comune 'dip di dipendenza' usato da ciascuno.

Un pom 'dipendenza' è un pom che standardizza tutte le dipendenze attraverso i vostri progetti ed è diverso in quanto tali dipendenze sono specificati nella sezione dependencyManagement piuttosto che la sezione dependencies (è imposta anche configurazione plug-in di serie, ecc). Ciò consente ai tuoi poms di progetto di specificare la dependency pom come loro padre e quindi dichiarare le dipendenze di cui hanno bisogno meno le versioni, che vengono prelevate dalla finestra 'dependence' e quindi standardizzate nei tuoi progetti.

Se si è ancora preoccupati di poter creare tutto, è possibile ottenerlo con un semplice file batch.

Answer 2

Direi che il progetto multi-modulo è migliore. In caso di collocazione del servizio principale nel repository, gli sviluppatori dovrebbero preoccuparsi delle versioni. Developer1 ha bisogno del vecchio servizio ma Developer2 aggiorna il servizio.

Anche più filiali potrebbero essere un problema.

Answer 3

In linea di principio è sempre meglio che i progetti si evolvano nel modo più indipendente possibile. Tuttavia questo è più un problema organizzativo che tecnico. Quando tutto è stato detto e fatto, la struttura del tuo progetto dovrebbe essere coerente con la tua organizzazione.

Questo si riduce a tenere separati i progetti e hanno progetti dipendenti che gestiscono le dipendenze per mezzo di un gestore di repository locale se sono gestiti da persone diverse o ha senso rilasciarli in momenti diversi. Altrimenti probabilmente starai meglio con una struttura di progetto multi-modulo.

Nel nostro progetto siamo andati per una specie di scelta intermedia: abbiamo una struttura multi-modulo, ma tutti i progetti risiedono in repository Subversion indipendenti, in modo che possano essere ramificati separatamente, e usiamo il progetto di aggregatore per scegliere come combinare progetti di diverse filiali tramite svn:externals per creare versioni personalizzate per clienti specifici.

Lo svantaggio è che il mantenimento di una struttura simile è complicato e richiede molto tempo. Abbiamo sviluppato una quantità significativa di script per automatizzare parzialmente queste attività. Ciò è particolarmente oneroso perché lo Maven release plugin non è in grado di gestire i moduli collegati tramite gli elementi esterni di Subversion.

Answer 4

Una build multi-modulo dovrebbe essere preferita quando tutti i singoli moduli avranno lo stesso ciclo di vita l'uno dell'altro ... in altre parole, quando vengono sempre rilasciati insieme, i loro numeri di versione sono aumentati insieme, ecc. Ecc.

Un forte esempio di questo nel mondo OSS è il apache camel project. Ad esempio, tutti i componenti in bundle esistono come individual modules che possono essere inclusi separatamente nel progetto, ma sono legati allo stesso ciclo di vita della distribuzione core del cammello.

Le configurazioni multi-modulo Maven consentono alcune comodità quando si tratta di inserire i propri progetti in CI o di caricarli in IDE, ad esempio ma, in generale, se tutti i singoli moduli non condividono lo stesso ciclo di vita, allora un il progetto multi-modulo non è ottimale