1. Maven
Project Management Framework
Fulvio Di Marco
fulvio.dimarco@epocaricerca.it

2. Maven
Sommario

Introduzione

Obiettivi e caratteristiche principali

POM: Project Object Model

Un esempio reale con Fatturazione Elettronica

Riferimenti

3. Maven
Odi et amo...
[ Catullo, Carme 85 ]

4. Maven
In poche parole, cos'è Maven?

In Yiddish ed Ebraico: meyvn/mevin, accumulatore di conoscenza

Strumento completo per la gestione di progetti software Java

Compilazione del codice, distribuzione, documentazione e collaborazione

Tentativo di applicare pattern consolidati e collaudati all'infrastruttura di build dei
progetti

Apache Software Foundation, Open source

“Scusa, io sono un manager, non ci sto capendo niente”:
"Maven è uno strumento dichiarativo per la gestione dei progetti Java
che permette di ridurre il tempo totale di sviluppo dei progetti (time-to-
market) attraverso un efficace utilizzo delle sinergie disponibili.
Maven permette di ridurre il numero delle risorse umane e
contemporaneamente permette di ottenere elevate efficienze
operative"

5. Maven

Coerenza

Standardizzazione di un insieme di best practice

Adesione ad uno standard → Minore opacità

Riusabilità

Agilità

Abbattimento dei costi di riuso

Semplificazione del processo di creazione e integrazione di un singolo
componente in un multi-project build

Abbattimento dei costi di project-switch per gli sviluppatori

Manutenibilità

Abbattimento dei costi di implementazione/manutenzione del processo di
build

Incremento della manutenibiltà come conseguenza dell'adozione di un
modello comune di build

6. Maven: i principi
Cristopher Alexander (1977):
“patterns help create a shared language for communicating
insight and experience about problems and their solutions”

Convenzioni sulla configurazione

Dichiaratività

Riutilizzo della logica di build

Gestione e organizzazione delle dipendenze

7. Convenzioni sulla configurazione

Organizzazione standard della directory dei progetti
(collocazione del codice sorgente, dei file di
configurazione, della documentazione, degli artefatti
generati)

Archetype

Progetto Maven (1) → (1) Archivio distribuibile

Separation Of Concerns (SoC)!

Convenzioni sui nomi

Es: spring-aspects-3.0.2.RELEASE.jar

8. Maven Archetype
Project templating toolkit

Archetipo:“modello a a partire dal quale tuttialtrialtri oggetti
Archetipo: “modello partire dal quale tutti gli gli oggetti dello
stesso stesso tipo sono creati”.
dello tipo sono creati”.

 Definizione della struttura di progetto.
Definizione della struttura di progetto.

 Best practices
Best practices
Consistenza, portabilità, riutilizzo, apprendimento,
Consistenza, portabilità, riutilizzo,


trasferibilità.
apprendimento, trasferibilità.

Archetipi pre-esistenti o custom per la propria organizzazione

Archetipi pre-esistenti o custom per la propria
mvn organizzazione
mvn archetype:generate -DgroupId=it.epoca -DartifactId=seminar-
archetype:generate -DgroupId=it.epoca -DartifactId=seminar-
j2ee-project -DarchetypeGroupId=org.jboss.weld.archetypes
j2ee-project -DarchetypeGroupId=org.jboss.weld.archetypes
-DarchetypeArtifactId=weld-jsf-jee -DarchetypeVersion=1.0.0-BETA1
-DarchetypeArtifactId=weld-jsf-jee -DarchetypeVersion=1.0.0-BETA1
-DinteractiveMode=false
-DinteractiveMode=false

9. Maven Archetype
src/main/java Application/Library sources
src/main/resources Application/Library
src/main/filters resources filter files
Resource
src/main/assembly Assembly descriptors
src/main/config Configuration files
src/main/webapp Web application sources
src/test/java Test sources
src/test/resources Test resources
src/test/filters Test resource filter files
src/site Site
LICENSE.txt Project's license
README.txt Project's readme

10. Dichiaratività

Per design, Maven è un framework “progetto-
centrico” e il POM (Project Object Model) è la
descrizione di un singolo progetto.

Qualsiasi aspetto viene specificato e configurato
all'interno del file pom.xml ubicato nella radice di
progetto.

E' mediante il POM che Maven gestisce ogni singolo
aspetto e stadio del ciclo di vita del progetto.

11. POM: Project Object Model
“Building the build”
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>it.epocaricerca</groupId>
<artifactId>maven-seminar</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>

