Consigli sulla creazione della struttura del progetto Maven - Moduli multipli o progetti multipli?

Question

Si consideri la seguente applicazione enterprise esempio stratificazione:

1. progetto-services -> POJO Servizi strato
2. progetto-web -> applicazioni Web, dipende 'progetto-services', schierato come WAR
3. project-web-services -> Web Services, non è attualmente esposto su Internet
4. project-standalone -> Cron Jobs, dipende da "project-services"

Quale sarebbe l'approccio giusto per organizzare questo a Maven. Devo creare un progetto Maven multi-modulo? se "project-services" è un modulo Maven, può essere condiviso con altri tre progetti ciascuno dei quali è un'unità indipendente dispiegabile?

Nei miei progetti precedenti ho semplicemente creato 4 diversi progetti Maven e non ho mai sentito il bisogno di nient'altro.

Vuoi verificare se esiste un modo migliore rispetto a quello che ho fatto in precedenza.

Answer 1

Si potrebbe effettivamente fare entrambi approccio. Se è davvero un grande progetto, che vuoi sempre creare e rilasciare allo stesso tempo, un progetto multi-modulo è una buona idea. Faresti imposta in questo modo, probabilmente:

pom project (top level project that would define all of the modules) 
    jar project (project-services) 
    war project (project-web) 
    war project (project-web-services) 
    project-standalone (wasn't sure if this was a jar, or just some scripts, etc) 

quindi faresti solo costruire e rilasciare il via al progetto radice, e ci si prende cura di tutti i moduli secondari per voi. Possono avere entrambi dipendenze reciproche (basta fare attenzione alle dipendenze circolari). E avresti praticamente intenzione di andare.

L'altra opzione è completamente artefatti separati. Il vantaggio è un diverso ciclo di rilascio. È una buona opzione quando si ha una libreria jar che non cambia spesso, ma si aggiorna spesso la guerra.

E ovviamente, si potrebbe avere un mix, quindi forse il jar è standalone, ma si ha un progetto multi-modulo che contiene i due file di guerra. Il vantaggio di Maven è che è abbastanza flessibile da gestire qualunque sia il business case che hai per come dovrebbero essere suddivisi.

Answer 2

Sicuramente con un singolo progetto andrò per i moduli per garantire che le versioni utilizzate delle librerie di terze parti comuni corrispondano.

Avere un progetto POM come root e avere tutte le implementazioni e altri artefatti condivisi è generalmente considerato una buona pratica per tutto tranne che per progetti a modulo singolo.

Answer 3

Nel mio posto di lavoro abbiamo molti progetti di livello superiore che condividono le librerie (15 progetti di livello superiore condividono 35 o più librerie). Siamo andati con il singolo progetto per approccio alla biblioteca. Oggi, quando dobbiamo rilasciarli tutti in una volta, è un incubo.

Alcuni problemi che dobbiamo affrontare:

• capire manualmente le dipendenze
• necessario eseguire il rilascio nel giusto ordine
• un fallimento si ferma l'intero rilascio

Se dovessi d tutto da capo (ho contribuito a impostare tutto questo), vorrei utilizzare un singolo progetto multi-modulo. Se non altro, rilasciare tutto in una volta sola è un enorme vantaggio. I progetti potrebbero non sembrare belli in eclissi ma questo non è quello che dovresti mirare comunque.

Answer 4

Poiché si hanno alcune dipendenze dirette tra i moduli, consiglierei anche per il progetto multi-modulo.

Quello che consiglio spesso è di considerare il ciclo di vita dei moduli. Ad esempio: se si rilasciasse il modulo batch molto più spesso del livello di servizio, potrebbe essere opportuno dividerlo. Quindi non è necessario rilasciare (distribuire) materiale che non ha apportato modifiche. Poiché batch non viene solitamente distribuito allo stesso modo dei file .war. Ma ciò dipende dal ciclo di vita del servizio + moduli batch.

Nella maggior parte dei casi lo spostamento affiancato. Quindi +1 per "uno per tutti"