Gestione del ciclo di vita del progetto: approccio Maven vs 'manuale'

Usiamo Maven come nostro sistema di generazione di base sul nostro enorme sistema aziendale. Vale la pena il suo peso in oro. Lo usiamo per gestire le dipendenze, sia per le librerie di terze parti che per i moduli interni, per pacchettizzare l'applicazione per la distribuzione, per eseguire la versione dell'applicazione e in generale per fare tutto ciò che non abbiamo voglia di fare manualmente: -)

Se abbinato a qualcosa come Nexus, Maven è fantastico. Tutti sono sicuri di lavorare con le stesse dipendenze e i file POM sono supportati molto bene da IDE come Eclipse.

Non potevo tornare a fare roba senza Maven; è troppo utile.

Gli unici contro che riesco a pensare è che lavorare con Maven significa che devi pensare come Maven - i tuoi progetti devono essere eseguiti in modo Maven e devi mostrare agli altri sviluppatori non-maven come realizzare i loro progetti nel modo più saggio. Ha una curva di apprendimento non banale.

Se la tua applicazione è strettamente legata a qualcosa come una formica Apache, allora dovresti fare molte modifiche w.r.t. al modo in cui gestisci, costruisci, distribuisci o addirittura esegui test case, anche se non necessariamente tutto. Con Maven hai un ciclo di vita ben definito.

È vero che dovresti fare le cose nel modo in cui Maven ti chiede di fare, ma a volte ci sono dei modi per aggirarlo (ad esempio scavalcare la struttura standard del progetto).

Ma una volta che hai tutto a posto con Maven, la vita sarebbe sicuramente molto più semplice e gestibile.

Maven viene fornito con il supporto IDE e molti plugin in modo da poter scegliere i plug-in necessari.

L'unico problema è la documentazione. Poiché è ancora in crescita, non è il massimo.

Spero che questo link utile aiuti. Maven, un'introduzione e un confronto con Apache Ant.