Préface de la troisième édition▲
Ecrire un bouquin pour un éditeur est un travail épuisant. La rédaction elle même n'est qu'une toute petite partie du travail, déjà prenante, et il faut y ajouter les relations éditeur par eMail et la phase de relecture puis de mise en page, sans parler des questions des équipes marketing pour la promotion du livre.
Pour la première édition de ce livre je découvrais le monde de l'édition et j'étais super motivé. Nous avons nous-même choisi nos relecteurs dans la communauté Maven francophone et utilisé un DropBox, nettement plus pratique que le process d'envoi des chapitres par eMail proposé par l'éditeur.
Il a fallu assi s'adapter au template Word de Pearson, qui s'est avéré pas si mal fait que ça après avoir été confronté à celui d'autres éditeurs ! Au final, la masse de travail, toutes les tâches non prévues, pour quelques euros récoltés (8% à se partager) n'est pas du tout rentable. Si cela restait du plaisir - après tout, écrire du code OSS n'est pas très rentable non plus - la pillule pourrait passer, mais en plus il faut subir les contraintes de la chaîne d'édition.
Pearson nous a annoncé début décembre 2013 que le livre serait arrêté, faute de rentabilité. Pas vraiment une surprise, un livre technique, qui plus est en Français, n'a pas un auditoire énorme - ou alors, peut être que tout le monde fait du gradle aujourd'hui - en tout cas nous en avons vendu environ 2000 exemplaires, ce qui est un beau succès pour un marché aussi limité.
Aussi, après avoir récupéré nos droits sur le texte nous avons décidé de le convertir en AsciiDoc pour ne plus subir Word et le template editeur, et surtout de l'open-sourcer, sous license Creative Commons 4.0 afin que tout le monde en profite et que d'éventuels contributeurs puisse nous aider à corriger les boulettes inévitables qui s'y sont glissées.
"Attribution - Pas d´Utilisation Commerciale - Partage dans les Mêmes Conditions"
Nicolas de Loof
Préface de la seconde édition▲
La rédaction de la première édition d'Apache Maven a été un exercice difficile mais très enrichissant. Avec Arnaud, nous avons trouvé un rythme et un ton qui nous permettait de prendre du plaisir sans accumuler trop de retard - un petit mois à peine - sur le planning de Pearson. Nous en avons retiré une grande fierté, surtout avec le très bon accueil du public.
Malgré cela, nous avons rapidement identifié des manques et des sujets que nous aurions aimé approfondir. Au cours de la rédaction, les nouvelles versions de plugins et l'avancement des développements de Maven 3 rendaient certaines de nos remarques obsolètes ou moins pertinentes. La liste des éléments de notre Erratum, que nous n'avons jamais publié d'ailleurs faute de l'organiser correctement, a commencé à s'allonger. Il était hors de question d'en rester là !
A l'heure où nous reprenons la plume (enfin, le clavier), Maven 3 enfin sorti en version 3.0 finale, est pleinement utilisable sur un projet. Les versions suivantes apporteront encore de nouvelles fonctionnalités et améliorations. Dans le même temps, de nombreux projets vont continuer d'utiliser Maven 2 pendant encore un long moment. Il n'est pas question de laisser ces utilisateurs sur le carreau juste parce que la nouvelle version de Maven est plus belle, plus grande, plus forte.
Nous avons donc choisi de donner à cette seconde édition une double lecture : le corps du texte a été revu pour correspondre à l'état de l'art, à savoir Maven 3. De nouveaux chapitres viennent en décrire les avancées et les outils associés. C'est seulement lorsqu'une rupture significative avec les versions précédentes existe que nous ajoutons un encart. Ces encarts sont reconnaissables au logo :
Vous constaterez rapidement qu'ils sont assez peu nombreux : Maven 3 est avant tout conçu pour remplacer son prédécesseur sans heurts. Même avec ces réserves, les grandes idées présentées dans le livre sont applicables aux deux versions. Nous espérons donc que vous en tirerez le meilleur parti.
Quoi qu´il en soit, nous avons utilisé Maven 3.0 dans ses diverses pré-versions et nous vous encourageons à migrer vers cette nouvelle édition de l´outil phare du développement Java. Les prochaines versions sont une large promesse de fonctionnalités innovantes, et « au pire » vous bénéficierez d´une amélioration des performances et d´une réduction d´occupation mémoire ! Si vous utiliser m2eclipse pour intégrer votre projet Maven dans Eclipse, vous êtes déjà des utilisateurs de Maven 3 sans même le savoir, alors laissez vos dernières hésitations de côté et en avant toute.
Nous espérons que les pages qui suivent vous aideront à prendre en main Maven et à en comprendre la richesse et la philosophie, qui en font un outil sans équivalent.
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 accessible à 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 on s'embarque dans de longues explications de principes et de concepts et le lecteur n'attendra jamais ce même Chapitre 5.
Pour être honnête, je dois dire que les premières ébauches de cet ouvrage sont immanquablement tombées dans ces travers, ce qui annonçait un livre bien peu pertinent pour les utilisateurs, qu'ils soient novices ou déjà expérimentés. Lorsque j'ai soumis les premiers extraits de ce projet à Arnaud, il m'en a rapidement fait la remarque et nous nous sommes 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'est Maven, lequel réunit des développeurs aux parcours très différents. Les rencontres que j'ai faites dans cette communauté ont forgé mon approche de l'informatique. Avec cette motivation, établir un dictionnaire impersonnel Maven-Français était exclu ; aussi j'ai rapidement choisi, en accord avec Arnaud, de privilégier une approche aussi didactique que 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, alors qu'ils y sont pourtant confrontés en permanence. Situation intéressante où tout le monde rencontre un problème, mais, faute de mettre un nom dessus et d'en évaluer l'importance, celui-ci reste latent tout au long de la vie du projet, amenant parfois à des situations critiques. Nous allons suivre ensemble la vie d'un projet fictif, bien que largement inspiré de situations réelles. Il passera par toutes les phases, du prototype écrit sur un coin de table à l'application stratégique d'entreprise de grande envergure, ce qui nous 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 long exposé théorique sur ses concepts, je préfère au travers de cette démonstration un peu romancée vous montrer les difficultés concrètes auxquelles Maven s'attaque. Sur la base de ces exemples, parfois volontairement excessifs, je souhaite vous démontrer de manière ludique les avantages que Maven peut apporter à vos projets. Malgré les caricatures proposées, de nombreuses situations vous sembleront familières. Derrière la fiction se cachent des cas bien réels, que je n'ai fait qu'amplifier, et beaucoup auront des points communs avec vos propres difficultés. Ce parallèle vous donnera une image ré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 du texte qui suit. En particulier, j'aimerais qu'arrivé au bout de votre lecture vous soyez conscient des objectifs visés par Maven, de sa philosophie et des raisons pour lesquelles il 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 participer en 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 cet outil. Arnaud et moi avons commencé de cette façon avant de passer "de l'autre côté du miroir", mais au quotidien nous restons comme vous, avant tout, des utilisateurs de Maven, 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ù la chercher entre le site web du projet (1), ses nombreux plugins et son wiki (2). Pourtant, il existe désormais deux ouvrages en anglais disponibles gratuitement sur la Toile pour combler ces manques : Better Builds with Maven (3), publié en 2006, et Maven : The Definitive Guide (4), publié en 2007 et régulièrement mis à jour. Alors qu'apporter de plus qu'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 et pointer sur les mauvaises que j'avais pu rencontrer. C'est sur ce principe que nous avons commencé avec Nicolas à bâtir le squelette de cet ouvrage. Fondé sur un projet fictif, il retrace nos expériences ainsi que celles des personnes que nous avions croisées sur notre chemin et permet d'expliquer les enjeux de Maven dans un projet et dans une entreprise. Même si nous n'avons pas recherché l'exhaustivité dans les cas traités, tellement ils peuvent être nombreux, nous avons essayé de faire apparaître les plus fréquents ou les plus épineux que nous ayons eus à résoudre. Nous avons axé nos efforts sur la pré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 complet afin qu'il ne soit plus jamais complexe à vos yeux.
Arnaud Héritier
Contenu▲
Cet ouvrage se compose de quatre parties :
- La première, du Chapitre 1 au Chapitre 5, aborde les concepts fondamentaux de Maven et leur mise en oeuvre 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.
- La deuxième, du Chapitre 6 au Chapitre 10, exploite des fonctionnalités plus avancé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 JavaEE (Java Enterprise Edition) en entreprise.
- 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".
- 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 pratiques à 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 peu abscons utilisés dans cet ouvrage.
Partie 1▲
Commençons donc notre récit par l'inévitable mise en garde : toute ressemblance avec des 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 (si vous ne participez pas à un JUG … et bien vous avez tort). Faisant connaissance autour d'un verre, ils évoquent les souvenirs de leurs premiers pas avec Java, devenu depuis leur plateforme de prédilection. Un Java Development 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 rappellent qu'on a tous débuté un jour, rencontré les mêmes problèmes et commis les mêmes erreurs idiotes que l'on dénonce aujourd'hui.
La première application un peu intéressante de Nicolas était un splendide outil de gestion 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 tout simplement 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épart du bureau, un message de rappel avec la liste des courses. Autrement dit, un outil de rêve totalement indispensable, à tel point que le code de ce monument de l'informatique est respectueusement conservé quelque part.
Arnaud, confronté au même souci et amusé par cette solution de pur geek, lui demande s'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, voici les fichiers qui la constituent :
La structure originale du projet "noubliepaslalistedescourses".
Arnaud, qui, semble-t-il, n'a vraiment que cela à faire de son temps libre, se jette sur cette magnifique relique des années Java 1.1 et tente de le compiler. Seulement, Arnaud est un utilisateur Mac. Le fichier BAT qui compile et assemble le logiciel en une archive Java JAR est inexploitable sur son système. Arnaud n'est pas du genre à se décourager si facilement, aussi écrit-il un fichier de compilation adapté à son environnement afin de pouvoir tester ce chef-d'oeuvre de l'informatique.
Deux jours plus tard, profitant d'un peu de rangement, Nicolas retrouve une autre disquette contenant une version plus avancée de son logiciel, qui utilise les fonctions d'une bibliothèque utilitaire pour lire le fichier contenant la liste des courses. Il l'envoie donc à 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 pour comparaison 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 environnements de 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
|
|
|
|
build.bat Sélectionnez |
build.sh Sélectionnez |
De nombreux projets industriels ou communautaires sont confrontés à ce même problème et sont obligés de maintenir deux versions (ou plus) du script de construction du logiciel, soit parce que l'équipe n'est pas homogène, soit parce que l'environnement de test ou de production n'est pas équivalent à celui de développement. Même sur des systèmes d'exploitation identiques, les outils peuvent être installés à des emplacements différents, ce qui oblige à prévoir dans le script un ensemble de propriétés que chacun devra 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 comme postes de développement.
Arnaud raconte ses déboires à son collègue Olivier. Ce dernier, utilisateur du système Solaris, s'est souvent trouvé face à ce problème ; il lui propose d'utiliser un fichier de commande universel, basé sur l'outil Apache Ant.
Les fourmis à la rescousse▲
Qu'est-ce que c'est que ce "Ant" ? Faisons un détour par Wikipédia pour nous en faire une idée :
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 de document (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 de tout développeur. Aucun logiciel dédié à Java ne peut aujourd'hui se permettre de ne pas 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 indispensables 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'utilisation. Le fichier d'Olivier suppose que les fichiers sources java sont stockés dans un répertoire sources et que les bibliothèques java sont placées sous libraries. Celui de Fabrice fait des choix différents, respectivement java et libs. De plus, la commande de compilation pour le fichier d'Olivier est ant package alors que celle de Fabrice est ant jar. La fusion de ces deux fichiers, chacun apportant des options intéressantes, est un véritable casse-tête. Rapidement, les quatre compères, qui commencent à se prendre au sérieux avec leur liste de courses, font appel à des connaissances spécialistes d'Ant pour les assister dans cette lourde tâche.
Ant a donc créé un nouveau métier dans le microcosme informatique : expert en script Ant ! Certains projets semblent jouer pour le concours du script le plus inutilement tordu, mixant des paramètres à n'en plus finir (que personne n'a d'ailleurs jamais eu besoin de modifier) et prenant en charge des cas de figure qui tiennent de l'expression artistique, 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 une organisation suspecte du projet, qui pourrait bien avoir laissé passer un élément de complexité inutile.
Pris au jeu, nos quatre amis - qui ont trouvé un boulot en or pour avoir autant de temps libre - ne s'avouent pas vaincus et veulent poursuivre ensemble le développement de ce projet. Des complications commencent à émerger. Notre petite équipe provenant d'horizons différents, chacun a ses habitudes "maison" et ses bonnes pratiques et voudrait les voir 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 de compiler ce fameux logiciel avec son outil miracle, là où nos deux scripts Ant, pourtant irréprochables, pris séparément refusent obstinément la fusion. Et dix minutes plus tard, Jason envoie un fichier de quelques lignes, d'une simplicité surprenante, et les instructions 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 :
<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>
<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'ordre dans 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 indique l'emplacement du JDK (Java Development Kit), ce qui est généralement le cas sur le poste de travail des bons développeurs. La construction du projet s'effectue ensuite via la commande mvn package depuis la ligne de commande. Rien de bien révolutionnaire donc par rapport au script Ant que nous avions envisagé.
Jason nous a indiqué que Maven nécessitait une connexion à Internet. L'installation n'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érie de messages de téléchargements divers :
D:\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.pom
1K downloaded
Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugins/1/maven-plugins-1.pom
3K downloaded
Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-parent/1/maven-parent-1.pom
6K downloaded
Downloading: http://repo1.maven.org/maven2/org/apache/apache/1/apache-1.pom
3K downloaded
...
