Apache Maven (Fr)

3 530 vues

Publié le

Apache maven le livre

Publié dans : Formation
0 commentaire
2 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
3 530
Sur SlideShare
0
Issues des intégrations
0
Intégrations
7
Actions
Partages
0
Téléchargements
339
Commentaires
0
J’aime
2
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Apache Maven (Fr)

  1. 1. Référence Apache Nicolas De loof et Arnaud Héritier Préface de Jason Van Zyl Réseaux et télécomProgrammationGénie logiciel Sécurité Systèmed’exploitation
  2. 2. Apache MavenNicolas De loofet Arnaud Héritier Avec la contribution des membres francophones de la communauté Maven, en particulier Stéphane Nicoll, Vincent Siveston, Raphaël Piéroni, Hervé Boutemy, Jérôme Van Der Linden, Antonio Goncalves et François Le Droff
  3. 3. Pearson Education France a apporté le plus grand soin à la réalisation de ce livre afin de vous four-nir une information complète et fiable. Cependant, Pearson Education France n’assume de respon-sabilités, ni pour son utilisation, ni pour les contrefaçons de brevets ou atteintes aux droits de tiercespersonnes qui pourraient résulter de cette utilisation.Les exemples ou les programmes présents dans cet ouvrage sont fournis pour illustrer les descriptionsthéoriques. Ils ne sont en aucun cas destinés à une utilisation commerciale ou professionnelle.Pearson Education France ne pourra en aucun cas être tenu pour responsable des préjudicesou dommages de quelque nature que ce soit pouvant résulter de l’utilisation de ces exemples ouprogrammes.Tous les noms de produits ou marques cités dans ce livre sont des marques déposées par leurspropriétaires respectifs.Apache, Apache Maven, Maven, and the Apache Maven logo are trademarks of The ApacheSoftware Foundation. Used with permission. No endorsement by The Apache Software Foundationis implied by the use of these marks.Publié par Pearson Education France47 bis, rue des Vinaigriers75010 PARISTél. : 01 72 74 90 00www.pearson.frMise en pages : TyPAOISBN : 978-2-7440-4098-6Copyright © 2009 Pearson Education FranceTous droits réservésAucune représentation ou reproduction, même partielle, autre que celles prévues à l’article L. 122-5 2˚ et 3˚ a) du code de lapropriété intellectuelle ne peut être faite sans l’autorisation expresse de Pearson Education France ou, le cas échéant, sansle respect des modalités prévues à l’article L. 122-10 dudit code.All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic ormechanical, including photocopying, recording or by any information storage retrieval system, without permission fromPearson Education, Inc.
  4. 4. Table des matièresTable des listings ................................................................................................................ XIPréface ................................................................................................................................ XIIIAvant-propos ...................................................................................................................... XVII Contenu ....................................................................................................................... XIX Partie I Premiers pas avec Maven1 Introduction .................................................................................................................. 3 Prologue ...................................................................................................................... 3 Partageons ! ................................................................................................................ 4 Les fourmis à la rescousse .......................................................................................... 6 Et Maven dans tout ça ? .............................................................................................. 7 Que fait Maven ? ........................................................................................................ 8 La clé du mystère ........................................................................................................ 10 Convention plutôt que configuration ..................................................................... 11 Décrire plutôt que programmer ............................................................................. 12 POM ...................................................................................................................... 12 Pourquoi adopter ces conventions ? ...................................................................... 15 La force de Maven ...................................................................................................... 162 Au-delà de java.lang .................................................................................................. 17 Des JAR sous CVS ...................................................................................................... 17 Quand le répertoire lib explose ........................................................................... 17 Identification univoque ......................................................................................... 20 Dépôt de bibliothèques ......................................................................................... 21 Avis aux amateurs de casse-tête ................................................................................. 22 L’ami de mon ami… ............................................................................................. 23 Testons un peu ............................................................................................................ 26 Les "scopes" .......................................................................................................... 27
  5. 5. IV Apache Maven Une arme à double tranchant ...................................................................................... 27 L’analyse des dépendances ................................................................................... 30 Conclusion .................................................................................................................. 323 Un peu plus que compiler ............................................................................................ 33 Êtes-vous prêt pour Java 7 ? ....................................................................................... 33 Plugins ........................................................................................................................ 35 Propriétés .................................................................................................................... 36 Quand Java ne suffit plus ............................................................................................ 38 Où placer les sources ............................................................................................ 39 Ajouter un plugin .................................................................................................. 40 Plugin et tâches ..................................................................................................... 41 Compiler… en JavaScript ........................................................................................... 42 Invoquer un plugin ................................................................................................ 45 Cycle de vie .......................................................................................................... 45 Générer du code .......................................................................................................... 48 Produire autre chose qu’un JAR .................................................................................. 50 Des plugins pour tout ? ............................................................................................... 52 Conclusion .................................................................................................................. 534 Mettre en place des tests unitaires .............................................................................. 55 Tester ? Pour quoi faire ? ............................................................................................ 55 Automatisons ! ...................................................................................................... 56 Utiliser un framework de test ................................................................................ 58 Les tests sous Maven .................................................................................................. 60 Le scope "test" ...................................................................................................... 61 Le développement piloté par les tests ................................................................... 62 Pas de JAR sans tests réussis ................................................................................. 65 Réutiliser notre outillage de test ........................................................................... 65 L’intégration continue ................................................................................................. 67 Continuum ............................................................................................................ 68 Hudson .................................................................................................................. 69 Lequel choisir ? ..................................................................................................... 70 Conclusion .................................................................................................................. 715 Mettre en place des tests d’intégration....................................................................... 73 Des tests unitaires… de moins en moins unitaires ..................................................... 73 Qu’est-ce qu’un test "unitaire" .............................................................................. 74 Les profils ................................................................................................................... 75 S’adapter à l’environnement ................................................................................. 76 Désactiver à la demande ....................................................................................... 78 Tester l’accès à une base de données .......................................................................... 79
  6. 6. V Utiliser des tests fonctionnels ..................................................................................... 82 Tester la charge et les performances ........................................................................... 84 Intégration continue .............................................................................................. 85 Conclusion .................................................................................................................. 86 Partie II Maven en entreprise6 Gestion avancée des dépendances ............................................................................... 91 Oracle, quand tu nous tiens ........................................................................................ 91 Un moteur de recherche pour Maven .................................................................... 92 Pourquoi publier un POM sans JAR ? ...................................................................... 93 Installer le fichier manquant ................................................................................. 94 Les dépendances "System" ................................................................................... 94 Créer son propre dépôt ............................................................................................... 96 Contrôle d’identité, vos papiers s’il vous plaît ! ................................................... 96 Rebelote : mais où est javax.jms ? ........................................................................ 97 Gérer son dépôt privé ................................................................................................. 98 Métadonnées ............................................................................................................... 100 Passer à un "véritable" gestionnaire de dépôt ............................................................. 100 Un miroir de central ............................................................................................. 101 Un gestionnaire d’artefacts ................................................................................... 101 Conclusion .................................................................................................................. 1067 Quand le projet devient trop lourd ............................................................................. 107 Un projet – un artefact ................................................................................................ 107 Héritage ................................................................................................................. 108 Packaging d’un POM parent ................................................................................. 109 Parent "naturel" ..................................................................................................... 110 Mutualiser ................................................................................................................... 111 Gestion des dépendances ...................................................................................... 111 Gestion des plugins ............................................................................................... 112 Diviser pour régner ..................................................................................................... 114 Héritage "naturel" ................................................................................................. 115 Et l’intégration continue ? ..................................................................................... 115 Un gros projet vs plein de modules ....................................................................... 116 Les modules au service de l’architecture .............................................................. 117 Conclusion .................................................................................................................. 117
  7. 7. VI Apache Maven8 Maven et JEE ................................................................................................................ 119 Java Entreprise Edition ............................................................................................... 119 Construire une archive web WAR ......................................................................... 120 Construire un EJB ................................................................................................. 123 Construire une archive d’entreprise EAR ............................................................. 126 Tester .......................................................................................................................... 128 Selenium ............................................................................................................... 128 Cargo ..................................................................................................................... 132 Soyons pragmatiques, soyons productifs .................................................................... 134 Une application web "sur place" ........................................................................... 134 Une application web sans assemblage .................................................................. 135 Ne plus sortir de l’IDE .......................................................................................... 135 Tester les EJB ........................................................................................................ 137 JEE6 .......................................................................................................................... 137 Conclusion .................................................................................................................. 1399 Maven et les IDE........................................................................................................... 141 Un plugin Maven pour Eclipse ............................................................................. 141 Maven vu depuis l’IDE ......................................................................................... 142 Eclipse ........................................................................................................................ 143 Installation ............................................................................................................ 143 Import d’un projet Maven ..................................................................................... 143 Prise en main ......................................................................................................... 144 Gestion du POM ................................................................................................... 145 Intégration des plugins Maven .............................................................................. 147 Et la cerise… ......................................................................................................... 148 Interrogations ........................................................................................................ 149 Intellij Idea .................................................................................................................. 149 Import d’un projet Maven ..................................................................................... 149 Gestion du POM ................................................................................................... 150 Intégration des plugins Maven .............................................................................. 152 Bonus .................................................................................................................... 152 NetBeans ..................................................................................................................... 153 Prise en main ......................................................................................................... 153 Import d’un projet Maven ..................................................................................... 153 Gestion du POM ................................................................................................... 154 Intégration des plugins Maven .............................................................................. 154 Bonus .................................................................................................................... 154 Délibération du jury .................................................................................................... 155 Conclusion .................................................................................................................. 156
  8. 8. VII10 Le jour J : la livraison ................................................................................................ 157 Stratégie de livraison .................................................................................................. 157 Première livraison ................................................................................................. 157 Deuxième livraison ............................................................................................... 158 Troisième livraison ............................................................................................... 158 Documentation ...................................................................................................... 159 Le plugin release ...................................................................................................... 160 Étape 1 : préparation ............................................................................................. 160 Étape 2 : livraison ................................................................................................. 161 Et si ça foire ? ....................................................................................................... 163 Notre prochaine version ........................................................................................ 163 Tester des candidats .................................................................................................... 163 Urgence ! .................................................................................................................... 165 Au-delà de l’intégration continue ............................................................................... 166 Conclusion .................................................................................................................. 168 Partie 3 Encore plus loin avec Maven11 Utiliser un outil non supporté.................................................................................... 171 Un outil maison .......................................................................................................... 171 Réutiliser l’existant ............................................................................................... 172 Retour dans un monde de scripts ? ....................................................................... 174 Créer un plugin ........................................................................................................... 174 Pas de panique ! .................................................................................................... 174 Des paramètres pour le plugin .............................................................................. 176 Un modèle dynamique .......................................................................................... 177 Plexus .................................................................................................................... 178 Des classes et des royaumes… ............................................................................. 180 Au-delà de Java ..................................................................................................... 183 Tester notre plugin ...................................................................................................... 185 Plugin testing harness ........................................................................................... 186 Plugin invoker ..................................................................................................... 187 Conclusion .................................................................................................................. 18912 L’assurance qualité..................................................................................................... 191 Audit de code .............................................................................................................. 191 Analyse statique .................................................................................................... 192 Analyse dynamique ............................................................................................... 195
  9. 9. VIII Apache Maven Les rapports Maven .................................................................................................... 198 Autre chose que du HTML ................................................................................... 200 Exploiter notre gestion documentaire ......................................................................... 201 68 %, qui dit mieux ? ............................................................................................ 202 L’entropie augmente ............................................................................................. 202 Maîtrise de S ......................................................................................................... 203 Sonar ..................................................................................................................... 204 Conclusion .................................................................................................................. 20713 Respecter un format de distribution......................................................................... 209 D’où vient ce JAR ? ..................................................................................................... 209 Numéro de construction ........................................................................................ 210 Numéro de révision ............................................................................................... 211 Utiliser le MANIFEST .......................................................................................... 212 La confiance règne… .................................................................................................. 214 L’EAR ne suffit pas .................................................................................................... 216 Assemblage du livrable ......................................................................................... 217 L’intégration continue produit notre livrable ........................................................ 219 L’œuf ou la poule ? ............................................................................................... 220 OSGi ? ........................................................................................................................ 221 Conclusion .................................................................................................................. 22214 Un nouveau projet démarre....................................................................................... 223 Mutualiser ................................................................................................................... 223 Qui paye ? ............................................................................................................. 224 Partager un POM parent ....................................................................................... 224 Copier-coller ......................................................................................................... 225 Copier et mutualiser ! ................................................................................................. 226 Un plugin qui crée des projets .............................................................................. 226 Un archétype ? ...................................................................................................... 228 Construire ses propres archétypes ......................................................................... 228 Gérer un projet de référence ....................................................................................... 229 Donner le meilleur de nous-mêmes ...................................................................... 230 Démarrer sur les bons rails ................................................................................... 230 Un support pour expérimenter .............................................................................. 231 Un support de démonstration ................................................................................ 232 Conclusion .................................................................................................................. 23315 Avons-nous fait le bon choix ? ................................................................................... 235 Les limites .................................................................................................................. 236 Points faibles ......................................................................................................... 236 Les plugins ............................................................................................................ 237
  10. 10. IX Le support ............................................................................................................. 238 Le coût de Maven .................................................................................................. 240 La concurrence ........................................................................................................... 240 Maven bon partout ? ............................................................................................. 240 Ant et Ivy ............................................................................................................... 242 EasyAnt.................................................................................................................. 242 Gradle..................................................................................................................... 242 Maven 1 ................................................................................................................. 244 Buildr ..................................................................................................................... 244 Un outil reconnu ......................................................................................................... 244 La communauté ..................................................................................................... 245 L’équipe de développement .................................................................................. 247 L’adoption en entreprise ....................................................................................... 247 L’avenir de Maven ...................................................................................................... 248 Maven 2.x ............................................................................................................. 249 Maven 3.x ............................................................................................................. 251 À qui appartient Maven ? ........................................................................................... 255 La fondation Apache ............................................................................................ 256 Sonatype ................................................................................................................ 256 Maven + OSGi = Tycho ........................................................................................ 257 Non, Sonatype n’est pas seul ! .............................................................................. 258 La garantie par l’open-source ............................................................................... 259 Conclusion .................................................................................................................. 26016 Nos recommandations ................................................................................................ 261 Les bonnes bases ........................................................................................................ 261 Commandement n° 1 : Les conventions de Maven tu suivras. ............................. 262 Commandement n° 2 : Simplicité tu choisiras. .................................................... 262 Commandement n° 3 : Au fur et à mesure de tes besoins, les outils nécessaires tu mettras en place. ............................................................................................... 264 Commandement n° 4 : De la sur-conception point tu ne feras. ........................... 265 Commandement n° 5 : Tes outils et ton build à jour tu maintiendras. .................. 266 Commandement n° 6 : Dans un projet, la même version tous les modules auront. ........................................................................................ 267 Commandement n° 7 : La gestion des versions tu centraliseras. .......................... 268 Commandement n° 8 : Comme la peste les dépendances optionnelles tu éviteras. ............................................................................................................. 268 Commandement n° 9 : Les SNAPSHOT tu utiliseras. .......................................... 269 Commandement n° 10 : L’IDE toujours tu privilégieras. ..................................... 269 Conclusion .................................................................................................................. 271
  11. 11. X Apache Maven17 Épilogue ....................................................................................................................... 273 Récapitulons ............................................................................................................... 274 Sortez de l’amateurisme ............................................................................................. 274 Le mot de la fin ........................................................................................................... 275 Qui est qui ? ................................................................................................................ 275 Les membres francophones de l’équipe Maven .................................................... 275 Les membres de la communauté Java ................................................................... 281 Post-scriptum ........................................................................................................ 28318 Lexique ........................................................................................................................ 285 Le petit monde open-source ....................................................................................... 285 Les concepts Maven ................................................................................................... 287 Ceux qui font tourner Maven ...................................................................................... 291 Et tout ce qui tourne autour… .................................................................................... 293 Liens utiles .................................................................................................................. 294Index ................................................................................................................................... 295
  12. 12. Table des listingsListing 1.1 : Les fichiers de compilation utilisés respectivement par Nicolas et par Arnaud 5Listing 1.2 : pom.xml ......................................................................................................... 7Listing 1.3 : Première exécution de Maven ........................................................................ 8Listing 1.4 : Seconde exécution de Maven… sans téléchargement cette fois .................... 9Listing 1.5 : L’en-tête du fichier POM ............................................................................... 13Listing 1.6 : Le bloc build du fichier POM ...................................................................... 14Listing 1.7 : Le bloc dependencies du fichier POM ....................................................... 14Listing 2.1 : Exécution de mvn dependency:tree ........................................................ 30Listing 3.1 : Production d’un binaire SWF ........................................................................ 51Listing 4.1 : Une méthode main de test ............................................................................. 57Listing 4.2 : Utilisation d’une bibliothèque utilitaire dans le test ...................................... 58Listing 4.3 : Utilisation de jUnit ......................................................................................... 59Listing 4.4 : Accès aux fichiers de test en tant que ressources ........................................... 61Listing 4.5 : Construction d’un test-jar en même temps que l’archive java du projet .. 66Listing 4.6 : Utilisation d’une dépendance exploitant la notion de classifier .................... 67Listing 5.1 : Un profil dédié aux tests GWT ...................................................................... 75Listing 5.2 : Activation d’un profil en fonction du système d’exploitation ........................ 77Listing 5.3 : Profil contrôlant le respect des règles de codage ........................................... 78Listing 5.4 : Préparation d’une base de données de test "propre" avec le plugin SQL ...... 80Listing 5.5 : Configuration du plugin Fitnesse ................................................................... 83Listing 6.1 : Erreur de résolution des dépendances ............................................................ 91Listing 7.1 : pom parent du projet ....................................................................................... 109Listing 7.2 : Utilisation du plugin Enforcer ....................................................................... 113Listing 8.1 : Descripteur de déploiement de notre EJB ...................................................... 124Listing 8.2 : Descripteur de déploiement de notre application web ................................... 125Listing 8.3 : Test Selenium en syntaxe Java ....................................................................... 129
  13. 13. XII Apache MavenListing 8.4 : Configuration du plugin Selenium ................................................................. 130Listing 8.5 : Configuration du plugin Surefire pour exécuter nos tests Selenium .............. 131Listing 8.6 : Configuration du plugin Cargo ...................................................................... 132Listing 8.7 : Lancement d’OpenEJB embarqué dans un test ............................................. 137Listing 11.1 : Utilisation du plugin AntRun ...................................................................... 173Listing 11.2 : En-tête POM du plugin documentaire ......................................................... 175Listing 11.3 : Notre classe Mojo de base ........................................................................... 176Listing 11.4 : Construction d’un royaume ClassWorlds dédié à l’exécution de GEACheck 182Listing 11.5 : Invocation par réflexion de l’outil GEACheck ............................................. 183Listing 11.6 : Le mojo GEACheck en version Groovy ...................................................... 184Listing 11.7 : Test unitaire pour un plugin, basé sur le plugin-testing-harness ...... 186Listing 11.8 : Pseudo-POM chargé lors du test .................................................................. 187Listing 11.9 : Configuration du plugin invoker ............................................................... 188Listing 11.10 : Script Groovy de contrôle de l’exécution .................................................. 188Listing 12.1 : Le descripteur de notre site .......................................................................... 199Listing 12.2 : Configuration du plugin Sonar ..................................................................... 205Listing 13.1 : Exploiter le numéro de construction de Hudson .......................................... 210Listing 13.2 : Obtenir le numéro de révision SVN ............................................................. 211Listing 13.3 : Ajout de métadonnées dans le MANIFEST ................................................. 213Listing 13.4 : Mise en place d’une signature GPG ............................................................. 215Listing 13.5 : Le fichier assembly ...................................................................................... 217Listing 13.6 : Invocation du assembly:single au cours de la construction du projet ... 219Listing 13.7 : Un POM dédié à l’assembly ........................................................................ 220Listing 14.1 : Un POM d’entreprise pour Geegol .............................................................. 225Listing 14.2 : Génération d’un nouveau projet à partir d’un archétype ............................. 226Listing 14.3 : Structure de fichiers générée ........................................................................ 227Listing 15.1 : Un script simple de build Gradle ................................................................. 243Listing 15.2 : Un POM Maven 3 basé sur les attributs XML ............................................. 254Listing 16.1 : Un profil pour éviter les plugins trop consommateurs sous m2eclipse ....... 270Listing 16.2 : Un profil pour activer le cycles de vie reconfigurable de m2eclise 0.9.9 .... 271
  14. 14. Préface Histoire de Maven Maven est né au sein du projet Jakarta Alexandria. Ce projet, aujourdhui arrêté, fût le terreau non seulement de Maven mais aussi dautres projets comme Gump et Forrest. Le premier import des sources du prototype eulieu en août 2001. Maven vécu pendant environ 5 mois au sein dAlexandria avant derejoindre sa nouvelle adresse dans le projet Turbine.Bien que Maven fît ses débuts dans Alexandria, le test en grandeur nature fut le projetTurbine. Turbine tentait de découpler ses couches persistance, service, et présentationweb dans des builds séparés et jétais exaspéré de devoir gérer de multiples scripts decompilation très semblables. Il ny avait pas de moyen simple à cette époque pour créerdes modèles de scripts Ant, chaque build semblait différent. Je trouvais cela incroyable-ment frustrant et futile : personne nétait intéressé de savoir comment la constructionseffectuait tant quelle fonctionnait et quelle était facile à utiliser. Linfrastructure dunprojet est incroyablement importante, mais sa valeur réside dans lapplication dévelop-pée. En conséquence le build est souvent négligé et tend à vous lâcher quand vous enavez le plus besoin, par exemple lors de la préparation dune livraison ou lorsqueplusieurs personnes interviennent sur le projet. Dans le projet Jakarta, il y a plusieursannées, il était rare quun build Ant fonctionne tel quel.Les développeurs de Turbine ont souffert lorsque jai essayé de faire fonctionnerMaven, ce que je regrette, mais jimagine mal comment un nouveau projet peut démar-rer et survivre si personne ne souffre. Je pensais que cétait pour leur propre bien (je suisconnu pour avoir une opinion ou deux sur le sujet) et, après quelques grincements dedents, Maven est arrivé à maturité. Cela me rappelle une de mes citations favorite deRalph Johsnon et Don Roberts dans Patterns for Evolving Frameworks :Les gens créent de labstraction en généralisant des exemples concrets. Toute tenta-tive de définir labstraction correcte sur papier sans développer et exécuter unsystème réel est condamnée à léchec. Personne nest aussi doué. Un framework estune conception réutilisable, donc il se construit en regardant les choses dont il estsensé être le modèle. Plus vous avez dexemples sous la main, plus le frameworkpourra être générique.
  15. 15. XIV Apache MavenJe ne savais pas vraiment à quoi le résultat final ressemblerait, mais je savais quil devaity avoir une meilleure façon de faire. Pour commencer, je savais ce que je voulais :m un modèle pour le projet, pour quil ny ait quun seul endroit où aller chercher linformation relative au projet ;m une structure standardisée pour quil ne soit pas nécessaire daller à la pêche aux bibliothèques, au code source et à la documentation.La chose suivante que je notais était que tous les JAR dont nous dépendions étaientstockés sous CVS. Nous perdions de la place en conservant plusieurs copies de biblio-thèques comme Xerces. À chaque fois quune nouvelle version de Xerces apparaissait,je devais mettre à jour chaque projet. Mais plus grave, sans gestion déclarative il nyavait aucun moyen deffectuer une analyse. Les gens ont tendance à sous-estimerlimportance dune gestion déclarative. Ils se disent que cest si simple de placer lesbibliothèques dans le gestionnaire de sources, mais essayez de décomposer votre grosprojet poubelle en composants réutilisables et maintenables, ou danalyser ce qui seranécessaire à lexécution entre toutes vos applications avec des dépendances communesdans la chaîne et vous serrez bien ennuyé. La vraie puissance de la gestion déclara-tive ne tient pas à léconomie de quelques octets de disque (quoique cela puisse êtresignificatif si on ny prend pas garde) mais à la possibilité danalyse. Une fois ungraphe de dépendances en place, tout devient possible. Mais retour à lhistoire :maintenant que la gestion déclarative des dépendances existait, il fallait rendre plussimple le partage des librairies. Juste après avoir créé Maven nous avons créé le réfé-rentiel Maven, un référentiel de librairies qui est utilisé aujourdhui par la plupart desdéveloppements Java.Beaucoup de personnes ont eu des soucis avec Maven 1, mais il fonctionnait générale-ment bien, et tous les outils dans leur première génération souffrent de divers défauts.La seule façon daller au delà est den prendre de la graine et de créer quelque chose demieux pour le coup daprès. Nous avons créé Maven 2.0, et après plusieurs années noussommes sur le point de publier Maven 3.0. Avec tous les retours que les développeursont reçu de la part de lincroyable communauté des utilisateurs de Maven, je pense quenous sommes arrivés à quelque chose de solide sur lequel nous pouvons itérer. Ne vousinquiétez pas : Maven 3.0 est 100 % compatible avec lexistant en Maven 2.0 :-) Nousavons désormais une compréhension très complète sur comment les organisations cons-truisent leurs applications, depuis le développement en passant par les tests et jusquà lamise en production. Ce sont toutes ces connaissances qui ont été utilisées pour créer lesbases de Maven 3.0.
  16. 16. Préface XVÀ propos de ce livreNicolas et Arnaud ont choisi, avec une approche légère et récréative, de proposer unguide aux utilisateurs novices, basé sur lhistoire dune start-up technologique qui fait lechoix dutiliser Maven. Le livre couvre toutes les phases du projet, de son originejusquà létape finale de livraison et de déploiement dun produit complet. Les lecteursdécouvrent progressivement les bonnes pratiques de Maven à travers les utilisations quenos experts en font et bénéficient de techniques puissantes quil faudrait sans cela desmois pour apprendre.Le livre Apache Maven nest pas seulement une introduction pratique à Maven, maiscest aussi un guide où chaque leçon est basée sur un exemple. Je pense quArnaud etNicolas ont réalisé un super travail, demandant beaucoup defforts. Je recommande sanshésitation cet ouvrage à toute personne sintéressant à Maven : cest un ouvrage de réfé-rence et de grande valeur pour la communauté Maven. Jason Van Zyl, Fondateur du projet Apache Maven
  17. 17. Avant-propos L’écriture d’un ouvrage technique n’est pas une tâche triviale, car il est facile de perdre le lecteur dans une avalanche de concepts théoriques ou de s’égarer dans des détails non fondamentaux. Décrire un outil comme Maven, ou tout simplement le définir clairement, tout en restant accessi-ble à tous, est encore plus délicat : soit on reste trop vague, et le lecteur n’a plus qu’àattendre le Chapitre 5 pour commencer à apprendre quelque chose de concret, soit ons’embarque dans de longues explications de principes et de concepts et le lecteurn’attendra jamais ce même Chapitre 5.Pour être honnête, je dois dire que les premières ébauches de cet ouvrage sont imman-quablement tombées dans ces travers, ce qui annonçait un livre bien peu pertinent pourles utilisateurs, qu’ils soient novices ou déjà expérimentés. Lorsque j’ai soumis lespremiers jets de ce projet à Arnaud, il m’en a rapidement fait la remarque et nous noussommes accordés sur la forme que nous voulions donner à ce livre.Mon objectif est de communiquer ma passion autour de ce projet open-source qu’estMaven, lequel réunit des développeurs aux parcours très différents. Les rencontres quej’ai faites dans cette communauté ont forgé mon approche de l’informatique. Avec cettemotivation, établir un dictionnaire impersonnel Maven-Français était exclu ; aussi j’airapidement choisi, en accord avec Arnaud, de privilégier une approche aussi didactiqueque possible, bâtie sur des exemples concrets issus de ma propre expérience du terrain.Il est difficile de sensibiliser les utilisateurs aux enjeux que Maven tente de gérer, alorsqu’ils y sont pourtant confrontés en permanence. Situation intéressante où tout lemonde rencontre un problème, mais, faute de mettre un nom dessus et d’en évaluerl’importance, celui-ci reste latent tout au long de la vie du projet, amenant parfois à dessituations critiques. Nous allons suivre ensemble la vie d’un projet fictif, bien que large-ment inspiré de situations réelles. Il passera par toutes les phases, du prototype écrit surun coin de table à l’application stratégique d’entreprise de grande envergure, ce quinous permettra de couvrir un très large éventail de situations.Plutôt que de décrire le rôle de Maven sur un projet, ou de vous accabler par un longexposé théorique sur ses concepts, je préfère au travers de cette démonstration un peu
  18. 18. XVIII Apache Mavenromancée vous montrer les difficultés concrètes auxquelles Maven s’attaque. Sur labase de ces exemples, parfois volontairement excessifs, je souhaite vous démontrer demanière ludique les avantages que Maven peut apporter à vos projets. Malgré les cari-catures proposées, de nombreuses situations vous sembleront familières. Derrière lafiction se cachent des cas bien réels, que je n’ai fait qu’amplifier, et beaucoup auront despoints communs avec vos propres difficultés. Ce parallèle vous donnera une imageréaliste de Maven et des conseils applicables dans les meilleurs délais.J’espère que vous apprécierez ce choix et que vous tirerez un enseignement pratique dutexte qui suit. En particulier, j’aimerais qu’arrivé au bout de votre lecture vous soyezconscient des objectifs visés par Maven, de sa philosophie et des raisons pour lesquellesil devient un élément clé de la boîte à outils du développeur. Enfin, je souhaite réussir àvous transmettre mon enthousiasme pour ce projet libre, auquel vous pouvez participeren rejoignant le forum pour y exposer vos interrogations, apporter de nouvelles idées,proposer des contributions de toutes sortes et participer à l’amélioration générale de cetoutil. Arnaud et moi avons commencé de cette façon avant de passer "de l’autre côté dumiroir", mais au quotidien nous restons comme vous, avant tout, des utilisateurs deMaven, soucieux de disposer d’un outil pertinent et productif. Nicolas De loof Lorsque Nicolas m’a contacté pour écrire un ouvrage sur Maven en fran- çais, j’ai commencé par me demander si cela en valait la peine. Certes, la documentation du produit est critiquable. Elle est très dispersée, et il est souvent difficile de trouver l’information utile lorsqu’on ne sait pas où lachercher entre le site web du projet1, ses nombreux plugins et son wiki2. Pourtant, ilexiste désormais deux ouvrages en anglais disponibles gratuitement sur la Toile pourcombler ces manques : Better Builds with Maven3, publié en 2006, et Maven : The Defi-nitive Guide4, publié en 2007 et régulièrement mis à jour. Alors qu’apporter de plusqu’une simple traduction en français de ces ouvrages ?Après de nombreuses années à utiliser et à préconiser Maven dans des contextes variés,j’avais envie de partager tout ce que j’avais pu emmagasiner comme bonnes pratiques etpointer sur les mauvaises que j’avais pu rencontrer. C’est sur ce principe que nousavons commencé avec Nicolas à bâtir le squelette de cet ouvrage. Fondé sur un projet1. http://maven.apache.org.2. http://docs.codehaus.org/display/MAVENUSER.3. MaestroDev (http://www.maestrodev.com).4. Sonatype, Inc. (http://www.sonatype.com).
  19. 19. Avant-propos XIXfictif, il retrace nos expériences ainsi que celles des personnes que nous avions croiséessur notre chemin et permet d’expliquer les enjeux de Maven dans un projet et dans uneentreprise. Même si nous n’avons pas recherché l’exhaustivité dans les cas traités, telle-ment ils peuvent être nombreux, nous avons essayé de faire apparaître les plus fréquentsou les plus épineux que nous ayons eus à résoudre. Nous avons axé nos efforts sur laprésentation et la compréhension des concepts plutôt que sur le détail du paramétrage,lequel peut évoluer périodiquement.J’espère que cet ouvrage saura autant vous divertir que vous former sur cet outil completafin qu’il ne soit plus jamais complexe à vos yeux. Arnaud HéritierContenuCet ouvrage se compose de quatre parties :m La première, du Chapitre 1 au Chapitre 5, aborde les concepts fondamentaux de Maven et leur mise en œuvre pratique. Nous avons choisi de mettre en scène de manière très explicite et souvent exagérée les problèmes que Maven tente de prendre en charge, afin que cette première partie soit aussi didactique que possible.m La deuxième, du Chapitre 6 au Chapitre 10, exploite des fonctionnalités plus avan- cées de Maven pour traiter des besoins orientés "gros projets d’entreprise" mais tout aussi délicats. Cette partie s’adresse typiquement aux développeurs intervenant sur des projets JEE (Java Enterprise Edition) en entreprise.m La troisième regroupe les Chapitres 11 à 15 et couvre des facettes plus spécialisées et moins mises en avant de Maven, mais que nous considérons comme tout aussi essentielles. Vous verrez alors que Maven ne se résume pas comme on le lit souvent à "un outil de compilation".m Pour terminer cet ouvrage le Chapitre 16 sera l’occasion de résumer les éléments clés présentés, de vous donner nos recommandations, bonnes et mauvaises prati- ques à connaître pour tirer le meilleur de Maven. Par ailleurs, nous nous essayerons à l’exercice acrobatique de la boule de cristal en vous présentant l’avenir du projet Maven. Nous indiquerons comment aller au-delà de ce livre en participant à la communauté qui épaule ce projet open-source. Le Chapitre 17 conclura le récit de notre histoire et vous présentera les personnes qui nous ont inspiré les différents protagonistes.Un dix-huitième chapitre vous propose un lexique qui éclaircit les mots quelques peuabscons utilisés dans cet ouvrage.
  20. 20. Partie IPremiers pas avec Maven
  21. 21. 1 IntroductionCommençons donc notre récit par l’inévitable mise en garde : toute ressemblance avecdes personnes ou des situations existantes ou ayant existé ne serait que fortuite…Prologue Nicolas et Arnaud se sont rencontrés au cours d’une confé- rence organisée par un Java User Group. Faisant connais- sance autour d’un verre, ils évoquent les souvenirs de leurspremiers pas avec Java, devenu depuis leur plateforme de prédilection. Un Java Develo-pment Kit dans une version qui fait sourire aujourd’hui, et les bons vieux "Hello World"qui initient tout développeur à un nouveau langage. De nombreux souvenirs qui rappel-lent qu’on a tous débuté un jour, rencontré les mêmes problèmes et commis les mêmeserreurs idiotes que l’on dénonce aujourd’hui.La première application un peu intéressante de Nicolas était un splendide outil degestion de sa liste de courses. D’un naturel assez désorganisé, Nicolas n’a jamais réussià mémoriser toute la liste. Il lui est même déjà arrivé de l’oublier ou pire, d’oublier toutsimplement de faire les courses. Son application était donc un extraordinaire pense-bête, qu’il lançait à l’avance et qui lui envoyait fièrement, dix minutes avant son départdu bureau, un message de rappel avec la liste des courses. Autrement dit, un outil derêve totalement indispensable, à tel point que le code de ce monument de l’informatiqueest respectueusement conservé quelque part.
  22. 22. 4 Premiers pas avec Maven Partie IArnaud, confronté au même souci et amusé par cette solution de pur geek, lui demandes’il a toujours son programme et s’il peut en faire une copie pour satisfaire sa curiosité– la geekitude est dangereusement contagieuse !Partageons !De retour à la maison, Nicolas fouille dans ses archives et en retire une vieille disquette(vous savez, ces carrés de plastique qu’on utilisait "dans le temps", avant que la cléUSB et Internet ne les fassent disparaître). Il envoie donc le trésor tant convoité àArnaud.Pour vous faire une meilleure idée de cette exceptionnelle construction logicielle, voiciles fichiers qui la constituent :Figure 1.1La structure originale du projet "noubliepaslalistedescourses".Arnaud, qui, semble-t-il, n’a vraiment que cela à faire de son temps libre, se jette surcette magnifique relique des années Java 1.1 et tente de le compiler. Seulement, Arnaudest un utilisateur Mac. Le fichier BAT qui compile et assemble le logiciel en une archiveJava JAR est inexploitable sur son système. Arnaud n’est pas du genre à se décourager sifacilement, aussi écrit-il un fichier de compilation adapté à son environnement afin depouvoir tester ce chef-d’œuvre de l’informatique.Deux jours plus tard, profitant d’un peu de rangement, Nicolas retrouve une autredisquette contenant une version plus avancée de son logiciel, qui utilise les fonctions
  23. 23. Chapitre 1 Introduction 5d’une bibliothèque utilitaire pour lire le fichier contenant la liste des courses. Il l’envoiedonc à Arnaud, qui une nouvelle fois doit écrire son propre fichier de compilation.Le "projet" étant trivial, la traduction du build.bat en build.sh est rapide. Voici pourcomparaison les deux fichiers utilisés respectivement par Nicolas et Arnaud. Les diffé-rences sont minimes mais nécessitent une reprise manuelle à chaque modification,pouvant introduire des disparités, voire des incompatibilités entre les environnementsde nos deux compères, qui peuvent leur faire perdre un temps précieux.Listing 1.1 : Les fichiers de compilation utilisés respectivement par Nicolas et par Arnaud‘@echo off #!/bin/bashset JAVA_HOME=C:jdk1.3 export JAVA_HOME=/opt/jdk1.3set PATH=%JAVA_HOME%bin export PATH=$JAVA_HOME/binset CLASSPATH=libmail.jar;lib export CLASSPATH=lib/mail.jar:lib/➥activation.jar ➥activation.jarmkdir build mkdir buildjavac -d build src*.java javac -d build src/*.javajar cf noubliepaslalistedescourses.jar jar cf noubliepaslalistedescourses.jarbuild*.class build/*.classDe nombreux projets industriels ou communautaires sont confrontés à ce mêmeproblème et sont obligés de maintenir deux versions (ou plus) du script de constructiondu logiciel, soit parce que l’équipe n’est pas homogène, soit parce que l’environnementde test ou de production n’est pas équivalent à celui de développement. Même sur dessystèmes d’exploitation identiques, les outils peuvent être installés à des emplacementsdifférents, ce qui oblige à prévoir dans le script un ensemble de propriétés que chacundevra renseigner en fonction de sa configuration.Sur Unix, ce problème a été traité depuis longtemps par l’outil make. Cependant, celui-ci n’est pas facilement exploitable sur les machines Windows, omniprésentes commepostes de développement.Arnaud raconte ses déboires à son collègue Olivier. Ce dernier, utilisateur du systèmeSolaris, s’est souvent trouvé face à ce problème ; il lui propose d’utiliser un fichier decommande universel, basé sur l’outil Apache Ant.
  24. 24. 6 Premiers pas avec Maven Partie ILes fourmis à la rescousseQu’est-ce que c’est que ce "Ant" ? Faisons un détour par Wikipédia pour nous en faireune idée : INFOAnt est un projet open-source de la fondation Apache, écrit en Java, qui vise le développe-ment d’un logiciel d’automatisation des opérations répétitives tout au long du cycle dedéveloppement logiciel, à l’instar des logiciels Make1.Le nom est un acronyme pour Another Neat Tool (un autre chouette outil).Ant est principalement utilisé pour automatiser la construction de projets en langage Java,mais il peut l’être pour tout autre type d’automatisation dans n’importe quel langage.Parmi les tâches les plus courantes, citons la compilation, la génération de pages HTML dedocument (Javadoc), la génération de rapports, l’exécution d’outils annexes (checkstyle,findbugs, etc.), l’archivage sous forme distribuable (JAR, etc.).Ant a connu un succès exceptionnel et occupe une place de choix dans la panoplie detout développeur. Aucun logiciel dédié à Java ne peut aujourd’hui se permettre de nepas fournir des tâches Ant. Le choix de cette solution semble donc la meilleure marcheà suivre ! Pour lui faciliter la tâche, Olivier envoie à Arnaud un script Ant, appelé avec beaucoup d’originalité build.xml, qu’il utilise lui-même sur la plupart de ses projets, et qui est donc rodé et bourré d’options et de paramètres indis-pensables permettant de le plier à tous les besoins courants.Aurait-on trouvé avec Ant la solution miracle, rassemblant tous les suffrages ? Pas si simple : Nicolas, de son côté, désolé d’avoir causé tant de soucis à Arnaud, a reçu le même conseil de Fabrice, qui lui aussi a proposé un script de commandes Ant à tout faire, éprouvé par de nombreuses années d’utilisa-tion. Le fichier d’Olivier suppose que les fichiers sources java sont stockés dans unrépertoire sources et que les bibliothèques java sont placées sous libraries. Celui deFabrice fait des choix différents, respectivement java et libs. De plus, la commande decompilation pour le fichier d’Olivier est ant package alors que celle de Fabrice est antjar. La fusion de ces deux fichiers, chacun apportant des options intéressantes, est unvéritable casse-tête. Rapidement, les quatre compères, qui commencent à se prendre ausérieux avec leur liste de courses, font appel à des connaissances spécialistes d’Antpour les assister dans cette lourde tâche.1. Source : http://fr.wikipedia.org/wiki/Apache_Ant.
  25. 25. Chapitre 1 Introduction 7Ant a donc créé un nouveau métier dans le microcosme informatique : expert en scriptAnt ! Certains projets semblent jouer pour le concours du script le plus inutilementtordu, mixant des paramètres à n’en plus finir (que personne n’a d’ailleurs jamais eubesoin de modifier) et prenant en charge des cas de figure qui tiennent de l’expressionartistique, le tout en important d’autres fichiers de script pour éviter l’ignoble copier-coller. S’ils sont fonctionnels, de tels scripts sont un enfer à maintenir et traduisent uneorganisation suspecte du projet, qui pourrait bien avoir laissé passer un élément decomplexité inutile.Pris au jeu, nos quatre amis – qui ont trouvé un boulot en or pour avoir autant de tempslibre – ne s’avouent pas vaincus et veulent poursuivre ensemble le développement de ceprojet. Des complications commencent à émerger. Notre petite équipe provenant d’hori-zons différents, chacun a ses habitudes "maison" et ses bonnes pratiques et voudrait lesvoir appliquées.Et Maven dans tout ça ? Au hasard d’un de ces appels au secours, Jason les prend à contre-pied et leur répond : "Et pourquoi ne pas utiliser plutôt Apache Maven ?" Surpris, et quelque peu incrédules devant cette proposition, ils mettent Jason au défi decompiler ce fameux logiciel avec son outil miracle, là où nos deux scripts Ant, pourtantirréprochables, pris séparément refusent obstinément la fusion. Et dix minutes plustard, Jason envoie un fichier de quelques lignes, d’une simplicité surprenante, et lesinstructions de base pour installer Maven. À leur grande surprise, chacun arrive àcompiler le projet sur son environnement, quelle que soit sa singularité.Voici le fichier envoyé par Jason :Listing 1.2 : pom.xml<project> <modelVersion>4.0.0</modelVersion> <groupId>fr.noubliepaslalistedescourses</groupId> <artifactId>noubliepaslalistedescourses</artifactId> <version>0.0.1-SNAPSHOT</version> <build> <sourceDirectory>src</sourceDirectory> </build> <dependencies> <dependency> <groupId>javax.mail</groupId> <artifactId>mail</artifactId> <version>1.4</version> </dependency>
  26. 26. 8 Premiers pas avec Maven Partie I <dependency> <groupId>commons-io</groupId> <artifactId>commons-io</artifactId> <version>1.4</version> </dependency> </dependencies></project>Comparé aux fichiers Ant testés jusqu’ici, ce fichier "pom.xml" – quel drôle de nom –ne ressemble à rien de connu. Pas de directive de compilation, pas d’indication d’ordredans les tâches, pas de commande d’assemblage du JAR. Où est le secret ?Que fait Maven ?Épluchons point par point les consignes de Jason et voyons.L’installation de Maven à proprement parler se résume à désarchiver un fichier ZIP et àdéfinir la variable PATH pour y ajouter le chemin vers le répertoire apache-maven/bin.Il faut aussi s’assurer d’avoir la variable d’environnement JAVA_HOME qui indiquel’emplacement du JDK (Java Development Kit), ce qui est généralement le cas sur leposte de travail des bons développeurs. La construction du projet s’effectue ensuite viala commande mvn package depuis la ligne de commande. Rien de bien révolutionnairedonc par rapport au script Ant que nous avions envisagé.Jason nous a indiqué que Maven nécessitait une connexion à Internet. L’installationn’est donc pas complète, et Maven va rechercher sur le réseau les éléments manquants.Effectivement, la première exécution de Maven se traduit dans la console par une sériede messages de téléchargements divers :Listing 1.3 : Première exécution de MavenD:noubliepaslalistedescourses>mvn package[INFO] Scanning for projects...[INFO] ------------------------------------------------------------------------[INFO] Building Unnamed - fr.noubliepaslalistedescourses:noubliepaslalistedescourses:jar:0.0.1-SNAPSHOT[INFO] task-segment: [package][INFO] ------------------------------------------------------------------------Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-resources-➥plugin/2.2/maven-resources-plugin-2.2.pom1K downloadedDownloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugins/1/➥maven-plugins-1.pom3K downloaded
  27. 27. Chapitre 1 Introduction 9Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-parent/1/maven-➥parent-1.pom6K downloadedDownloading: http://repo1.maven.org/maven2/org/apache/apache/1/apache-1.pom3K downloaded...Cette liste de messages semble même interminable et avoir été conçue pour favoriser ledéveloppement d’Internet à haut débit. Tout ça pour notre projet composé de troisclasses ? Jason nous a prévenus qu’à la première utilisation, Maven semble téléchargertout Internet, mais il nous a promis des explications ! Mise en garde quelque peusurprenante, mais laissons-lui le bénéfice du doute. INFOLa mise en garde de Jason est judicieuse car de nombreux utilisateurs sont surpris par cecomportement de Maven et sa dépendance à une connexion Internet. Nous verrons par lasuite ce qui impose ce mode de fonctionnement et en quoi cela sert les utilisateurs plutôtque de les contraindre.Poursuivons l’analyse des messages que Maven trace dans la console, en ignorant leslignes liées à ces téléchargements étranges mais apparemment nécessaires :Listing 1.4 : Seconde exécution de Maven… sans téléchargement cette foisD:noubliepaslalistedescourses>mvn package[INFO] Scanning for projects...[INFO] ------------------------------------------------------------------------[INFO] Building Unnamed - fr.maven:noubliepaslalistedescourses:jar:0.0.1-SNAPSHOT[INFO] task-segment: [package][INFO] ------------------------------------------------------------------------[INFO] [resources:resources][INFO] Using default encoding to copy filtered resources.[INFO] [compiler:compile][INFO] Compiling 3 source files to D:javaworkspacemalistedecoursestargetclasses[INFO] [resources:testResources][INFO] Using default encoding to copy filtered resources.[INFO] [compiler:testCompile][INFO] Nothing to compile - all classes are up to date[INFO] [surefire:test][INFO] Surefire report directory:D:javaworkspacemalistedecoursestargetsurefire-reports------------------------------------------------------- T E S T S-------------------------------------------------------There are no tests to run.
  28. 28. 10 Premiers pas avec Maven Partie IResults :Tests run: 0, Failures: 0, Errors: 0, Skipped: 0[INFO] [jar:jar][INFO] Building jar: D:javaworkspacemalistedecoursestargetmalistedecourses-0.0.1-➥SNAPSHOT.jar[INFO] ------------------------------------------------------------------------[INFO] BUILD SUCCESSFUL[INFO] ------------------------------------------------------------------------[INFO] Total time: 15 seconds[INFO] Finished at: Fri Jan 02 17:02:09 CET 2009[INFO] Final Memory: 6M/13M[INFO] ------------------------------------------------------------------------Nous constatons que Maven a compilé nos trois fichiers sources et construit unfichier JAR, ce qu’on attendait de lui, mais il a également tenté de copier des"ressources" et d’exécuter des tests, ensemble de traitements que nous n’avonsspécifiés nulle part !La clé du mystèreInterrogé sur le sujet, Jason nous livre la clé du mystère : Ant, make et bon nombred’outils similaires s’appuient sur une approche procédurale, pour laquelle on décrit lesopérations à accomplir pour construire le logiciel ou exécuter des tâches annexes. Celase traduit donc par une suite de commandes, qui prendra d’une façon ou d’une autre laforme décrite à la Figure 1.2. Étape Traitement Initialiser Préparer les répertoires de travail Nécessite Compiler Invoquer le compilateur “javac” Nécessite Assembler Invoquer l’archiveur “jar”Figure 1.2Les étapes élémentaires de construction d’un projet.
  29. 29. Chapitre 1 Introduction 11Cette approche fonctionne très bien et permet de faire à peu près tout ce qu’on veut,mais elle nécessite :m de répéter pour chaque nouveau projet une liste de tâches très similaires, ce qui se traduit souvent par la copie d’un fichier de configuration considéré comme "faisant référence" ;m de gérer une liste de dépendances entre les étapes clés, comme, dans notre exemple, "compiler" lorsqu’on désire assembler le JAR.Maven choisit une approche différente, fondée sur le constat suivant : tous les projetsJava vont suivre peu ou prou le même schéma. Les développeurs de Maven considèrentalors qu’il est plus simple de décrire en quoi un projet est différent de ce "scénario type"que de répéter invariablement des commandes très comparables d’un projet à l’autre.Maven exploite donc le concept très structurant de conventions.Convention plutôt que configurationNotre pseudo-exemple réunissant les étapes "initialiser", "compiler", "assembler"semble s’appliquer à n’importe quel projet informatique, alors pourquoi devons-nousrépéter cette déclaration pour chaque projet ? C’est exactement la question que soulèveMaven et à laquelle il répond simplement : tout projet Java passe par une phase depréparation, de compilation puis d’assemblage. Ces trois phases ne sont pas propres àun projet, mais liées au développement informatique et s’appliquent à tous.Maven définit donc un scénario type de construction d’un projet Java, avec des étapesclés prédéfinies et dont l’ordre est immuable. Ce "cycle de vie" est suffisamment largeet consensuel pour être applicable à quasiment tous les projets. En admettant que lenôtre n’ait rien de particulier comparé à tous ceux que pilote Maven, nous comprenonsmieux comment celui-ci a "deviné" les opérations nécessaires à sa construction.Java Entreprise Edition suit également cette piste en proposant un environnement stan-dardisé et un format de livraison commun pour les applications, même s’il existe denombreux serveurs d’applications ayant des caractéristiques très variées. Construireune application web Java consiste à assembler une archive WAR (Web ApplicationArchive), que l’on ait choisi JBoss, Webpshere, Tomcat ou Jetty pour l’exécuter. Lecomportement "par convention" d’une application web est défini par une norme, chaqueserveur proposant des options de configuration pour bénéficier d’un comportementpersonnalisé lorsque c’est nécessaire. Une convention a, bien sûr, un statut inférieur àune norme comme JEE, mais elle apporte la même simplification.La force des conventions est d’offrir à ceux qui les suivent un outil directement exploi-table, sans configuration complémentaire. Une convention de Maven concerne parexemple l’emplacement des fichiers sources Java à compiler. Notre fichier pom.xml
  30. 30. 12 Premiers pas avec Maven Partie Icontient effectivement une indication sourceDirectory que nous faisons pointer sur lerépertoire src. Cette indication n’aurait pas été nécessaire si nous avions suivi laconvention. Il nous suffit de l’adopter pour alléger d’autant notre configuration Maven.Nous verrons en détail plus loin les diverses conventions préconisées par Maven.Certains trouveront cette structure inutilement complexe, peu pratique, ou au contraireparfaitement adaptée à leurs habitudes. L’essentiel n’est pas là, mais dans le fait queMaven propose une organisation par défaut, qui peut fonctionner sans plus d’indi-cations pour tout projet qui la respecte. La force de Maven est de présenter une structureconventionnelle, qui évite à chacun un travail rébarbatif de configuration.Maven reposant sur un scénario type de construction de projet Java, nous n’avons plusbesoin d’indiquer la moindre commande. Il nous suffit de décrire en quoi notre projetest différent de ce cas stéréotypé. Nous passons d’une approche programmatique à unesolution déclarative.Décrire plutôt que programmerNotre fichier pom.xml de Maven ne compte aucune commande de compilation et, pour-tant, il se traduit au final par l’exécution des outils de compilation et d’assemblage duJDK. Maven fait le choix d’une approche déclarative, dans laquelle on indique les parti-cularités du projet et non la manière de le construire. On précise l’emplacement desfichiers sources, les bibliothèques qui sont nécessaires, plutôt que la ligne de commandedu compilateur.La différence est très significative, car il ne s’agit plus de définir les options de javac,mais de décrire une structure plus générale du projet, qui pourra être exploitée dans unautre contexte. Elle sera, par exemple, utilisée pour s’intégrer dans un IDE (IntegratedDevelopment Environment) comme Eclipse ou par les outils d’analyse de code.POMAvec ces explications, revenons à présent sur le fichier pom.xml que Jason nous a écrit.Tout d’abord, pourquoi ce nom ? Nous avons vu que ce fichier ne décrit pas la procé-dure de construction du projet mais qu’il rassemble des éléments descriptifs. Il est donclogique qu’il ne s’appelle pas build.xml (en dehors du conflit que cela introduirait avecles utilisateurs d’Ant).Les trois lettres POM sont en fait l’acronyme de Project Object Model. Sa représenta-tion XML est traduite par Maven en une structure de données riche qui représente lemodèle du projet. Ces déclarations sont complétées avec l’ensemble des conventionsqui viennent ainsi former un modèle complet du projet utilisé par Maven pour exécuterdes traitements.
  31. 31. Chapitre 1 Introduction 13La première partie du POM permet d’identifier le projet lui-même.Listing 1.5 : L’en-tête du fichier POM<modelVersion>4.0.0</modelVersion><groupId>fr.noubliepaslalistedescourses</groupId><artifactId>noubliepaslalistedescourses</artifactId><version>0.0.1-SNAPSHOT</version>L’élément modelVersion permet de savoir quelle version de la structure de données"modèle de projet" est représentée dans le fichier XML. Les futures versions de Mavenpourront ainsi exploiter des versions différentes de modèles en parallèle et introduire sinécessaire des évolutions dans le format de ce fichier.L’identifiant de groupe (groupId) permet de connaître l’organisation, l’entreprise,l’entité ou la communauté qui gère le projet. Par convention, on utilise le nom dedomaine Internet inversé, selon la même logique que celle généralement recommandéepour les noms de package Java.L’identifiant de composant (artifactId) est le nom unique du projet au sein du groupequi le développe. En pratique et pour éviter des confusions, il est bon d’avoir un arti-factId unique indépendamment de son groupId.Enfin, on précise quelle version du projet est considérée. La plupart des projets utilisentla formule <Version Majeure>.<Version Mineure>.<Correctif>, même s’il est diffi-cile d’obtenir un consensus sur la signification exacte de ces numéros et sur leuremploi. Vous pouvez utiliser une chaîne arbitraire, mais la syntaxe numérique permetde faire des comparaisons de versions et de trier celles-ci pour identifier automatique-ment la plus récente. SNAPSHOT est un mot clé réservé de Maven, dont nous décrironsla fonction par la suite. ASTUCELe numéro de version est un concept délicat et changeant selon les organisations et la sensi-bilité de chacun. Nous vous recommandons une notation purement numérique qui faciliteles comparaisons, selon la logique Majeur.Mineur.Correctif. Seules deux versions majeurespeuvent ne pas assurer de compatibilité, une nouvelle version mineure peut apporter desfonctionnalités inédites mais s’interdit de ne pas respecter le mode de fonctionnement exis-tant ; enfin, une version corrective n’apporte aucune fonctionnalité nouvelle mais éliminecertains problèmes.Certains enrichissent cette numérotation d’un dernier élément qui indique le degré deconfiance dans une version donnée : "RC" pour une Release Candidate (version quasifinale), "GA" pour General Availability pour une version diffusée au public. Cet usage peutporter préjudice au projet car dans la comparaison purement alphabétique, "GA" est infé-rieur à "RC" !
  32. 32. 14 Premiers pas avec Maven Partie ILa deuxième partie du POM concerne la construction du projet :Listing 1.6 : Le bloc build du fichier POM<build> <sourceDirectory>src</sourceDirectory></build>L’approche déclarative utilisée par Maven permet de définir l’emplacement de nosfichiers sources. Le projet étant à la fois très simple et très banal, aucune autre décla-ration n’est nécessaire. Si nous avions utilisé le répertoire conventionnel de Mavenpour les fichiers sources Java, nous n’aurions même pas eu besoin de ce bloc<build> !La troisième partie de POM concerne les bibliothèques dont dépend le projet :Listing 1.7 : Le bloc dependencies du fichier POM<dependencies> <dependency> <groupId>javax.mail</groupId> <artifactId>mail</artifactId> <version>1.4</version> </dependency> <dependency> <groupId>commons-io</groupId> <artifactId>commons-io</artifactId> <version>1.4</version> </dependency><dependencies>Une nouvelle fois, l’approche déclarative prend le dessus : nous n’indiquons pasl’emplacement physique de ces bibliothèques, à savoir /lib pour notre projet, mais desidentifiants groupId + artifactId + version. Il s’agit des mêmes identifiants degroupe, de composant et de version, que nous venons de rencontrer, appliqués à unebibliothèque. Nous indiquons, par exemple, que nous utilisons l’API standard JavaMailen version 1.4.Nous avons ici une réponse partielle à notre question sur la nécessité d’un accès Inter-net : Maven va télécharger les bibliothèques indiquées, à partir d’une source fiable,plutôt que de se contenter des fichiers JAR présents dans le répertoire /lib et dont laversion et l’origine sont incertaines. L’espace contenant l’ensemble des bibliothè-ques téléchargées est un dépôt d’archives local (local repository) et respecte uneconvention. Nous verrons en détail au Chapitre 2 les raisons de cette approche et sesavantages.
  33. 33. Chapitre 1 Introduction 15Pourquoi adopter ces conventions ?Nous venons de le voir, Maven propose un ensemble de conventions qui permettentd’outiller le projet avec peu de configuration. Il ne nous interdit cependant pas de choisirnos propres conventions, comme le répertoire src pour les sources du logiciel.Dans ce cas, pourquoi adopter les conventions de Maven, alors qu’il suffit de quelqueslignes de déclaration supplémentaires pour "plier" Maven à nos habitudes ? Hostiles auchangement, comme une grande majorité des êtres humains, nous préférons cetteoption. C’est à ce moment qu’Emmanuel se propose de nous rejoindre, lui aussi à temps perdu grâce à son boulot en or, pour enrichir notre projet d’un grand nombre de nouvelles fonctionnalités. Emmanuel est déjà habitué à Maven etpeut donc être rapidement productif et nous aider à le configurer correctement. Seule-ment, les choses ne se passent pas aussi simplement que prévu, car malgré son expé-rience de l’outil, Emmanuel ne retrouve pas ses petits : pour ajouter des tests à notrearchitecture, il doit créer un nouveau répertoire de sources, indépendant de celles duprojet. Or notre répertoire src n’a qu’un seul niveau et ne permet pas de différencier lelivrable des tests. Il est donc obligé de déclarer une nouvelle dérogation aux conventionsde Maven.Par ailleurs, même si les différences sont minimes, il est contraint d’adapter toutes sespetites habitudes à notre structure de répertoire, qui n’est pas "strictement conformeMaven".Les conventions de Maven ne sont pas obligatoires, cependant réfléchissez à deux foisavant de vouloir en imposer d’autres pour votre projet. D’une part, vous allez vouscompliquer inutilement la tâche en ne profitant pas du comportement par défaut quepropose Maven, et chaque nouvelle option activée pourra se traduire par une nouvellephase de configuration. À moins d’être passionnés par l’éditeur XML, peu de déve-loppeurs prennent du plaisir à perdre un temps précieux dans des fichiers de configuration,Maven ou autres.Ensuite, pensez à la gestion de vos équipes et à l’intégration de nouveaux développeurs.Maven offre l’occasion de définir une fois pour toutes la structure de tous vos projetsJava, de manière homogène. Un développeur pourra passer d’un projet à un autre sansperdre son temps à apprendre les petites habitudes locales : où sont les fichiers de confi-guration ? Dans quel répertoire place-t-on les données de test ? Tous les projets qui seconforment aux conventions Maven seront identiques de ce point de vue, et le déve-loppeur sera plus rapidement productif.
  34. 34. 16 Premiers pas avec Maven Partie IEnfin, contrairement à une politique "maison" qui aurait pu établir ce type de conven-tions, celles de Maven sont partagées par la majorité des développeurs qui ont adopté celogiciel. Tout nouveau membre de votre équipe qui a déjà travaillé sur un projet Maventrouvera rapidement ses repères. Maven et ses conventions deviennent au fil des annéesle standard de facto dans le monde professionnel Java car un développeur trouve immé-diatement ses marques lorsqu’il aborde un nouveau projet.La force des conventions de Maven n’est pas dans le nom des répertoires qui ont étéchoisis, mais dans le fait qu’il offre à la communauté des développeurs Java tout entièreune base commune.La force de MavenRevenons un peu en arrière : le projet initial, que nous pouvons considérer comme unprototype, était difficilement exportable en dehors de l’environnement de son créateur.Il nécessitait un script de compilation à la fois indispensable et sans grande valeur ajoutée,étant d’une grande banalité.L’adoption d’Ant aurait pu partiellement résoudre le problème, mais pour tirer parti dela richesse des outils qui peuvent lui être greffés, il aurait fallu que tous les scripts Antadoptent une structure de base commune. En l’absence d’une convention dans lacommunauté Ant pour les éléments principaux qui gouvernent un projet Java, il peutêtre extrêmement délicat de réutiliser et de fusionner des éléments provenant de sourcesindépendantes. Enfin, tout ce travail aurait été réalisé par des copier-coller qu’il auraitfallu répéter pour notre prochain projet.Maven propose de passer à une approche déclarative, dans laquelle nous considéreronsnotre projet comme une variation sur un thème commun. Nous ne nous soucions plusde savoir quelle opération doit suivre quelle autre lors de la construction du logiciel.Nous déclarons juste les quelques éléments spécifiques qui font de notre projet quelquechose d’unique.En adoptant des conventions, nous réduisons à quelques lignes les informations quenous devons déclarer pour que le projet soit pris en charge par Maven. La maintenanceet l’ajout de nouvelles tâches au cours de la construction du projet s’en trouvent simpli-fiés. Un développeur, issu d’un contexte très différent mais déjà utilisateur de l’outil,peut prendre le projet en main sans difficulté particulière.La combinaison de conventions et d’une approche innovante fondée sur la descriptiondu projet fait de Maven un outil à part, très différent d’Ant ou de ses équivalents. Aucours des chapitres qui suivent, nous allons voir en quoi cette approche se généralise àtoutes les tâches qui accompagnent la vie d’un projet.
  35. 35. 2 Au-delà de java.langDes JAR sous CVSAvec une équipe qui se compose désormais de cinq développeurs motivés, il n’est plusquestion de s’envoyer par e-mail des archives du projet pour transmettre aux autres lesnouvelles fonctions que l’on vient de développer. Un projet en mode collaboratif utiliseun outil de gestion de sources pour partager le code, synchroniser les développementset gérer les conflits lorsque deux personnes travaillent sur le même fichier. Ce gestion-naire de sources (SCM – Source Control Management) est typiquement CVS (ConcurrentVersion System), Subversion ou, plus récemment, Git.Comme son nom l’indique, cet outil est prévu pour contenir des fichiers sources et nondes binaires issus d’une compilation. Pourtant, de nombreux projets placent les biblio-thèques et les outils nécessaires au projet dans leur gestionnaire de sources. L’idée peutsembler bonne a priori, car elle vise à gérer avec un unique outil et, de manière homo-gène, tous les éléments nécessaires au développement du projet. Sauvegarder les biblio-thèques Java dans le SCM est donc une garantie de retrouver à tout moment la versionexacte qui est utilisée par le projet.Notre prototype ne déroge pas à cette "bonne idée" et possède comme tant d’autres unrépertoire lib avec l’ensemble des bibliothèques utilisées.Quand le répertoire lib exploseLa croissance de l’équipe nous permet de rapidement améliorer notre prototype. Lenombre de bibliothèques nécessaires au projet augmente. Nous commençons par intro-duire Spring pour rendre le code plus évolutif avec l’utilisation des concepts de l’injec-tion de dépendances. Ensuite, nous remplaçons tout le code écrit en JDBC parHibernate et Java Persistence API. Nous développons une interface web sympathique

×