Guida all’utilizzo di Maven

Impariamo a conoscere questo tool di compilazione / gestione che permette di semplificare (e di molto) la compilazione e la gestione di progetti Java.

Maven rende più semplice gestire un progetto Java

Il processo si semplifica perché non è necessario conoscere nel dettaglio i meccanismi di compilazione, basta usare i numerosi plugins gestiti dalla comunità open-source. Questi ultimi sono riusati in più progetti che, cosicché i processi siano standardizzati. Grazie al POM (Project Object Model) tutte le informazioni riguardanti il progetto sono racchiuse in un solo punto.

La struttura di un progetto Maven, inoltre, porta lo sviluppatore a seguire i gli standard di qualità del software industriale, ad esempio

  • Test separati dall’applicativo
  • Documentazione aggiornata
  • Ambiente di esecuzione di test il cui ambiente di compilazione/esecuzione non sia legato all’ambiente applicativo

Inoltre, vi è mai capitato di dover usare una libreria, che sò… spring… e di dover cercare tutte le dipendenze per aggiungerle al progetto? Magari mettendo di tutto un po’ per non perdere tempo?

Maven si occupa anche di dependency management che include: update automatico e dipendenze transitive. Ma procediamo con qualche piccolo esempio. Per compilare tradizionalmente ci sono 3 opzioni

  1. javac
  2. ant script
  3. ide

Probabilmente ve ne sono altre, ma sicuramente meno usate. Nel primo caso bisogna costruire la stringa di compilazione, impacchettare il tutto, eseguire i test e rilasciare il software aggiornato. Il secondo prevede la scrittura di uno script che faccia le operazioni ripetitive per conto nostro ma va manutenuto (esistono i task ant opensource, ma, a parte qualche esempio, non si trovano script ant già pronti per le varie esigenze)

Il terzo funziona abbastanza bene, se il tool supporta quello che dobbiamo fare. Mi riferisco alla creazione di war, ear, webservices… Se non lo supporta possiamo integrare all’ide il primo ed il secondo metodo.

Fermo restando che in tutti e tre i casi bisogna gestire le librerie, se il progetto è composto da più moduli bisogna mantenere l’ordine di compilazione. Abbiamo tralasciato tutta una serie di dettagli perché non essenziali, ma best-practice che bisognerebbe sempre fare. Parlo di test prima di rilasciare ogni modulo, documentazione, metriche, verifica del riuso del codice.

Vediamo un piccolo esempio. Creiamo questa alberatura

il file pom.xml conterrà:

In poche righe abbiamo stabilito il nome del progetto, la versione e le sue dipendenze. In particolare abbiamo dichiarato che la dipendenza junit verrà usata in fase di test, ma non verrà rilasciata con l’applicativo.

E poi? Basta…

nella cartella my-app lanciamo mvn package e dopo pochi secondi otterremo

Tutto qui… il progetto è compilato ed impacchettato, un jar in questo caso

Anche se sembra poco nel frattempo maven avrà eseguito questi passi

  1. validate
  2. generate-sources
  3. process-sources
  4. generate-resources
  5. process-resources
  6. compile

i passi 2 e 4 sono passi un po’ particolari… vengono attivati quando si usano plugin che generano codice, ad esempio la generazione di un webservices. Ma supponiamo che non si voglia avere un jar, ma un war:

Aggiungiamo una cartella src/main/webapps/WEB-INF

Creiamo un web.xml

modifichiamo jar in war nel pom e:

Viene creato un war,

  • nella cartella /WEB-INF/classes vengono poste le classi compilate del progetto
  • nella cartella /WEB-INF/lib vengono poste le dipendenze, nel nostro caso log4j (junit, come dicevamo, viene usata solo per i test)

Nella root del progetto viene inserito tutto quello che è presente in src/main/webapps. Ci sono altri tipi di packaging che si posso usare in maven, come gli ear ed altri legati a plugins che si possono aggiungere.

 

Le dipendenze

Abbiamo detto che è possibile indicare le dipendenze del nostro progetto inserendo degli snippet xml opportuni, del tipo:

Dichiariamo solo il gruppo, l’artifact-id e la versione della libreria che vogliamo utilizzare e Maven provvederà a

  1. Se la libreria è presente nel repository locale, altrimenti accederà ad internet per scaricarla
  2. Verificare se la libreria dichiara a sua volta dipendenze aggiungendole automaticamente al nostro progetto

Nel nostro caso avremo alcune commons di jakarta in più. Tutte le dipendenze, se non già presenti nel repository locale, vengono scaricate principalmente da http://repo1.maven.org/maven2, ma ogni dipendenza può dichiarare altri siti dove scaricare librerie e plugin.

 

Strumenti di sviluppo

Ogni sviluppatore ha preferenze sull’IDE da utilizzare e Maven accontenta un po’ tutti. Esistono vari plugin (sia per maven che per gli IDE) che consentono di lavorare su di un progetto prendendo le configurazioni direttamente dal POM senza doverle re-immettere nella configurazione del tool.

Ad esempio

genererà il .project ed il .classpath di eclipse.

Dal tool sarà sufficiente importare il progetto nel workspace è… il gioco è fatto, avremo il progetto pronto con tutte le dipendenze già disponibili (va bene, bisogna indicare ad eclipse il repository locale maven, ma lo facciamo solo una volta)

Per netbeans (versione 6+), il discorso è ancora più semplice, basta aprire il progetto. E di nuovo è già tutto pronto e configurato.

Esistono plugins per altri IDE, ma personalmente, non li ho mai provati.

 

Other stuff

Le funzionalità di maven non si fermano qui, solo per stuzzicarvi vi do degli esempi:

  1. Deploy (tramite cargo su container J2EE)
  2. Release (su scm con avanzamento automatico della versione)
  3. Generazione script ant (per la compilazione del progetto)
  4. E tutto quello che trovate qui: http://maven.apache.org/plugins/index.html

In ogni caso, per chi fosse interessato ad un uso più spinto, vi consiglio di andare su http://maven.apache.org/

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *