Maven : convention over configuration

1. Outil de construction
Convention vs Configuration

2. Introduction
• maven ... c’est quoi ?
• Pourquoi maven ?
• maven... pour quoi faire ?
• maven... comment faire ?

3. C’est quoi maven ?

4. C’est quoi maven ?
• Outil de build
• Né de l’expérience des outils comme
Makefile, Ant, etc.
• En reprend les fonctionnalités
principales (gestion des
dépendances, script de
construction)
• Ajout de fonctions : test automatique,
génération de rapport
• Plugable

5. Pourquoi maven ?

6. Pourquoi maven ?
• Éviter les constructions manuelles
• Standardiser le modèle de projet
• Standardiser la chaîne de construction
• Automatiser le maximum
• Gérer les dépendances
• Faire plus que de la construction :
• Exécution des tests unitaires
• Génération de documentation
• Génération de rapports de tests, de couverture
code, d'analyses statique (checkstyle, PMD,
CPD, ...)

7. Pourquoi maven ?
• Gestion des dépendances entre projets
(dependency graph de m2eclipse)

8. Comment faire ?

9. Comment faire ?
• Convention != normes, obligations,
contraintes...
• Si tu veux configurer tu es libre mais
débrouille toi...
• KISS : Keep It Simple, Stupid
• Partir de rien, quand c'est possible
• Industrialiser au maximum
• Bien définir les dépendances, être
minimaliste

10. Comment faire ?
• pom.xml
• POM : Project Object Model
• Situé à la racine du projet
• Phase principales dans le cycle de vie de
Maven
• compile
• test
• package
• install
• deploy

11. Comment faire ?
• pom.xml
• POM : Project Object Model
• Situé à la racine du projet
• Phase principales dans le cycle de vie de
Maven
• compile
• test
• package
• install
• deploy

12. Comment faire ?
• Convention des répertoires
• /src : les sources du projet
• /src/main : code source et fichiers source
principaux
• /src/main/java : code source
• /src/main/resources : fichiers de ressource
• /src/test : fichiers de test
• /src/test/java : code source de test
• /src/test/resources : fichiers de ressources de test
• /src/site : informations sur le projet pour les rapports
• /src/main/webapp : webapp du projet
• /target : fichiers résultat, les binaires (du code et des
tests), les packages générés et les résultats des tests

13. Comment faire ?
• Configuration local
• $home
• .m2
• settings.xml
• repository
• libs

14. Comment faire ?
• Les commandes maven de base
• mvn install : compile le projet,
exécute les tests, met a disposition le
repository local
• mvn clean install : supprime le fichier
target et re-install
• mvn test : exécute les tests unitaire
du projet
• mvn eclipse:eclipse :génère
les .classpath et .project
• mvn site : génère le site du projet,
information général, rapport de test,
de qualité, ...(conf. pom.xml requise)

15. Comment faire ?
• Comment faire planter son projet maven ?
• En n’utilisant pas les conventions de Maven 2 (target,
héritage, répertoires src…)
• En ayant trop de sous modules avec des versions différentes
(naissance de nouveaux projets involontairement)
• En ayant trop de modules dans le même projet : pénalise la
performance
• En confondant dependencies et dependencyManagement
• En confondant plugins et pluginManagement
• En utilisant massivement antrun : empêche la réutilisation
• En utilisant à outrance les profils : rend dépendant de
l’environnement
• En utilisant trop le reporting de qualité sur des projets déjà
existant
• En mettant tout et n’importe quoi dans le POM
• En faisant des releases à la main

16. Comment faire ?
• Comment réussir son projet maven ?
• Utiliser l’héritage « naturel »
• Bien définir les dépendances, être
minimaliste !
• Fixer les dépendances dans le
dependencyManagement
• On peut utiliser aussi le plugin
reactor pour ne compiler que ce qui
as été modifié

17. L’intégration continue
• But : prévenir les bogues, améliore le cycle de
développement en réduisant les corrections en phase
de robustesse
• Intégration, test, contrôle de qualité
• Lancement de la construction à chaque commit possible
ou paramétré avec un délai
• Les logiciels :
• Hudson : coder à la base pour le projet Glassfish,
très en vogue et très intuitif, facile à mettre en
œuvre. Pour le tester en local : java –jar hudson.war
(déployer sur http://localhost:8080/)
• Bamboo : payant
• Teamcity de Jetbrain, « build incassable »
• Continuum : Apache, vieux produit pas très
conviviale mais bien intégrer avec maven
• CruiseControl : vieux produit !

18. Joel test...
Utilisez-vous un gestionnaire de source ?!
Vos binaires sont-il assemblé en une fois ?!
Vos binaires sont-il produits quotidiennement ?!
Avez-vous un gestionnaire d’anomalie ?!
Le code est-il corrigé avant d’être étendu ?!
Avez-vous un planning à jour ?!
Avez-vous des spécifications ?!
Vos développeurs sont-il dans un lieu calme ?!
Avez-vous les meilleurs outils pour votre budget ?!
Avez-vous des testeur ?!
Les recrues écrivent-elles du codes ?!
Faites-vous des tests utilisateurs complet?