Maven - Aprile 2010
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Maven - Aprile 2010

on

  • 3,500 views

 

Statistics

Views

Total Views
3,500
Views on SlideShare
3,107
Embed Views
393

Actions

Likes
1
Downloads
52
Comments
0

6 Embeds 393

http://fdimarco.wordpress.com 367
http://www.slideshare.net 15
http://fulviodimarco.tumblr.com 5
http://flavors.me 4
http://www.tumblr.com 1
url_unknown 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Maven - Aprile 2010 Presentation Transcript

  • 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