Con questo articolo approfondiamo la presentazione del file pom.xml, componente fondamentale di Maven contenente la descrizione dichiarativa del progetto Java in formato XML.

Introduzione

Con questo articolo si conclude la presentazione di uno dei principali componenti di Maven: il file pom.xml (Project Object Model, modello ad oggetti del progetto). Che, come visto nel corso dell‘articolo precedente, contiene i meta-dati del progetto memorizzati utilizzando il formato xml.
La struttura di questo file è molto articolata e spesso di non immediata comprensione. Tuttavia ciò non deve spaventare, sia perché non è necessario impostare, per ogni progetto, tutte i vari elementi, sia perché Maven fornisce una serie di comportamenti di default utilizzabili per la maggior parte dei progetti. Inoltre, una volta preparati i vari file POM per un progetto, è possibile adattarli per i successivi con minime variazioni. Infine, nel corso dell‘ultimo anno si è assistito ad un proliferare di ambienti grafici e plug-in Maven che ne semplificano ulteriormente l‘utilizzo.
La ricchezza del file POM, per molte persone, rappresenta invece un punto di forza in quanto offre tantissimi punti in cui è possibile alterare il comportamento di default di Maven. Pertanto, questa elevata versatilità , se da un lato può presentare un rallentamento dell‘iniziale apprendimento, dall‘altro dovrebbe conferire un certo grado di sicurezza: è difficile trovarsi di fronte a scenari di build, non previsti o di fronte ad integrazioni/problematiche, non gestibili dalla struttura del POM.
Questo articolo conclude la presentazione avviata nel corso del precedente. In particolare,  sono illustrate i seguenti componenti: la sezione con le informazioni supplementari del progetto, le impostazioni d‘ambiente e le impostazioni proprie di Maven.

More information (ulteriori informazioni)

La sezione delle informazioni supplementari ha un ruolo quasi esclusivamente descrittivo: è possibile specificare informazioni aggiuntive come il nome interno del progetto, la descrizione, l‘URL di riferimento, etc. che Maven si limita a riportare nei vari report senza attribuirne alcun valore semantico.

Figura 1 – Rappresentazione grafica della sezione delle informazioni supplementari

Informazioni generali del progetto

Questa sezione prevede i seguenti elementi:

name 
permette di specificare il nome “interno” del progetto utilizzato dal team di sviluppo. Non è infrequente il caso in cui un progetto preveda un nome diverso da quello specificato nel campo artifactId. Per esempio, le varie versioni del JDK Java, oltre al nome ufficiale, prevedono come nome interno il nome di un animale. Per esempio, Java 6 è stato denominato Delphine

description
in questo campo si può impostare una breve descrizione del progetto. Non si tratta assolutamente di una sostituzione della documentazione ufficiale, bensì permette di specificare un breve commento ad uso e consumo del POM

url
contiene l‘indirizzo URL del sito dedicato al progetto (tipicamente realizzato per mezzo di wiki);

inceptionYear
indica l‘anno di avvio/ideazione del progetto.

License (licenze)

I file delle licenze rappresentano documenti legali che sanciscono importanti accordi, per esempio come e quando i relativi progetti, o loro parti, possano essere utilizzati. Informazioni del genere, chiaramente, non sono di alcun interesse per il framework Maven che si limita a riportarle nel sito generato.
Per ogni singola licenza, è possibile specificare: name, url, comments e distribution. Mentre il significato dei primi tre campi dovrebbe essere immediato, per quanto attiene al campo distribution è necessario evidenziare che si tratta di un campo enumerato in cui è possibile impostare uno dei seguenti due valori: repo e manual. Il primo indica che il progetto prevede la possibilità  di essere scaricato da un repository di Maven, mentre il secondo indica l‘obbligatorietà  di un‘installazione manuale. Si veda il seguente listato.

 
  Apache 2
  http://www.apache.org/licenses/LICENSE-2.0.txt
  repo
  A business-friendly OSS license
 

Organization (organizzazione)

Questa sezione ospita alcune informazioni relative all‘azienda/organizzazione proprietaria del progetto. In particolare, è possibile impostare il nome dell‘organizzazione e l‘indirizzo URL del relativo sito internet: si veda il seguente listato.

 ...
 
  MokaByte
  www.mokabyte.it
 

