Dovremmo utilizzare un Maven Multi-Module Project nel nostro scenario?

Question

Dovremmo utilizzare un Maven Multi-Module Project nel nostro scenario?

#1 da (5 voti)

6

The Situation

Attualmente sto lavorando a un progetto che sviluppa diversi servizi RESTful che interagiscono in parte l'uno con l'altro. Ad esempio:

Il servizio A utilizza il servizio B
Il servizio C non utilizza nulla
Il servizio D utilizza il servizio C
la maggior parte dei servizi utilizza un progetto Utillities comune.

Non c'è NESSUNA condivisione del codice tra i servizi, essi si basano strettamente sull'API RESTful definita. Util contiene helper per test, helper per la lib di sicurezza, ....

Attualmente ogni progetto è indipendente nel proprio repository git. Durante lo sviluppo ci sono stati alcuni momenti in cui questo era leggermente allucinante:

più posti per la gestione delle dipendenze (i servizi condividono le dipendenze con le librerie di terze parti)
ogni progetto deve essere (maven) rilasciato separatamente (personaly mi piace)
quando si lavora "tra" progetti (lavorando su un servizio e lavorando su util a causa di ciò) si ottengono 2 richieste di revisione, a causa di 2 progetti (richieste pull)

La domanda

Uno del team ha proposto una soluzione ai problemi precedenti per unire tutti i repository e i progetti git in un unico repository git e in un progetto multi-modulo maven.

Accanto ai miei dubbi sull'idea (nessuna condivisione di codice, solo utilizzo come dipendenza comune, affidamento su API tra alcuni (non tutti) servizi, ...) mi piacerebbe sapere:

Sono noti vantaggi / svantaggi di questo piano?

Non mi piace che faccia una brutta discussione.

git project-management maven

posta Laures 11.04.2013 - 20:03

fonte

1 risposta

Leggi altre domande sui tag git project-management maven

Qual è l'algoritmo più ottimale per il conteggio delle righe di testo in un file? modello mvc: modello di suddivisione in livelli di accesso ai dati e di logica aziendale

score 5 · Accepted Answer

Se tutti i progetti devono essere (sempre, o quasi sempre) rilasciati contemporaneamente, come service-a-1.2.3, service-b-1.2.3, service-c-1.2.3 etc, allora il progetto multi-modulo è quello che il medico ha ordinato perché ti dà queste versioni simultanee, invece di dover ripetere manualmente le versioni per ogni modulo ogni volta.

Altrimenti, è meglio pensarci due volte prima di andare lì. Potrebbe essere piuttosto ingombrante e confondere avere qualcosa come 10 identiche versioni di service-a solo perché c'erano 10 rilasci di service-b - perché, beh, il progetto multi-modulo ti costringerebbe a rilasciare a ogni volta che rilasci b .

In uno dei miei progetti precedenti, i problemi con le versioni ridondanti dei moduli liberamente accoppiati sono stati la ragione principale per dividere un progetto multi-modulo.

^{"Hey ragazzi, perché abbiamo 10 rilasci di module-a ? Oh aspetta, 2 di questi erano a causa di cambiamenti in module-b , 3 a causa di module-c , 4 a causa di module-d E, sì, c'era un rilascio a causa delle modifiche in module-a , giusto. " Vedere cose del genere andare via dopo lo split è stato un vero sollievo.}

D'altra parte, quella stessa esperienza mi ha insegnato che se avessi mai bisogno di versioni sincrone di diversi moduli, farò sicuramente un progetto multi-modulo.

Pensaci: non è necessario memorizzare i moduli coinvolti, non è necessario progettare complicati script di rilascio: basta scattare mvn -B clean release:prepare release:perform , rilassarsi per un po 'e fare tutto per te in perfetta armonia. Semplicemente non può andare meglio di così.