« On ne présente plus Maven ! »

Et pourtant, je m’aperçois que beaucoup (moi y compris) ont du mal avec ce super outil !!

Maven est un outil de build né de l’expérience acquise sur le marché des outils de build comme Makefile, Ant etc. Il en reprend les fonctionnalités principales en y ajoutant d’autres presque indispensables : test automatique, génération de rapport et j’en passe et des meilleurs.

En juin 2009, Arnaud Héritier (commiter chez Apache Maven) est venu nous présenter le projet Maven 2 au ch’ti JUG. Je souhaite vous faire part de ce que j’en ai retenu. Histoire de rallier quelques développeurs Java à la communauté utilisatrice de l’outil.

D’abord pourquoi Maven ?

• Éviter les reconstructions manuelles
• Automatiser le maximum
• Standard de la chaîne de construction
• Gestion des dépendances (librairies, API, dependencyManagement, scope import)
• Découplage en différent module
• Maven n’est pas seulement un outil de construction, et pas seulement le remplaçant de Ant

Et pourquoi pas Ant ?

• Script trop long (grande taille de fichier) et trop complexe
• Faiblesse du point de vu de la maintenance
• Problème de lecture du à l’import d’autre script

Pourquoi l’utiliser en entreprise ?

• Standard de fait !
• Rationalisation du coût de construction
• Facilité de l’intégration continue
• Utilisation des fonctions de qualité de code
• Automatisation du processus de release (passage de tests, construction du WAR)
• Partager le paramétrage : juste descriptif, logique d’héritage avec le Pom parent

Mise en place de Maven :

• KISS : Keep It Simple, Stupid !
• Partir de rien !
• Éviter la « sur architecture » !
• Créer des référentiels (proxy) pour sécurisez : gestionnaire de proxy, pour éviter le problème réseaux lors de téléchargement de nouvelle librairies par les équipes de développement
• Utiliser Sonatype Nexus ou Frog Artefact (ou Apache Archiva) pour gérer le proxy
• Industrialiser au maximum
• Utiliser les plugins pour modifier le comportement de maven, oser créer des plugins
• Partager les modèles entres les équipes
• Utiliser les tests, et le reporting :
  • JUnit, TestNG – tests unitaires
  • Selenium, Cannoo – tests d’IHM
  • Fitnesse, Greenpepper – tests fonctionnels
  • SOAUI – Tests des webservices

• Démarche de qualité :
  • Checkstyle – Uniformisation du code (Attention au différence entre règles IDE et règles Maven)
  • PMD, Findbug, Clirr – Déceler les mauvaises pratiques
  • Cobertura, Clover – Couverture de code par les tests

• Deux visions de démarche de qualité :
  • Le contrôle : la construction ne passe pas si certain critère ne sont pas atteints
  • Le reporting : site web ou serveur dédié, Exemple : Sonar ; ne casse pas le build par des contraintes

Les serveurs d’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 !

Comment planter son projet avec Maven ?

• En n’utilisant pas les conventions de Maven 2 (target, héritage, répertoires src…)
• En ayant trop de sous modules avec des version 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

Comment réussir son projet avec 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é

Les concurrents de Maven :

• ANT + IVY
• Easy Ant
• Gant
• Gaddle

Remarque : ils utilisent tous une logique de scripting (la souplesse au prix du sacrifice de la standardisation).

Maven 2.1.0 et après :

• Sortie de Maven 2.2 : prochainement, avant ou pendant l’été (Java 5 obligatoire pour l’exécution de Maven)
• Maven 3 en cours de développement (Non, ne fuit pas !) :
  • (car) Compatibilité ~ 100 % avec Maven 2
  • Correction de l’écueil : encapsulation au IDE (Eclipse en particulier)
  • Cycle de vie prédictible
  • Refonte de la gestion des Artifacts (Mercury)
  • Gestion http / WebDav
  • Abstraction du descripteur de projet
  • Migration du framework d’injection de dépendance Plexus vers Guice (de Google, se prononce « Juice »), ou XBeans (XBR ?)

La documentation :

• Definitive Guide (bientôt en français) : http://www.sonatype.com/products/maven/documentation/book-defguide
• Better Builds with Maven
• Maximum Maven : http://blog.xebia.fr/2009/04/30/maximum-maven/

Ne pas hésiter à créer s’est propre plugin Maven :

• http://dcabasson.developpez.com/articles/java/maven/introduction-maven2/
• http://blog.aheritier.net/les-nouveautes-de-maven-210/
• Plugin Maven pour Eclipse (m2eclipse) : http://docs.codehaus.org/display/M2ECLIPSE/Home

Connaissance général sur Maven :

• POM : Project Object Model
• Phase principales dans le cycle de vie de Maven = compile, test, package, install, deploy
• Convention de répertoire (source wikipedia) :
  • /src : les sources du projet
  • /src/main : code source et fichiers source principaux
  • /src/main/java : code source
  • /src/main/resources : fichiers de ressources (images, fichiers annexes..)
  • /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 et/ou les rapports générés suite aux traitements effectués
  • /src/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

Personnellement j’utilise Maven 2 dans ma société et j’en suis très content, les deux seul soucis que je peut reproché à l’outil c’est qu’il est long à exécution et que le pom.xml peut devenir vite très complexe.

NEWS !

• Un livre en français vient de sortir sur le sujet chez Pearson : Apache Maven.
• Arnaud H.  dans lescastcodeurs nous parle de Maven dans la rubrique « Les mains dans le cambouis » .