Introduzione

Con questo articolo concludiamo la serie dedicata a Maven, il cui obiettivo principale è stato quello di illustrare le caratteristiche salienti e i principali componenti di questo tool open source. Per quanto sia difficile esaurire l'argomento soltanto con una serie di articoli, i lettori dovrebbero aver tuttavia trovato sufficienti informazioni e stimoli per utilizzare professionalmente Maven per i propri progetti. Per chi desidera approfondire, esistono interi volumi dedicati all'argomento.

Nel corso di questo articolo ricapitoleremo le "luci" di Maven, senza nascondere alcune fastidiose "ombre" che per ora ne precludono il successo incondizionato. Tuttavia, nonostante tutte le legittime critiche nei confronti di Maven, per questo strumento si può e si deve parlare di successo, sia per l'enorme diffusione, sia per il semplice fatto che il processo di build della quasi totalità dei progetti Apache è affidato a Maven.

Come degna conclusione di questa serie di articoli si è deciso di affrontare un argomento complesso e al tempo stesso controverso: il confronto tra Maven e Ant. Sebbene un primo parallelo relativo alle caratteristiche di questi due tool sia già stato effettuato nel primo articolo, in questo contesto l'attenzione è focalizzata sull'aspetto del software engineering (quale tool selezionare?). Come lecito attendersi, si tratta di un dibattito ricorrente, spesso insidiato da inutili guerre di religione.

In effetti, Ant è stato un tool decisamente rivoluzionario: il suo avvento ha profondamente innovato il processo di build e di deployment dei progetti Java. Basti pensare ai vari tool "make" esistenti prima dell'avvento di Ant. Tuttavia, l'evolversi dei sistemi, e la consequente complessità dei relativi progetti organizzati in sottoprogetti opportunamente relazionati, richiede di effettuare un ulteriore passo in avanti, reso possibile da Maven.

L'impostazione dell'ambiente di sviluppo e produzione è un prerequisito fondamentale per ogni progetto software. Tutti coloro che lavorano in ambienti professionali sanno quanto sia importante disporre di una appropriata procedura di build, distribuzione e deployment.

Da tener presente che, probabilmente in maniera legittima, dal punto di vista degli sviluppatori, un tool di build dovrebbe limitarsi a compilare i sorgenti e produrre i package necessari.

In progetti professionali è richiesto molto di più. In particolare altri requisiti basilari prevedono:

1. la possibilità di integrare il pocesso di build con altri tool, come quello per la gestione dei sorgenti (SCM, software configuration management) e la continua integrazione, al fine di verificare continuamente il build del sistema, notificando tempestivamente eventuali errori; 2. avere un sito in cui pubblicare le varie informazioni relative al build; 3. poter produrre rapidamente i vari manufatti pubblicandoli in un luogo condiviso; 4. rendere disponibili i vari manufatti per l'installazione del sistema nei vari ambienti: integration test, UAT e produzione solo dopo aver eseguito con successo tutti i test previsti; 5. generare nuove versioni, opportunamente etichettate, in maniera consistente; 6. fornire la possibilità di eseguire il roll-back ad una precedente versione funzionante qualora quella corrente presenti dei malfunzionamente.

Maven e Ant

Come visto nel primo articolo della serie, il progetto Maven è nato all'interno della comunità Apache, inizialmente nell'ambito del progetto Jakarta Alexandria, quindi è migrato dapprima nel progetto Turbine per poi espandersi a macchia d'olio. Lo scopo era quello di risolvere una serie di problemi concreti relativi alla gestione del build, alla standardizzazione delle strutture di progetto, alla gestione delle dipendenze e alla generazione di documentazione.

Un primo grande passo nella razionalizzazione dei progetti di build è stato compiuto da Ant, che tuttavia aveva lasciato una serie di problemi irrisolti: quelli illustrati poc'anzi. Pertanto, da questo punto di vista, Maven si configura come la logica evoluzione di Ant. Nel primo articolo della serie abbiamo riportato un primo paragone tra Maven ed Ant da un punto di vista delle caratteristiche, mentre in queste pagine conclusive vogliamo presentare alcune informazioni circa il loro utilizzo e la curva di apprendimento.

Figura 1 - Tabella di confronto tra Ant e Maven
Figura 1 - Tabella di confronto tra Ant e Maven