Developers and Contributors (sviluppatori e contributori)

La sezione dedicata agli sviluppatori e contributori è indubbiamente una delle più popolari tra quelle presenti nel POM (è assolutamente atipico imbattersi in file POM privi di queste sezioni). Queste, come lecito attendersi, permettono di specificare informazioni relative, rispettivamente, ai membri del team sviluppo ed eventuali contributori. Si tratta di due strutture assolutamente simili, la cui differenza è principalmente di carattere semantico.
Per ogni individuo (developer o contributor, vedere il listato seguente) è possibile specificare l‘identificatore univoco (tipicamente il login), il nome, l‘indirizzo e-mail, un eventuale URL, l‘organizzazione di appartenenza (questa non è necessariamente quella che gestisce/possiede il progetto) incluso il relativo URL, i ruoli esercitati (ahimà© sono sempre più di uno), il fuso orario di riferimento ed ulteriori informazioni, come l‘indirizzo URL della foto.

 ...
 
  
   LucaVT
   Luca Vetti Tagliati
   Luca_V_T@yahoo.it
   http://LucaVettiTagliati.co.uk
   Mokabyte
   www.Mokabyte.it
   
    project manager
    senior architect
    senior developer
   
   0
   
     
     https://www.mokabyte.it/cms/writer-popup.run?id=i_YKY-6Z5-H61-OVT_7f000001_17035775_5b5429af     
    
   
  
 
 ...

Per quanto attiene alla seziona riservata ai contributori, come detto poc‘anzi, questa è del tutto equivalente a quella precedente con la sola eccezione che al posto dei tag developers e developer, ci sono i corrispondenti contributors e contributor.

Environment Settings

Questa sezione è dedicata alle informazioni relative a vari elementi dell‘ambiente in cui Maven è installato, come il sistema di gestione delle problematiche, quello dedicato al change management, le liste di distribuzioni e il scm. Da tener presente che le informazioni riportate in questa contesto hanno un ruolo essenzialmente documentativo. La configurazione dei vari tool è eseguita secondo le specifiche dei singolo tool nei relativi ambienti.

Figura 2 – Rappresentazione grafica della sezione relativa alle impostazioni d‘ambiente

Issue management (gestione delle “problematiche”)

In questa sezione sono riportate alcune informazioni basilari relative al software utilizzato per la gestione dei difetti e per il tracking delle richieste di modifica (defect and change request tracking), qualora utilizzato. Esempi di software di questo tipo sono: Jira, IBM Rational ClearQuest, TestTrak e Bugzilla. Le tipologie di “problemi” gestiti variano da richieste di fix, cambiamenti dei requisiti (change requirement), annotazioni ed idee utili per eventuali future versioni, etc.
La sezione issueManagement del POM ha essenzialmente un valore documentativo. Infatti, allo stato attuale le informazioni specificate non sono utilizzate da Maven.

 ...
 
  Jira
  http://127.0.0.1/Jira
 
 ...

Continuous Integration Management (gestione del processo di integrazione continua)

I sistemi che eseguono la integrazione continua, come Cruise Control, Continuum, TeamCity, e così via, sono ormai presenti in ogni progetto che si rispetti. Si tratta di sistemi che, su richiesta, o ad intervalli predefiniti (ogni ora, durante le ore notturne) eseguono il processo di build dell‘intero progetto.
Quantunque la configurazione di questi sistemi avvenga all‘interno e secondo i dettami degli stessi, alcuni elementi della relativa configurazione sono ospitati dal POM di Maven. Questi sono l‘insieme di quelli condivisi dalla totalità  dei sistemi di gestione del processo di continua integrazione: il famoso minimo comune denominatore. Un esempio è il notificatore di e-mail (listato riportato sotto). In particolare è possibile specificare gli eventi che si desidera notificare ed il tipo di notifica. Tipici eventi notificabili sono: errore di build (sendOnError), fallimento (sendOnFailure), successo (sendOnSuccess) e successo con presenza di warning (sendOnWarnng).

 ...
 
  continuum
  http://127.0.0.1:8080/continuum
  
   
    mail
    true
    true
    false
    false
    
     
continuum@127.0.0.1

    
   
  
 
 ...