12. POM: Project Object Model
“Building the build”

Informazioni relative al progetto 
Reportistica e copertura dei test

Parentela 
Javadoc

Profili 
Issue tracking

Dipendenze 
Continuous Integration

Plugins 
Mailing list

Infrastruttura di build 
Project Team

Generazione del sito 
Code Analysis

Source Control Management

13. Riutilizzo della logica di build

Riutilizzo → Incoraggiamento alla SoC

Incapsulamento della logica di build in appositi plugin (cross-project)

Coordinamento dell'esecuzione di tali plugin

14. Gestione e organizzazione delle
dipendenze

Artifact (Artefatto): “A specific piece of software”

jar, war, sar, ear

Dipendenza: riferimento ad un artefatto specifico
dislocato in un preciso repository remoto.

Maven interpreta le coordinate delle dipendenze
esplicitate nel POM e cerca di soddisfare tali riferimenti
cercando gli artefatti richiesti nei repository remoti
disponibili nel contesto di progetto.

Se la dipendenza richiesta viene localizzata, Maven
provvede al download e all'installazione presso il
repository locale.
Dipendenze logiche

15. Gestione delle dipendenze

Due tipi di repository: locale e remoti.

Durante il normale funzionamento, Maven, interagisce con il
repository locale; qualora però una dipendenza non sia presente
all'interno di tale repository, Maven si occupa di consultare i repository
remoti ai quali ha accesso, al fine di risolvere la dipendenza
mancante.

16. Gestione delle dipendenze
Apache Archiva

Apache Archiva

gestione di repository Maven utilizzato non solo per la
distribuzione intra-aziendale degli artefatti Maven

proxy verso repository remoti → riduzione overhead e
impegno di banda

17. Gestione delle dipendenze
Coordinate

Ciascuna dipendenza è univocamente identificata dai seguenti identificatori:

groupId: identifica univocamente un insieme di progetti appartenenti alla
stessa organizzazione, team, ...

es. javax, org.springframework, it.fe, ...

artifactId: indica il nome del progetto. In combinazione con il groupId
genera il nome univoco del progetto.

javax.persistence-api

org.springframework.core

it.fe.process-invoice

version: indica una specifica versione del progetto. Un repository Maven
può contenere molteplici versioni di uno stesso progetto.

18. Gestione delle dipendenze: scope
Ciascuna dipendenza ha uno scope.
Lo scope influisce su:

Transitività delle dipendenze

Classpath dei build task
Sei scope disponibili:

compile. Default scope. Disponibilità in tutti i classpath di un progetto.
Propagazione ai progetti dipendenti.

provided. La dipendenza è fornita da un'altra entità, come il JDK o un
container (ad esempio un AS). È disponibile solo per il classpath di
compilazione e non è transitivo.

runtime. La dipendenza non è richiesta a tempo di compilazione, ma solo
in esecuzione.

test. La dipendenza è richiesta solo durante la fase di test del progetto.

...

19. Lifecycle

Build lifecycle: il processo di build e distribuzione di un
determinato artefatto (progetto) è puntualmente specificato.

Tre lifecycle built-in: default, clean, site.

Ciascun build lifecycle è costituito da un differente insieme di
fasi, ove ciascuna fase rappresenta un passo nel lifecycle.
Ad esempio il default lifecycle:

validate – verifica che il progetto sia corretto e che tutte le informazioni necessarie siano disponibili

compile – compila il codice sorgente del progetto

test – test del codice sorgente compilato utilizzando uno unit testing framework appropriato.

package – assembla il codice compilato nel formato distribuile specificato, ad es. jar.

integration-test – assembla ed esegue il deploy del package in un ambiente dove eseguire i test di integrazione.

verify – esegue controlli per verificare la correttezza e la qualità del package generato.

install – installa il package nel repository locale in maniera tale che possa essere utilizzato come dipendenza da altri
progetti locali.

deploy – eseguito in un ambiente di integrazione o di produzione, copia il package presso il repository remoto al fine di
consentire la condivisione con altri sviluppatori o progetti

20. Maven vs. Ant

21. Maven in FE

22. Riferimenti
 supporto@epocaricerca.it
 Apache Maven Project: http://maven.apache.org,
Documentazione online:
– http://maven.apache.org/apache-maven.pdf

Archiva: The Build Artifact Repository Manager:
http://archiva.apache.org

Vincent Massol, Jason Van Zyl, “Better Build With Maven”,
Mergere Library Press