La tabella precedente suggerisce di preferire Maven per progetti complessi e in situazioni in cui sia necessario gestire diversi progetti contemporaneamente (scenari abbastanza standard). I limiti di cui ancora sembrerebbe soffrire Maven sono legati alla documentazione e ai bug, ossia due aspetti che invece dovrebbero essere molto più curati per un software di successo quale Maven. Nonostante questi problemi, però, Maven offre una serie importante di vantaggi. Di seguito ne riportiamo solo alcuni:

  • Coerenza: le varie organizzazioni possono standardizzare la gestione dei progetti Java utilizzando l'insieme di best practice alla base di Maven. Accettando una serie di comodi standard, si accede a tutta una serie di servizi predefiniti. Il livello di qualità dei vari progetti, inevitabilmente, si eleva, i progetti stessi diventano quindi più trasparenti, si minimizza il tempo necessario per comprendere i vari progetti e quindi si facilita il movimento delle risorse umane. La struttura standard permette di risolvere tutta una serie di problemi. Per esempio verificare rapidamente se una libreria X è utilizzata e, in caso affermativo, sapere quale versione. Eliminare il tempo di apprendimento necessario a nuovi sviluppatori per comprendere l'organizzazione dei sorgenti di un progetto.
  • Riutilizzo: si tratta di uno degli elementi alla base di Maven, il cui utilizzo, di fatto è già un primo riutilizzo di best practice. Un ulteriore livello di riutilizzo è garantito dal fatto che la business logic è incapsulata in moduli (plug-in).
  • Maggiore agilità: utilizzando Maven, si semplifica il processo di generazione di nuovi componenti, di integrazione tra componenti, di condivisione di file eseguibili; inoltre, la curva di apprendimento di ciascun progetto viene incredibilmente ridotta.
  • Manutenzione più semplice: non è più necessario investire tempo e risorse per manutenere gli ambienti e gli script di build, i quali, oltre ad essere standardizzati, sono gestiti internamente da Maven.

Con l'introduzione dei file POM (Project Object Model), che è un singolo file XML, è sufficiente definire la descrizione del progetto. Maven utilizza queste informazioni per eseguire una serie di task predefiniti chiamati goal. Qualora necessario, è possibile dotare Maven di ulteriori goal attraverso opportuni plug-in. L'attenzione pertanto viene spostata dal "come" al "cosa" generare.

In particolare, i componenti innovativi molto apprezzati di Maven sono:

  • i repository che permettono di pubblicare e scaricare (ossia di condividere) i vari manufatti come i file JAR
  • la definizione di una struttura standard che permette di armonizzare i vari progetti
  • l'auto-versionamento dei manufatti

Goal di Maven di utilizzo frequente

I goal più utilizzati in Maven includono quelli per la compilazione, il testing, il packaging e il deployment dei progetti.

Conclusioni

Nella gestione professionale dei progetti è assolutamente necessario disporre di un processo ben definito e controllato per il build e la distribuzione dei progetti: sebbene ancora oggi sia possibile assistere a casi di persone che utilizzano a questo scopo il proprio IDE. Pertanto, una volta definito e messo in esecuzione questo processo, non c'è una grandissima differenza qualora si decida di utilizzare Ant o Maven, tanto che spesso si tratta di una mera questione di gusti.

Tra l'altro, nella realtà lavorativa raramente accade di predisporre gli ambienti di sviluppo da zero: molto frequente è il caso in cui nuovi progetti siano basati su script e configurazioni messi a punto in progetti precedenti. Pertanto, il tempo necessario per dar luogo a un nuovo progetto è decisamente ridotto.

Maven è uno strumento che richiede un certo tempo di apprendimento (grazie anche alla disorganizzazione della documentazione): si tratta di una nuova filosofia di intendere il build, non più basata sullo spiegare il come ma il cosa. Probabilmente Maven sta ad Ant come Ant sta ai vari make di build.

Riferimenti

  • [1] Giovanni Puliti, "Ant, La Formica Operosa che beve Caffè", MokaByte 112 e 113
  • [2] Luca Vetti Tagliati, "Java Quality Programming", capitolo 7 di prossima pubblicazione, MokaByte
  • [3] Maven

http://maven.apache.org/

  • [4] Jelly

http://jakarta.apache.org/commons/jelly/

  • [5] Vincent Massol - Jason Van Zyl, "Better Builds With Maven", Mergere

http://www.mergere.com/m2book_download.jsp

  • [6] Luca Vetti Tagliati, "Maven: Best practice applicate al processo di build e rilascio di progetti Java - I parte", MokaByte 114, Gennaio 2007
  • [7] Luca Vetti Tagliati, "Maven: Best practice applicate al processo di build e rilascio di progetti Java - II parte", MokaByte 115, Febbraio 2007
  • [8] Luca Vetti Tagliati, "Maven: Best practice applicate al processo di build e rilascio di progetti Java - III parte", MokaByte 117, April 2007
  • [9] Luca Vetti Tagliati, "Maven: Best practice applicate al processo di build e rilascio di progetti Java - IV parte", MokaByte 118, Maggio 2007
  • [10] Luca Vetti Tagliati, "Maven: Best practice applicate al processo di build e rilascio di progetti Java - V parte", MokaByte 119, Giugno 2007
  • [11] Luca Vetti Tagliati, "Maven: Best practice applicate al processo di build e rilascio di progetti Java - VI parte", MokaByte 120, Luglio/Agosto 2007
  • [12] Maven Enforcer Plugin

http://maven.apache.org/plugins/maven-enforcer-plugin/rules/requireOS.html