Mailing list (elenchi degli indirizzi e-mail)

In questa sezione è possibile specificare eventuali mailing list costituite appositamente per il progetto (per esempio quella del team di sviluppo, quella degli utenti interessati a nuove release, etc.).
Come di consueto, la struttura del pom prevede una sezione mailingLists all‘interno della quale è possibile specificare le singole mailingList (listato sotto). La maggior parte degli attributi riportati hanno un significato piuttosto immediato. Le uniche sezioni che potrebbero destare qualche perplessità  sono quelle relative agli archivi. Questi, qualora presenti, sono i repository delle e-mail non più utilizzate e quindi archiviate.

 ...
 
  
   Development List
   developer-subscribe@127.0.0.1
    developer -unsubscribe@127.0.0.1
    developer @127.0.0.1
   http://127.0.0.1/user/
   
    http://base.google.com/base/1/127.0.0.1
   
  
 
 ...

SCM – Software Configuation Management (software per la gestione della configurazione)

Questa sezione è dedicata ai software utilizzati per la gestione dei file sorgenti, comunemente denominati SCM: Software Configuration Management o Control Management, oppure, semplicemente Version Control.

 ...
 
  scm:svn:https://subversion.scmsever.com/svn/myPrj/trunk/
  
    scm:svn:https://subversion.scmsever.com/svn/myPrj/trunk/
  
  trunk
   scm:svn:https://subversion.scmsever.com/svn/myPrj/trunk/myPrj
 
 ...

Gli elementi SCM (listato appena visto) sono:

• connection e developerConnection permettono di definire le diverse modalità  di connessione al sistema di controllo del versionamento attraverso Maven. In particolare, mentre la connessione utilizzata da Maven (connection) richiede un accesso di sola lettura necessaria per permettere a Maven di localizzare e leggere il codice sorgente, la connessione degli sviluppatori (developerConnection), invece, richiede un accesso in lettura/scrittura. Per la connessione con i sistemi SCM, Maven utilizza un proprio plug-in: Maven SCM. Questo fornisce un‘interfaccia comune per accedere alle diverse implementazioni SCM (CVS, Subversion, IBM ClearCase, etc.). Questa interfaccia è basata su una API ispirata al seguente formato URL: scm:[provider]:[provider_specific]. Nel listato riporato sopra è presente una configurazione contenente una connessione protetta (HTTPS) al server Subversion.
• tag permette di specificare l‘etichetta (la radice dell‘SCM) dalla quale è possibile accedere al progetto.
• url, permette di specificare l‘indirizzo URL che permette di navigare il repository

Maven environment (ambiente Maven)

La sezione dell‘ambiente Maven ospita informazioni relative ai repository, alla gestione delle distribuzioni e ai profili. Questi ultimi, in versioni precedenti di Maven, alloggiavano in un apposito file XML.

Prerequisites (prerequisiti)

In questa sezione, come lascia intuire il nome, è possibile specificare eventuali condizioni il cui soddisfacimento è propedeutico per un corretto funzionamento di Maven. Un esempi tipico è la necessità  di utilizzare eventuali fix. Qualora questi prerequisiti non siano soddisfatti Maven termina il build con un fallimento anche prima di avviare il build vero e proprio. L‘unico elemento che attualmente è possibile specificare in questa sezione è l‘elemento maven che permette di specificare il numero di versione (2.0.4).

 ...
 
  2.0.4
 
 ...

Figura 3. Rappresentazione grafica della sezione relativa alle impostazioni di ambiente MAVEN

Repositories

I repository di Maven, come evidenziato negli articoli precedenti, sono uno degli elementi più potenti ed apprezzati di Maven. Questi permettono di memorizzare e condividere vari manufatti, tipicamente file JAR. Ogniqualvolta un progetto Maven presenti una dipendenza da un determinato manufatto, Maven tenta di reperirlo accedendo al repository locale. Qualora questo tentativo fallisca, Maven ripete la ricerca nei vari repository remoti, terminando o dopo aver reperito il manufatto richiesto o a seguito dell‘esaurimento dei repository in cui cercare.

 ...
 
  
   
    false
    always
    warn
   
   
    true
    never
    fail
   
   codehausSnapshots
   Codehaus Snapshots
   http://snapshots.maven.codehaus.org/maven2
   default
  
 
 
  ...
 
 ...

Le informazioni previste sono:

• releases, snapshots: queste due sezioni permettono di configurare le politiche delle releases e shaposhots per ciascun tipo di manufatto. Tipicamente le release rappresentano rilasci ufficiali, testati, funzionanti, etc., mentre gli snapshot sono delle sorte di pre-view rese disponibili tipicamente per facilitare lo sviluppo di altri progetti dipendenti da quello di cui si abilita lo snapshot.
• enabled: si tratta di un attributo di tipo booleano, il cui significato è abbastanza intuitivo: permette di abilitare/inibire il meccanismo di appartenenza (releases/snapshots).
• updatePolicy: questo elemento permette di definire la frequenza con cui Maven verifica la presenza di aggiornamenti. Questa frequenza può essere sia legata ad un determinato lasso temporale, sia continuata. In particolare, a tal fine Maven esegue la comparazione tra il timestamp locale (memorizzato nel repositori del file maven-metadata) con quello remoto. I valori possibili sono: always (sempre), daily (giornalmente, impostazione di default), interval:x (ad intervalli x, dove x è un intero che specifica un lasso di tempo in minuti) e never (mai);checksumPolicy: ogniqualvolta Maven memorizza file nel repository, si occupa di accompagnarli con i relativi file di checksum. Questi sono utilizzati per verificare che il contenuto del file originario non sia alternato. Pertanto Maven permette di definire delle politiche di gestione di eventuali problemi relativi alla compatibilità  tra il manufatto pubblicato ed il relativo checksum. In particolare, è possibile impostare uno dei seguenti valori ignore (ignorare eventuali problemi), fail (fallire) o warn (emettere opportuna segnalazione).
• layout: Maven organizza i repository secondo un layout (organizzazione) standard. Tuttavia la versione precedente di Maven (1.x) utilizzava un formato diverso. Pertanto questo elemento permette di specificare il layout di riferimento.  I valori disponibili sono: default o legacy.

In Maven i repository sono utilizzati per due tipi di manufatti. I primi, la stragrande maggioranza, sono le librerie (in senso ampio) presenti nelle liste delle dipendenze dei vari progetti. I famosi file jar e non solo. I secondi, sono i vari plug-in utilizzati da Maven. Quantunque, anche questi siano dei manufatti, file a tutti gli effetti, è possibile allocarli in appositi distinti repository, il perché di questa decisione non è sempre chiarissimo, magari per rendere un po‘ più complessa la struttura del POM. L‘elemento pluginRepository ha una struttura completamente analoga a quella vista in precedenza dedicata alle librerie, unica differenza, come evidenziato poc‘anzi, è il tipo di manufatti memorizzati.

Distribution Management (gestione della distribuzione)

Repository

Mentre le sezioni repository del POM permettono di specificare le posizioni e le modalità  con cui Maven è in grado di effettuare il download dei vari manufatti necessari al POM, questa sezione, all‘interno dell‘elemento distributionManager, permette di specificare dove e come memorizzare i manufatti del progetto, in fase di deployment, all‘interno del repository. Qualora la sezione snaposhotRepository non sia definita, le impostazioni dell‘elemento repository sono utilizzati anche per la distribuzione di tipo snapshot. Ecco il listato che illustra le sezioni snapshotRepository e Repository all‘interno della sezione distributionManagement.

 ...
 
  
   false
   corp1
   Corporate Repository
   scp://repo1/maven2
   default
  

  
   true
   propSnap
   Propellors Snapshots
   sftp://propellers.net/maven
   legacy
  
  ...
 
 ...

Gli elementi di queste sezioni sono:

• id, name: entrambi i campi servono per identificare il repository. Mentre il campo id è un identificatore univoco, il nome serve per rendere il campo leggibile.
• uniqueVersion: è un attributo di carattere booleano il cui valore true serve ad incaricare Maven del versionamento dei vari manufatti pubblicati (generazione di un numero di versione univoco da associare ai manufatti memorizzati nel repository). Il valore false invece indica che la versione è definita come parte dell‘indirizzo.
• url: come lecito attendersi rappresenta l‘informazione principale dell‘elemento repository. Il formato URL, permette di specificare sia l‘ubicazione sia il protocollo di trasporto da utilizzare per il trasferimento dei manufatti generati dal processo di build.
• layout: come visto in precedenza permette di specificare la struttura del repository. In particolare: default indicata la struttura introdotta con Maven 2, mentre legacy  rappresenta la struttura precedente.

