Con questo articolo si conclude la serie dedicata a Maven, in cui abbiamo illustrato struttura e funzionamento di questo strumento di build. Cerchiamo pertanto di evidenziare luci e ombre anche in confronto a un altro importante strumento di build: Ant.

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 [5].

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 con tra Maven e Ant. Sebbene un primo parallelo relativo alle caratteristiche di questi due tool sia già  stato effettuato nel primo articolo [1], 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 leggitima, dal punto di vista degli sviluppatori, un tool di build dovrebbe limitarsi a:

• generare su richiesta i file di progetto per l‘IDE richiesto (per esempio mvn eclipse:eclipse);
• supportare lo sviluppo del codice e l‘esecuzione dei test;
• generare nuovi manufatti da “pubblicare” in luogo condiviso (per esempio mvn deploy);
• eseguire i test di integrazione e i regression test (possibilmente sempre all‘interno dell‘IDE).

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

• 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;
• avere un sito in cui pubblicare le varie informazioni relative al build;
• poter produrre rapidamente i vari manufatti pubblicandoli in un luogo condiviso;
• 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;
• generare nuove versioni, opportunamente etichettate, in maniera consistente;
• 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 [6], 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:

• rimuovere la necessità  di realizzare processi ad-hoc per il build dei progetti, fornendo all‘infrastruttura del build dei progetti uno standard basato su una serie di pattern ben collaudati (maggiore comprensione e produttività  del team coinvolto nello sviluppo, percorso chiaro per l‘utilizzo di best practice);
• ridurre la confusione relativa alla struttura dei progetti (struttura standard da utilizzare per organizzare i vari progetti);
• eliminare, o perlomeno minimizzare, la necessità  di implementare e manutenere diversi file di script;
• ridurre la necessità  di implementare script/programmi per l‘integrazione dei vari tool utilizzati per lo sviluppo del software (disponibilità  di plug-in predefiniti);
• risolvere elegantemente il problema delle dipendenze e delle varie relazioni tra i vari sotto-progetti;
• disporre di un sito standard in cui pubblicare le informazioni relative al progetto.

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 [1] 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 – Una 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 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

Di seguito sono riportati i goal di Maven di utilizzo frequente:

• clean:clean, rimuove tutti gli artifatti e file intermedi generati da Maven;
• idea:idea, genera i file di progetto per l‘IDE IntelliJ Idea;
• eclipse:eclipse, genera i file di progetto per l‘IDE Eclipse;
• javadoc:javadoc, estrae la documentazione standard (javadoc) del progetto;
• antrun:run, esegue uno specifico target Ant;
• clover:clover, produce il report relativo al copertura dei test;
• checkstyle:checkstyle, produce il report relativo allo stile del codice;
• site:site, genera la documentazione del progetto sotto forma di sito web;

Conlcusioni

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 casi di persone che utilizzano a questo scopo il proprio IDE.

Pertanto, una volta definito e messo in esecuzione questo progetto, non 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] http://maven.apache.org/plugins/maven-enforcer-plugin/rules/requireOS.html

Luca Vetti Tagliati

Luca Vetti Tagliati ha conseguito il PhD presso il Birkbeck College (University of London) e, negli anni, ha applicato la progettazione/programmazione OO, Component Based e SOA in diversi settori che variano dal mondo delle smart card a quello del trading bancario, prevalentemente in ambienti Java EE. Dopo aver lavorato a lungo nella City di Londra per le più importanti banche di investimento (Goldman Sachs, Lehman, Deutsche Bank, UBS, HSBC) ricopre attualmente l'incarico di Senior Lead Global Architect per importanti gruppi bancari nel sud della Svizzera. Ha collaborato attivamente con John Daniels (coautore del libro "UML components") e Frank Armour (coautore del libro "Advanced Use Case Modeling"). È autore del libro "UML e ingegneria del software", pubblicato nel 2003 da HOPS/Tecniche Nuove, di "Java Best Practice: i migliori consigli per scrivere codice di qualità", pubblicato nel 2008 dal medesimo editore, e dell'ebook "Verso Java 8. Appunti per lo sviluppatore in Java SE 7" pubblicato da MokaByte e scaricabile dal nostro sito. È stato invitato a Los Angeles e Boston per presentare i suoi paper in convegni inerenti Software Engineering & Architecture. Nel 2015 ha ricevuto il prestigioso ICMG Award.