Distribution management base (informazioni base della gestione della distribuzione)

La gestione della distribuzione, come lo stesso termine suggerisce, è il processo che si incarica della distribuzione dei file generati dal processo di build.  L‘elemento distributionManagement ha una struttura simile a quella mostrata nel listato seguente.

 ...
 
  ...
  https://www.mokabyte.it/mokatips
  deployed
 
 ...

Gli elementi sono:

• downloadURL: si tratta dell‘universal resource locator (più banalmente indirizzo) utilizzabile da parte di altri POM per ottenere il manufatto prodotto dal build del presente POM. In particolare, mentre nelle sezioni dedicate ai repository (descritta successivamente) è possibile stabilire come eseguire i vari upload, in questa sezione si dichiara dove i vari POM possano prelevare i manufatti prodotti dal POM.
• status: questa informazione non dovrebbe essere manipolata direttamente, si tratta di un‘area di competenza di Maven che viene aggiornata ogni qualvolta Maven effettua un deployment. I valori possibili sono: none (valore di default, indica che il progetto non è in alcuno stato specifico); converted (il repository è stato convertito da una precedente versione di Maven); partner (indica che il manufatto è stato sincronizzato con un repository partner; probabilmente, synchronized si prestava meglio a descrivere questo stato); deployed (si tratta dello stato più frequente e indica che si è effettuato il deployment del manufatto con il comando deploy); verified (il progetto è stato verificato e quindi dovrebbe essere considerato finalizzato, finalized).

Site distribution (distribuzione del sito)

In questa sezione è possibile specificare le modalità  con cui distribuire il sito relativo al progetto e relativa documentazione. La struttura di questo elemento prevede gli stessi elementi analizzati per la sezione distributionManagement.

 ...
 
 ...
  
   mojo.website
   Mojo Website
   scp://beaver.codehaus.org/home/projects/mojo/public_html/
  
  ...
 
 ...

Relocation (rilocazione)

Questa sezione si rende necessaria ogniqualvolta si abbia la necessità  di rilocare un progetto. Per comprendere appieno questa sezione è necessario ricordare che Maven è stato inizialmente concepito per risolvere problemi di gestione dei progetti all‘interno del gruppo Apache. In questo contesto, la migrazione di progetti era ed non è un evento atipico. In effetti, è possibile assistere ad una serie di progetti che, nati all‘interno di altre iniziative, abbiamo raggiunto un tale successo da far nascere l‘esigenza di creare progetti a sà© stanti oppure di progetti, inizialmente nati all‘interno di organizzazioni commerciali, vengano donati alla comunità  open source.
La sezione relocation, oltre alle informazioni tipiche ed in particolare al nuovo nome univoco, permette di specificare un messaggio con opportuna spiegazione delle motivazione che hanno dato luogo alla rilocazione.

 ...
 
  ...
  
   com.mokabyte
   my-project
   1.0
   This project has been donated to Mokabyte
  
 ...
 
 ...

Profiles (profili)

Una caratteristica introdotta a partire dalla versione 4.0 dei POM sono i profili. Queste sezioni permettono di variare opportune impostazioni in funzione dell‘ambiente di build. Ciascun profilo include sia una sezione opzionale dedicata all‘attivazione (una sorta di trigger per un profilo) sia un insieme di variazioni da apportare al POM qualora il relativo profilo venga attivato. Un esempio classico consiste nel far in modo che un progetto realizzato per eseguire determinati test faccia riferimento ad un diverso database a seconda dell‘ambiente di esecuzione. Un altro esempio consiste nel far sì che il sistema, a seconda della versione del JDK utilizzata, prelevi opportune impostazione da diversi repository.
Gli elementi del profilo, tutti già  esaminati in precedenza con l‘eccezione di attivazione, sono riportati nel seguente listatino:

 ...
 
  
   test
   ...
   ...
   ...
   ...
   ...
   ...
   ...
   ...
   ...
  
 

Activation (attivazione)

Le attivazioni sono una parte importantissima dei profili. Il punto di forza di un profilo è dato dalla sua capacità  di modificare le basi del POM in circostanze ben definite, le quali sono specificate attraverso l‘elemento attivazione. Pertanto un profilo viene attivato quando tutte le condizioni definite nella sezione attivazione sono contemporaneamente soddisfatte.

 ...
 
  
   test
   
    false
    1.5
    
     Windows XP
     Windows
     x86
     5.1.2600
    
    
     mavenVersion
     2.0.3
    
    
     ${basedir}/file2.properties
     ${basedir}/file1.properties
    
   
   ...
  
 

Gli elementi inclusi sono:

• jdk: questo elemento esegue la verifica della versione del jdk. In particolare, il controllo è soddisfatto qualora il numero di versione del jdk in esecuzione risulti compatibile con quello impostato.  Se per esempio si impostasse l‘elemento jdk al valore 1.5 e l‘ambiente di esecuzione riportasse un valore 1.5.0_06, il controllo risulterebbe soddisfatto.
• os: in questo caso l‘obiettivo dell‘elemento è verificare il sistema operativo di esecuzione. Gli elementi utilizzabili sono (per maggiori informazioni sui valori utilizzabili, consultare [9]): arch (ossia l‘architettura hardware di riferimento); family (famiglia, per la quale i valori ammessi sono dos, mac, netware, os/2, tandem, unix, windows, win9x, z/os, os/400); name (il nome del sistema operativo); vesion (la versione); display (flag per individuare il sistema operativo).
• property: in questo caso questa particolare attivazione è soddisfatta qualora Maven individui una proprietà  (${name}) con lo stesso valore specificato.
• file: questa attivazione è soddisfatta qualora Maven riesca ad individuare l‘esistenza (sezione exists) o l‘assenza (sezione missings) di un determinato file.

Per individuare l‘insieme, eventualmente vuoto, dei profili attivati in un determinato ambiente, è necessario eseguire il comando:

mvn help:active-profiles

Da tenere presente che l‘elemento attivazione non è l‘unico modo per far sì che un determinato profilo venga attivato. Il file settings.xml ha una sezione analoga denominata activeProfile che permette di definire l‘identificatore univoco (id) di un profilo. Per finire, un profile può essere attivato esplicitamente attraverso la linea di comando. In questo caso è necessario utilizzare il flag  -p  e il nome del profilo.

Conclusioni

In questo quarto articolo abbiamo concluso l‘analisi, avviata in quello precedente, di uno degli elementi fondamentali di Maven, il file POM. In particolare sono state presentate le sezioni relative alle informazioni supplementari, alle impostazioni di ambiente e alle impostazioni Maven. Quest‘ultima ospita la parte relativa ai profili, originariamente ospitata da un apposito file xml.
Il file POM presenta una struttura molto ricca e complessa. Sebbene non sia sempre intuitivo, si tratta di un elemento di grande importanza: evidenzia un certo stato di maturità  e di versatilità .
Particolarmente apprezzabile è lo sforzo di astrazione che ha portato alla formulazione della struttura del file POM e quindi alla possibilità  di incapsulare in un solo file, di carattere dichiarativo, tutti gli aspetti di un progetto. Questo permette di eliminare una situazione caotica, spesso frequente in progetti del passato, costituita dalla presenza di dozzine di file di script da utilizzare per i processi di build, deploy, etc.
Maven sta acquisendo un successo sempre crescente, tanto che nell‘ultimo anno si è assistito al proliferare di tutta una serie di tool e di ambienti grafici che ne agevolano enormemente l‘utilizzo, soprattutto per le operazioni di impostazione del file POM.
Infine, come tipicamente accade con altri tool/framework, una volta configurato Maven per la gestione di un progetto, esportare le varie impostazioni ad altri progetti diviene un esercizio elementare.

Riferimenti

[1] “Ant, la formica operosa che beve caffè” Mokabyte 112 e 113

[2] Luca Vetti Tagliati, “Java Quality Programming”, (scaricabile dalla sezione libri del sito 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] http://maven.apache.org/plugins/maven-enforcer-plugin/rules/requireOS.html