Notre pseudoexemple réunissant les étapes « initialiser », « compiler », « assembler » semble s’appliquer à n’importe quel projet informatique, alors pourquoi devons-nous répéter cette déclaration pour chaque projet ? C’est exactement la question que soulève Maven et à laquelle il répond simplement : tout projet Java passe par une phase de pré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 étapes clés prédéfinies et dont l’ordre est immuable. Ce « cycle de vie » est suffisamment large et consensuel pour être applicable à quasiment tous les projets. En admettant que le nôtre n’ait rien de particulier comparé à tous ceux que pilote Maven, nous comprenons mieux comment celui-ci a « deviné » les opérations nécessaires à sa construction.

Java Entreprise Edition suit également cette piste en proposant un environnement standardisé et un format de livraison commun pour les applications, même s’il existe de nombreux serveurs d’applications ayant des caractéristiques très variées. Construire une application web Java consiste à assembler une archive WAR (Web Application Archive), que l’on ait choisi JBoss, Webpshere, Tomcat ou Jetty pour l’exécuter. Le comportement par « convention » d’une application web est défini par une norme, chaque serveur proposant des options de configuration pour bénéficier d’un comportement personnalisé lorsque c’est nécessaire. Une convention a, bien sûr, un statut inférieur à une norme comme JavaEE, mais elle apporte la même simplification.

La force des conventions est d’offrir à ceux qui les suivent un outil directement exploitable, sans configuration complémentaire. Une convention de Maven concerne par exemple l’emplacement des fichiers sources Java à compiler. Notre fichier pom.xml contient effectivement une indication sourceDirectory que nous faisons pointer sur le répertoire src. Cette indication n’aurait pas été nécessaire si nous avions suivi la convention. 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 contraire parfaitement adaptée à leurs habitudes. L’essentiel n’est pas là, mais dans le fait que Maven propose une organisation par défaut, qui peut fonctionner sans plus d’indications pour tout projet qui la respecte. La force de Maven est de présenter une structure conventionnelle, qui évite à chacun un travail rébarbatif de configuration.

Maven reposant sur un scénario type de construction de projet Java, nous n’avons plus besoin d’indiquer la moindre commande. Il nous suffit de décrire en quoi notre projet est différent de ce cas stéréotypé. Nous passons d’une approche programmatique à une solution déclarative.

Notre fichier pom.xml de Maven ne compte aucune commande de compilation et, pourtant, il se traduit finalement par l’exécution des outils de compilation et d’assemblage du JDK. Maven fait le choix d’une approche déclarative, dans laquelle on indique les particularités du projet et non la manière de le construire. On précise l’emplacement des fichiers sources, les bibliothèques qui sont nécessaires, plutôt que la ligne de commande du 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 un autre contexte. Elle sera, par exemple, utilisée pour s’intégrer dans un IDE (Integrated Development Environment) comme Eclipse ou par les outils d’analyse de code.

Avec 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 donc logique qu’il ne s’appelle pas build.xml (en dehors du conflit que cela introduirait avec les utilisateurs d’Ant).

Les trois lettres POM sont en fait l’acronyme de Project Object Model. Sa représentation XML est traduite par Maven en une structure de données riche qui représente le modèle du projet. Ces déclarations sont complétées avec l’ensemble des conventions qui viennent ainsi former un modèle complet du projet utilisé par Maven pour exécuter des traitements.

La première partie du POM permet d’identifier le projet lui-même.

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. « 4.0.0 » correspond à la version utilisée par Maven 2.x dans toutes ses variantes.

Les futures versions de Maven 3 pourront exploiter des versions différentes de modèles et introduire des évolutions dans le format de ce fichier. Entre autres, sont envisagés :

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 de domaine Internet inversé, selon la même logique que celle généralement recommandée pour les noms de package Java.

L’identifiant de composant (artifactId) est le nom unique du projet au sein du groupe qui le développe. En pratique et pour éviter des confusions, il est bon d’avoir un artifactId unique indépendamment de son groupId.

Enfin, on précise quelle version du projet est considérée. La plupart des projets utilisent la formule <Version Majeure>.<Version Mineure>.<Correctif>, même s’il est difficile d’obtenir un consensus sur la signification exacte de ces numéros et sur leur emploi. Vous pouvez utiliser une chaîne arbitraire, mais la syntaxe numérique permet de faire des comparaisons de versions et de trier celles-ci pour identifier automatiquement la plus récente. SNAPSHOT est un mot clé réservé de Maven, dont nous décrirons la fonction par la suite.

La deuxième partie du POM concerne la construction du projet :

L’approche déclarative utilisée par Maven permet de définir l’emplacement de nos fichiers sources. Le projet étant à la fois très simple et très banal, aucune autre déclaration n’est nécessaire. Si nous avions utilisé le répertoire conventionnel de Maven pour 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 :

Une nouvelle fois, l’approche déclarative prend le dessus : nous n’indiquons pas l’emplacement physique de ces bibliothèques, à savoir /lib pour notre projet, mais des identifiants groupId + artifactId
version. Il s’agit des mêmes identifiants de groupe, de composant et de version, que nous venons de rencontrer, appliqués à une bibliothèque. Nous indiquons, par exemple, que nous utilisons l’API standard JavaMail en version 1.4.

Nous avons ici une réponse partielle à notre question sur la nécessité d’un accès Internet : 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 la version 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 une convention. Nous verrons en détail au Chapitre 2 les raisons de cette approche et ses avantages.

Nous venons de le voir, Maven propose un ensemble de conventions qui permettent d’outiller le projet avec peu de configuration. Il ne nous interdit cependant pas de choisir nos 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 quelques lignes de déclaration supplémentaires pour « plier » Maven à nos habitudes ? Hostiles au changement, comme une grande majorité des êtres humains, nous préférons cette option.

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 et peut donc être rapidement productif et nous aider à le configurer correctement. Seulement, 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 à notre architecture, il doit créer un nouveau répertoire de sources, indépendant de celles du projet. Or notre répertoire src n’a qu’un seul niveau et ne permet pas de différencier le livrable des tests. Il est donc obligé de déclarer une nouvelle dérogation aux conventions de Maven.

Par ailleurs, même si les différences sont minimes, il est contraint d’adapter toutes ses petites habitudes à notre structure de répertoire, qui n’est pas « strictement conforme Maven ».

Les conventions de Maven ne sont pas obligatoires, cependant réfléchissez à deux fois avant de vouloir en imposer d’autres pour votre projet. D’une part, vous allez vous compliquer inutilement la tâche en ne profitant pas du comportement par défaut que propose Maven, et chaque nouvelle option activée pourra se traduire par une nouvelle phase de configuration. À moins d’être passionnés par l’éditeur XML, peu de développeurs 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 projets Java, de manière homogène. Un développeur pourra passer d’un projet à un autre sans perdre son temps à apprendre les petites habitudes locales : où sont les fichiers de configuration ? Dans quel répertoire place-t-on les données de test ? Tous les projets qui se conforment aux conventions Maven seront identiques de ce point de vue, et le développeur sera plus rapidement productif.

Enfin, contrairement à une politique « maison » qui aurait pu établir ce type de conventions, celles de Maven sont partagées par la majorité des développeurs qui ont adopté ce logiciel. Tout nouveau membre de votre équipe qui a déjà travaillé sur un projet Maven trouvera rapidement ses repères. Maven et ses conventions deviennent au fil des années le 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ère une base commune.

La croissance de l’équipe nous permet de rapidement améliorer notre prototype. Le nombre de bibliothèques nécessaires au projet augmente. Nous commençons par introduire Spring pour rendre le code plus évolutif avec l’utilisation des concepts de l’injection de dépendances. Ensuite, nous remplaçons tout le code écrit en JDBC par Hibernate et Java Persistence API. Nous développons une interface web sympathique basée sur Wicket et, enfin, nous faisons appel à Apache CXF pour exposer nos services à d’autres applications sous forme de services web.

Le nombre de bibliothèques croît exponentiellement car, au-delà de la gestion de celles que nous utilisons explicitement au sein du projet, il faut gérer toutes les bibliothèques qui leur sont nécessaires. Rapidement, le répertoire lib se retrouve chargé de dizaines de fichiers JAR avec des noms plus ou moins hétéroclites.

Les choses se compliquent alors significativement et la moindre mise à jour d’une bibliothèque relève d’un casse-tête chinois.

D’une part, cette pratique encourage à utiliser ces bibliothèques telles quelles, sans chercher à s’assurer de leur origine ou de la fiabilité de leur téléchargement. Comme il est délicat de comparer deux versions d’un fichier binaire, il nous est impossible de savoir en quoi notre fichier util.jar diffère de celui utilisé sur un autre projet comparable, dont nous voulons importer des classes intéressantes. Même si ces deux fichiers portent le même nom et ont la même taille, cela ne signifie pas qu’ils soient identiques. Seule une comparaison binaire pourrait nous en assurer.

Autant dire qu’avec les dizaines de bibliothèques embarquées dans notre projet, plus personne ne fait scrupuleusement cette vérification, et nous nous contentons de lire le nom de l’archive mail-1.2.jar pour identifier la bibliothèque JavaMail.

Cela nous amène à un second problème possible. Supposons que cette bibliothèque ait été corrompue lors de son téléchargement depuis le site de SUN qui la diffuse ou de son enregistrement dans notre SCM. Un transfert réseau n’est jamais 100 % garanti, et un seul bit modifié peut rendre la bibliothèque inutilisable, sans parler de ces charmants petits virus qui peuvent traîner un peu partout. L’identification du problème peut être extrêmement complexe, car la remise en cause de la bibliothèque sera probablement la toute dernière hypothèse que nous évoquerons pour justifier un dysfonctionnement.

Maven propose une approche à l’opposé de ces pratiques hasardeuses. Il se focalise sur l’identification exacte des bibliothèques utilisées. Des référentiels de bibliothèques sur Internet lui sont dédiés et permettent de télécharger les bibliothèques précises, utilisées dans le projet, sans ambiguïté. Les risques d’erreur de transfert sont éliminés par un contrôle automatique basé sur des fonctions de hachage (une sorte d’empreinte digitale du binaire, qui sera invalidée au moindre bit différent).

L’identification d’une bibliothèque utilisée par un projet s’appuie sur un triplet (identifiant de groupe, identifiant d’artefact, version précise), lequel est construit sur le même principe que celui que nous avons déclaré pour notre projet. Dans le fichier POM de Jason, nous référençons l’artefact mail de la bibliothèque standard javaMail dans sa version 1.4.

Il n’y a ici aucune équivoque possible. Toute autre variante de JavaMail possédera dans le dépôt Maven un numéro de version différent. Si nous devions nous-mêmes appliquer un correctif, nous devrions utiliser un numéro de version adéquat, comme 1.4-patch-1234. Dans ce cas, cette bibliothèque modifiée serait placée dans notre dépôt privé, comme nous le verrons au Chapitre 6.

Notre projet inclut également une mystérieuse bibliothèque util.jar. Nicolas ne se souvient pas du tout de l’origine de ce fichier. Les équipes de maintenance, confrontées à ce cas de figure, auraient du fil à retordre. Comment gérer une mise à niveau ou un bogue rencontré dans la bibliothèque considérée si on est incapable de l’identifier avec précision ?

Dans le contenu de cette archive Java, les packages utilisés, org.apache.commons.io, nous mettent sur la piste, et c’est ce qui a inspiré à Jason la déclaration d’une dépendance vers Apache Commons-io. Cependant, il pourrait s’agir d’une version modifiée, pour une quelconque raison, avec je ne sais quel impact possible sur l’application.

L’identification exacte réclamée par Maven oblige à préciser quelle version est utilisée et à définir des numéros de version pour chaque variante de la bibliothèque ou version modifiée que l’on voudrait utiliser.

Ajouter une bibliothèque à un projet Maven se traduit simplement par l’ajout d’un bloc <dependency> comparable à notre exemple, identifiant sans équivoque notre intention. Pas de script à éditer, pas de fichier JAR à télécharger et donc pas de validation du fichier téléchargé ; pas de répertoire de bibliothèques à modifier, avec les risques d’erreur de synchronisation qui en découleraient. Mettre à jour une bibliothèque consiste tout simplement à modifier l’information de version qui lui est associée.

La configuration par défaut de Maven utilise le dépôt (ou référentiel) de bibliothèques http://repo1.maven.org/maven2/. Ce site, maintenu par la communauté Maven, compte plusieurs dizaines de gigaoctets de bibliothèques libres de diffusion, et il est mis à jour plusieurs fois par jour. Nous verrons au fil des prochains chapitres comment utiliser d’autres dépôts et en construire un pour nos besoins propres.

À partir de notre déclaration de dépendance, Maven va construire l’URL du sous-répertoire dédié à la bibliothèque indiquée :

<URL du dépôt> / <groupId en tant que chemin> / <artifactId> / <version>

Pour notre dépendance à JavaMail, nous obtenons : http://repo1.maven.org/maven2/javax/mail/mail/1.4/.

Le sous-répertoire dédié à JavaMail 1.4 sur le dépôt de bibliothèques.

En plus du fichier JAR de la bibliothèque attendue, nous trouvons de nombreux autres fichiers dans ce répertoire : 

Que propose Maven pour cette situation ? Nous avons vu qu’il nous demande de déclarer les dépendances plutôt que de fournir nous-mêmes les binaires ; aussi, notre dernière option – prendre la distribution telle quelle et la fusionner avec notre répertoire lib – n’est pas applicable. Maven va-t-il nous obliger à éplucher la documentation de chaque bibliothèque utilisée ?

Maven est autrement plus subtil : jetez un coup d’œil quelques pages en arrière, sur le contenu du répertoire lib de notre projet initial : 

Nous utilisons trois bibliothèques, la première est l’API JavaMail, la deuxième le Bean Activation Framework, nécessaire au bon fonctionnement de JavaMail, et enfin le mystérieux util.jar qui s’est avéré être Apache commons-io. Le fichier POM.xml ne compte que deux entrées <dependency>, là où notre projet nécessite trois bibliothèques. Jason aurait-il été un peu trop vite ?

Si vous jetez à nouveau un œil aux traces de téléchargement dont Maven nous a abreuvé au premier lancement, vous constaterez qu’il télécharge à la fois des fichiers POM et des fichiers JAR – comme s’il ne téléchargeait pas déjà assez de choses !

Ces fichiers POM, au même titre que celui de notre projet, décrivent les bibliothèques auxquelles ils sont associés. Pour JavaMail, l’archive mail-1.4.jar est ainsi accompagnée d’un mail-1.4.pom. Il s’agit bien d’un fichier Project Object Model, au même format XML que pour notre projet et qui comprend des déclarations comparables, en particulier des dépendances. C’est ici qu’est indiqué le lien entre JavaMail et le Bean Activation Framework. Cela permet à Maven de savoir que tout projet qui utilisera l’API JavaMail aura nécessairement besoin du JAR Activation. Si celui-ci a aussi des dépendances, la chaîne se poursuivra, jusqu’à ce qu’un graphe complet de bibliothèques interdépendantes soit construit.

On parle, pour ces données qui décrivent la bibliothèque, de « métadonnées ». Il s’agit d’une version compacte et normalisée au format POM des informations que nous aurions pu obtenir en lisant la documentation de la bibliothèque : sa licence, le site web qui l’héberge, et ses prérequis. L’exploitation automatisée de ces données permet à Maven de construire l’arbre des dépendances du projet, chaque nouvelle feuille pouvant, par ses propres métadonnées, introduire de nouvelles branches.

Arbre de dépendances transitives.

Cet arbre, extrêmement difficile à construire à la main et douloureux à maintenir, est analysé automatiquement par Maven à chaque exécution. Il s’assure que l’ensemble des bibliothèques nécessaires est présent et il construit ainsi le chemin de classes utilisé par le compilateur. Maven va également gérer les problèmes de conflit de versions, lorsque l’arbre fait apparaître plusieurs fois la même bibliothèque dans des versions différentes. Le mécanisme utilisé est cependant limité par la liberté laissée aux numéros de versions qui rend délicate une comparaison 100 % déterministe.

Cette dernière fonctionnalité finit par nous convaincre définitivement. Aussi, nous abandonnons nos différents scripts et adoptons les conventions de Maven pour la suite du développement de noubliepaslalistedescourses. Les développeurs sont nombreux à choisir Maven pour sa gestion des dépendances. N’oubliez pas, cependant, tous les points que nous avons déjà vus, et en quoi cela différencie Maven d’autres outils de construction de projet. Maven n’est pas juste un outil de gestion des dépendances, pour lequel il existe d’autres très bons outils comme Apache Ivy qui sont utilisables depuis un script Ant.

Ayez bien en tête les points forts et la philosophie de Maven, si vous envisagez de convertir un projet existant, car vous devrez probablement en repenser l’organisation, et pas juste écrire quelques fichiers POM pour déclarer vos dépendances.

Notre problème vient de la nécessité d’associer à chaque dépendance du projet le contexte dans lequel elle doit intervenir. S’agit-il d’un élément indispensable à l’exécution du logiciel ? Est-il utilisé uniquement à des fins de test ? Doit-il être inclus dans l’application ou est-il intégré dans l’environnement d’exécution ?

La déclaration d’une dépendance Maven permet de définir un élément supplémentaire, le « scope » dans lequel la dépendance devra s’appliquer. Nous pouvons ainsi préciser que la bibliothèque jUnit n’est utilisée que durant la phase de test et que l’API servlet ne doit pas être intégrée dans notre archive web.

Maven exploite ces données supplémentaires lorsqu’il exécute les commandes de construction du projet. Avec cette précision, jUnit ne sera pas inclus sur la liste des bibliothèques référencées par la commande de compilation. Maven aurait ainsi identifié notre bogue immédiatement.

Avec le nombre de frameworks que nous avons intégrés à l’application, il devient difficile de savoir lequel introduit quelle dépendance. Même si les exclusions peuvent permettre de corriger le tir, encore faut-il savoir sur quelles dépendances les déclarer.

Maven propose un outillage complet pour analyser nos dépendances, via les plugins dependency et project-info-reports.

La commande mvn dependency:list permet d’établir la liste des dépendances du projet, soit l’équivalent de notre répertoire WEB-INF/lib. Elle sera utile pour vérifier l’impact de nos exclusions au fur et à mesure que nous les déclarerons.

La commande project-info-reports:dependencies est analogue à la précédente mais elle génère un fichier HTML contenant la liste des dépendances.

Plus intéressante, mvn dependency:tree trace un arbre, où chaque branche est une dépendance qui introduit par transitivité d’autres dépendances.

L’analyse de cet arbre permet d’identifier les bibliothèques qui font appel à commons-logging-api et d’exclure cet intrus de notre projet.

Ces commandes bien pratiques restent assez spartiates, cantonnées dans la console. L’intégration de Maven dans les environnements de développement en offre une version nettement plus ergonomique. La Figure 02-03 présente le plugin Maven pour Eclipse (m2eclipse) et sa fenêtre d’analyse des dépendances. Si on sélectionne une dépendance dans la zone de droite, il nous indique tous les chemins de dépendance qui y mènent. Un simple clic permet de placer les exclusions qui s’imposent sans éditer manuellement le fichier POM.

Plugin Maven pour Eclipse.

En rejoignant le projet, Emmanuel apporte dans sa musette bon nombre d’idées innovantes et de petites expériences amusantes à nous présenter. Entre autre, Emmanuel a testé un outil rigolo, une implémentation de JCR sur la base NoSQL Cassandra. Rien que l’assemblage que cela représente attise notre curiosité. Place à la démo !

Oups :

« WTF ? » comme on dit outre-Atlantique ^[8], ce que nous ne traduirons pas ici par respect pour nos lecteurs et la qualité de ce récit. Maven s’acharne – et échoue – à télécharge la bibliothèque jcr-on-cassandra :

Emmanuel vérifie trois fois, la bibliothèque jcr-on-cassandra dont il veut nous montrer le potentiel est bien dans son dépôt local, pourtant – rien à faire – Maven fait la sourde oreille. Il est temps de faire appel à nos experts…

Maven utilise par défaut un dépôt nommé central, qui héberge un vaste choix de bibliothèques Open Source. Pour une grande majorité de développements, ce dépôt sera suffisant pour nous fournir toutes les dépendances nécessaires. Il arrive cependant régulièrement qu’un projet ne contribue pas à ce dépôt et préfère héberger son propre dépôt interne, souvent en prétextant plus de simplicité de mise en œuvre ou une meilleure maîtrise de ses infrastructures.

Pour accéder à un dépôt de ce type, Maven nous demande de l’ajouter explicitement à notre POM, sous forme d’un bloc <repository> comme celui qu’Arnaud a identifié dans le projet d’exemple de jcr-on-cassandra :

Le dépôt local de Maven 3 n’est pas juste un cache d’accès à Internet. Il permet aussi à Maven de tracer l’origine de chaque dépendance, à savoir d’où elle a été téléchargée. Notre projet ne déclarant pas l’URL geek.org, les bibliothèques associées ne sont pas accessibles pour notre build, même si elles sont présentes physiquement.

Après avoir ajouté la déclaration de dépôt manquante, Emmanuel peut enfin lancer sa démo et nous présenter toutes ses idées.

Nous l’avons déjà dit, les conventions de Maven sont un élément décisif dans sa capacité à prendre en charge de manière automatisée le projet. En particulier, la structure type d’un projet Maven est la suivante (voir Figure 03-02) :

La structure de base d’un projet Maven.

La logique est plutôt simple : à la racine, on trouve le fichier POM qui gouverne toute la gestion Maven du projet. L’ensemble des sources est placé dans un répertoire src, tandis qu’un répertoire target sert de zone temporaire pour toutes les opérations réalisées sur le projet. Cela a au moins l’avantage de faciliter grandement la configuration de votre gestionnaire de code source ! Il suffit d’exclure target (en plus des fichiers spécifiques de votre EDI) et vous êtes sûr de ne pas inclure par mégarde des fichiers de travail qui n’ont pas à être partagés.

Sous le répertoire des sources, Maven effectue un découpage explicite entre ce qui fait partie du projet – ce que vos utilisateurs vont utiliser – et ce qui sert d’outillage de test. Deux sous-répertoires, main et test, marquent cette distinction.

Enfin, dans chacune de ces branches, un dernier niveau de répertoire sépare les fichiers sources par langage : Java pour le code source de vos classes java, resources pour les fichiers de ressources (configuration XML ou fichiers de propriétés…), webapp pour les fichiers statiques d’une application web.

Le plugin Groovy ajoute son lot de conventions qui viennent compléter celles déjà définies par Maven. Les fichiers source Groovy ont ainsi leur propre répertoire de code source sous src/main/groovy. Il en est de même pour les tests écrits dans ce langage avec src/test/groovy. Ces conventions sont alignées sur celles de Maven pour obtenir un ensemble cohérent. D’autres plugins qui apportent le support de langages autres que Java suivront la même logique.

Ces répertoires créés pour accueillir le code, il nous reste à déclarer le plugin Groovy dans notre POM. Sur l’exemple du plugin compiler, nous ajoutons :

Au lancement de Maven, nous constatons avec plaisir le téléchargement de fichiers POM et JAR associés au plugin Groovy. Voici une autre explication de la dépendance de Maven à un accès Internet : les plugins, comme les bibliothèques, sont téléchargés à la demande depuis un dépôt de bibliothèques. L’installation de Maven est ainsi limitée à un noyau et tous les plugins qui lui permettent d’exécuter des tâches sont obtenus au moment de sa connexion au réseau, d’où les interminables téléchargements lors de la première exécution !

Cependant, nos sources Groovy ne sont pas prises en compte, et les traces d’exécution de la console ne laissent entendre aucun traitement particulier de ce langage. Nous avons dû brûler une étape…

La notion de plugin permet à Maven d’isoler, dans un sous-projet dédié la gestion, des opérations élémentaires qui sont utilisées pour construire divers projets. Cela ne signifie pas pour autant qu’un plugin n’est concerné que par un seul traitement. Si l’on reprend l’exemple du plugin de compilation, celui-ci doit compiler le code source Java de l’application, mais aussi le code source des tests. Un plugin regroupe donc des tâches élémentaires qui partagent un même domaine.

Chaque plugin définit ainsi plusieurs tâches (ou goals) et il ne suffit pas de déclarer un plugin pour ajouter un traitement à notre projet ; nous devons également préciser lequel (ou lesquels) de ces traitements unitaires nous souhaitons intégrer à la construction du projet.

Un élément <execution> permet de définir les tâches définies par le plugin considéré que Maven devra exécuter.

Le cycle de vie du projet et les plugins qui viennent s’y greffer.

Miracle, nous pouvons compiler notre code source Groovy. Sortez la boule à facettes !

Les commandes que nous avons passées jusqu’ici étaient de la forme mvn xxx, avec pour xxx la phase de construction du projet que nous désirerions atteindre, par exemple compile. Maven permet également d’invoquer directement un plugin, et lui seul, via une forme différente de la ligne de commande :

Ici, nous ne demandons pas la construction du projet, mais l’exécution isolée de la tâche run du plugin GWT. Il s’agit d’ailleurs d’une version contractée de la commande complète :

Le raccourci est appréciable, mais il vaut mieux garder en tête cette syntaxe qui pourra parfois se révéler indispensable.

L’invocation directe d’un plugin n’est généralement utile que pour des tâches annexes du projet, comme ici le lancement du serveur web de développement de GWT. La plupart des plugins et des tâches qu’ils définissent sont prévus pour se greffer dans le cycle de construction du projet. Il est donc inutile d’invoquer directement une tâche d’un plugin qui n’a pas été prévu dans ce sens ; d’ailleurs, cela aboutirait dans la majorité des cas à une erreur.

Cette nouvelle découverte nous amène à nous demander ce qui différencie dans ce plugin GWT la tâche run de la tâche compile. La première s’exécute seule par invocation directe, la seconde sait se greffer dans le cycle de construction du projet. Mais comment fait Maven pour déterminer quand l’exécuter ?

Ce que nous avons jusqu’ici qualifié de « projet type » utilisé par Maven pour identifier et enchaîner les tâches de base d’un projet Java est en réalité composé de deux éléments : le cycle de vie d’un côté, et les plugins et tâches qui y sont attachés de l’autre.

Le cycle de vie est une série de phases ordonnées qui doit couvrir les besoins de tout projet. Ces phases sont purement symboliques et ne sont associées à aucun traitement particulier, mais elles permettent de définir les étapes clés de la construction du projet. On retrouve ainsi :

Tableau 3.1 : Le cycle de vie défini par Maven

Il s’agit d’une liste simplifiée : le cycle complet définit de nombreuses phases intermédiaires, dont vous trouverez la description complète dans la documentation en ligne de Maven ^[15].

Quels que soient le projet et ses particularités, tout traitement réalisé pour le « construire » viendra naturellement se greffer sur l’une de ces étapes.

Pour un projet standard (sans indication de <packaging>), Maven considère que le binaire à construire est une archive JAR. Chaque plugin propose des tâches qui correspondent à un traitement unitaire. Maven associe un certain nombre de tâches à ces phases du cycle de vie. La tâche compile du plugin de compilation, par exemple, est associée à la phase compile, et la tâche jar du plugin d’archivage à la phase package. L’invocation de la commande mvn deploy va alors dérouler une à une les étapes du cycle de vie jusqu’à la phase demandée (deploy), et exécuter pour chacune d’elles les tâches des plugins qui lui sont associés :

Tableau 3.2 : Les plugins et les tâches associés par défaut au cycle de vie d’un projet JAR

Maven fournit un moyen pour venir greffer d’autres plugins à ce cycle, en plus de ceux qu’il aura associés par défaut.

Cycle de vie du projet et plugins exécutés pour chaque phase.

Pour limiter ces risques, il existe une pratique simple et particulièrement efficace : l’automatisation des tests ! Un mécanisme automatique ne coûte pas grand-chose à l’exécution. En dehors de la machine qu’il monopolise, il ne réclame pas d’augmentation ni de congés. Il peut être très rapide et ne se lasse pas de ce qu’on lui demande de faire. Même après des centaines de répétitions, il sera tout aussi regardant sur le résultat qu’il est censé vérifier. Nous devons donc voir les tests comme un traitement informatique intégré dans notre projet. La création des tests, même si elle a un coût, est avant tout un investissement qui nous prémunit des régressions dans le futur, et qui améliore l’évolutivité de notre logiciel en levant l’angoisse : « Je ne touche pas au cas où je casserais quelque chose. » Les tests automatisés sont un véritable vecteur pour l’amélioration de la productivité des équipes puisqu’ils leur permettent de se concentrer sur le logiciel en toute quiétude même si une partie importante du code doit être refactorisée.

La solution la plus élémentaire pour mettre en place des tests automatisés consiste à intégrer dans le code des fragments de tests, en général sous forme d’une méthode main chargée de vérifier le fonctionnement de la classe qui la définit, comme dans l’exemple du Listing 4.1.

Cette pratique est cependant très discutable. D’une part, elle nécessite de passer par un lanceur qui va exécuter toutes les méthodes main des tests, l’automatisation n’est donc pas complète. Ensuite, notre projet va embarquer dans son code binaire le code de test, qui n’a pas grand intérêt pour les utilisateurs. Si l’augmentation de la taille du fichier JAR n’est pas en soi un problème bloquant, cela n’est pas conceptuellement très satisfaisant.

Malgré ces quelques reproches, considérons tout de même cette option qui a l’avantage d’être simple et a d’ailleurs été une pratique courante en développement Java.

Pour améliorer la capacité de notre test à identifier un problème, nous allons contrôler le contenu de l’objet ListeDeCourses lu lors de l’exécution du test. Nous nous basons donc sur une comparaison entre un objet ListeDeCourses attendu et l’objet ListeDeCourses effectivement construit lors de l’exécution du test. Pour ne pas devoir écrire la comparaison entre ces deux objets (attendu vs effectif), nous faisons appel à la classe BeanComparator de la bibliothèque éprouvée commons-beanutils ^[19] qui fait ce travail pour nous en une seule ligne de code, ce qui rend le test plus simple et plus lisible. Inutile de réinventer la roue et de venir compliquer le code alors que cette classe simplifie tellement la tâche et nous permet de nous focaliser sur notre objectif : tester de manière automatique autant de fonctionnalités que possible. Le Listing 4.2 montre cette évolution de notre méthode de test.

Très fiers de notre mécanisme de test automatisé, nous lançons donc la version fraîchement compilée de l’application sur notre serveur de test. Et là, c’est la douche froide :

Que s’est-il passé ? L’introduction d’une nouvelle bibliothèque pour simplifier l’écriture du test a créé des imports dans le code, imports qui ne peuvent être résolus sur le serveur de test, car nous n’avons pas ajouté la bibliothèque commons-beanutils à l’environnement de test. Cela n’aurait aucun sens car, en dehors de ce test, elle n’est absolument pas nécessaire !

Faut-il alors renoncer à utiliser des bibliothèques dans les tests et se contenter du seul JDK ? Bien sûr que non ! Cela voudrait dire que nous plaçons les tests au second plan et que nous nous interdisons d’en faire quelque chose d’intelligent et de facile à écrire. De toute évidence, la solution de la méthode main pour tester montre de graves limites.

Nous ne sommes pas les premiers à faire ce constat, et la réponse existe depuis bien longtemps à travers des outils de test spécialisés pour Java, dont le plus connu d’entre eux est jUnit ^[20].

Ces outils reposent sur des principes simples :

Pour tester notre ListeDeCoursesReader avec jUnit, nous allons donc écrire une classe ListeDeCoursesReaderTest, y créer une méthode testLectureDeuxElements, et y transférer notre code de test. Le Listing 4.3 montre cette transformation de notre code :

Cette nouvelle organisation nous permet de ne pas polluer le code de notre projet, sans pour autant renoncer à nos tests automatisés. Elle fournit un cadre simple pour l’écriture de ces tests et des méthodes utilitaires pour nous aider à les écrire simplement. Elle nous propose de prendre en charge l’exécution de nos tests, en fournissant via une interface graphique un compte rendu synthétique pointant immédiatement les erreurs rencontrées. Ce rapport est en particulier parfaitement intégré dans les environnements de développement comme Eclipse, NetBeans ou IntelliJ Idea.

L’objectif de cet ouvrage n’est pas de détailler le fonctionnement de jUnit. Nous ne pouvons donc que vous conseiller de consulter le site junit.org et les nombreux ouvrages consacrés au sujet. Signalons cependant que jUnit n’est pas le seul candidat pour l’écriture de tests, et qu’il partage ce terrain en particulier avec son challenger TestNG et avec sa propre version « modernisée » jUnit4. Chacun a ses points forts, aussi nous vous laissons choisir l’outil le plus approprié à vos besoins et à vos habitudes de travail.

Nous avons vu que la bibliothèque commons-beanutils nous a joué un mauvais tour. Bien pratique pour simplifier l’écriture de notre test, elle venait perturber notre application. Maintenant que le test possède sa propre classe dédiée, ce problème est en principe résolu. Cependant, les utilisateurs d’EDI font confiance à leur environnement pour gérer les imports et peuvent se faire piéger à nouveau. Il est si facile d’ajouter un import en saisissant juste le début du nom d’une classe qu’il n’est pas rare de terminer son travail avec quelques imports inutiles. L’EDI peut également faire le ménage pour nous, mais qu’il laisse passer une coquille par mégarde n’est pas exclu.

Contrairement à un projet dans les EDI courants, un projet Maven a deux visages bien définis : la branche principale (src/main), portant le code de l’application et les dépendances qui lui sont associées dans le POM, et la branche test (src/test), portant l’outillage de contrôle ainsi que ses dépendances dédiées. En effet, une dépendance déclarée dans le POM porte une indication de scope, qui permet à Maven de savoir quand telle ou telle bibliothèque doit être utilisée par les outils de compilation. Lorsque le scope porte la valeur test, il est exclu de l’application et ne sera utilisé que pour la compilation et l’exécution des tests.

Si l’assistance de l’EDI nous a fait intégrer par erreur des classes normalement dédiées à notre outillage de test, la compilation par Maven échouera en signalant immédiatement le problème. Nous pouvons donc faire appel à tous les utilitaires possibles et imaginables qui nous aideront à écrire nos tests de manière plus efficace et sans risquer de polluer l’application.

Le choix d’outils de tests est parfois plus délicat que le choix de l’infrastructure de notre logiciel. Pour être pertinents et bien couvrir les besoins, les tests doivent rester simples et performants et pouvoir utiliser les ressources de nombreuses bibliothèques. La gestion de dépendances transitives de Maven nous ouvre les portes d’outils de test et de simulation très avancés, avec une simplicité de mise en œuvre déconcertante.

Les tests automatisés que nous venons d’ajouter à notre projet nous offrent un garde-fou intéressant. À de nombreuses reprises, ils nous signalent qu’une « petite modification » s’avère bien plus significative que ce que nous avions pensé.

Au cours d’une discussion sur les nouvelles idées que nous avons eues pour notre projet, Vincent propose de changer le format du fichier dans lequel nous stockons la liste de courses. Cette modification permettra de stocker des données complémentaires, dont je vous laisse le soin d’imaginer l’utilité.

Nos tests existants permettront de vérifier que ce nouveau format ne perturbe pas le code existant, mais Vincent va plus loin. Avant même que nous n’ayons déterminé comment nous allions lire ces nouvelles données depuis le fichier, il commence à écrire une nouvelle méthode de test vérifiant que les informations supplémentaires ont été correctement lues. Aurait-il « oublié » que, pour que le logiciel fonctionne, il faut à un moment ou un autre réaliser son code ?

Une fois son test écrit, Vincent le lance et ne semble même pas vexé de voir son écran afficher dans un rouge sang le résultat assez prévisible :

Vincent est tout simplement un adepte du développement piloté par les tests (Test Driven Development ou Test First). Plutôt que de tester son code, il préfère écrire des tests qui décrivent précisément ses attentes, puis écrire le code qui sera capable de faire passer ses tests au vert. La différence est étonnamment efficace en termes de structuration du logiciel. Plutôt que d’être guidé par des contraintes techniques ou par des considérations de pur informaticien, chaque élément du logiciel n’existe que parce que la bonne exécution d’un test nécessite son existence. Comme chaque test est guidé par un besoin, écrit avant même que l’on n’ait commencé à se torturer l’esprit avec la réalisation, le code répond de manière simple et juste aux besoins.

La sur-ingénierie est une dérive courante de l’informatique où des composants deviennent inutilement complexes au regard de la fonctionnalité à rendre, simplement pour répondre à des considérations purement techniques qui n’apportent rien à l’utilisateur.

Vincent a donc écrit d’abord une méthode de test simple, focalisée sur sa nouvelle idée et uniquement guidée par ce qu’il attend du logiciel et non pas par l’idée qu’il a derrière la tête concernant les technologies qui vont l’aider, ou le code qu’il va mettre en œuvre. Après cette phase préparatoire qu’on pourrait qualifier dans un vocabulaire plus traditionnel d’expression de besoin, Vincent est content de voir son test échouer : le test est valide et vérifie bien quelque chose que l’application ne fournit pas encore. Ne riez pas, trop souvent des tests ne font qu’effleurer l’application et n’échouent pas si l’on supprime le code censé être testé !

Vincent commence ensuite la réalisation. Après quelques lignes de code, le test lancé à nouveau échoue encore mais sur un cas d’erreur moins abrupt :

Le code commence donc à se mettre en place mais ne répond pas encore aux attentes. Quelques minutes plus tard et après les corrections qui s’imposent ont été apportées, le test passe enfin au vert.

Cette façon de travailler est un moyen très puissant de structurer ses développements en fonction du résultat à atteindre et non en répondant à nos pulsions d’informaticiens avides de code. Une règle de base du développement piloté par les tests est qu’aucun code ne doit être écrit s’il n’est pas rendu indispensable par un test. Autrement dit, d’une part, du code non testé ne devrait pas exister, et d’autre part, du code qui n’est pas guidé par un besoin fonctionnel n’a rien à faire dans un logiciel intelligemment construit.

La réalisation du code qui répond à son test lui a permis d’identifier de nouvelles portions de code très proches d’autres déjà existantes. Il aimerait bien les regrouper dans des méthodes communes. La duplication de code est l’ennemi d’un logiciel évolutif et fiable, aussi Vincent applique le second commandement du développement piloté par les tests : DRY (Don’t Repeat Yourself – « Tu ne te répéteras pas »).

Armé de ses tests, tous focalisés sur des aspects unitaires ou fonctionnels de l’application, il peut faire toutes les opérations de réingénierie qui lui semblent nécessaires pour arriver à un bon niveau de structuration. Chaque modification apportée est contrôlée par les tests existants qui assurent ainsi que le logiciel reste fonctionnellement équivalent. L’outillage de test en place permet à présent de se focaliser sur des aspects purement techniques, pour ne pas dire esthétiques, concernant l’organisation de notre code : niveau d’abstraction, évolutivité, lisibilité. Chaque modification que nous lui apporterons afin d’en améliorer la qualité pourra être validée d’un point de vue des fonctions rendues par l’application : nos tests doivent tous rester au vert. Certaines modifications lourdes et pourtant importantes n’auraient jamais été réalisées en confiance sans cette garantie.

Développement piloté par les tests.

Le développement piloté par les tests est une pratique préconisée par de nombreuses méthodes agiles ^[21]. Sa mise en œuvre efficace nécessite une culture du test automatisé pour être réellement efficace. Maven participe à cette démarche par la place qu’il donne au test dans le cycle de vie du projet. Les tests vus par Maven sont des éléments de premier plan du projet.

Le passage des tests par Maven fait partie des phases standard de construction du projet. Maven les place au cœur de la gestion de la qualité et fait le choix de bloquer la construction du projet si un test échoue. Comme ces tests sont exécutés avant que la phase de packaging qui construit le JAR ne soit exécutée, Maven interdit donc de construire un livrable qui ne passe pas avec succès tous les tests définis par le projet. C’est une interprétation rigoureuse des principes de qualité logicielle, mais qui évite d’utiliser par mégarde un JAR fraîchement compilé et de découvrir de manière détournée et coûteuse un bogue qui est déjà contrôlé par un test unitaire.

Interdire la construction du JAR, n’est-ce pas un peu abrupt comme prise de position ? C’est en tout cas l’avis de Fabrice, qui tue le temps dans le TGV en testant rapidement quelques nouvelles idées et qui ne parvient pas à lancer l’application. Ses modifications, réalisées en mode « exploratoire », ne visent qu’à tester un nouveau concept et certainement pas à obtenir un résultat stable et irréprochable.

Maven met certes les concepts de qualité logicielle au premier plan mais ne manque cependant pas de pragmatisme. Il existe une option qui permet de ne pas passer les tests lors de la construction du projet, et donc de passer outre cette règle parfois trop stricte. Cette option, ajoutée sur la ligne de commande, est –DskipTests. C’est une option à double tranchant, soyez-en bien conscient. Elle peut être indispensable, comme le pense Fabrice qui peut ainsi vérifier la pertinence de son idée, auquel cas il pourra la présenter à son client à l’arrivée de son voyage d’affaires. C’est une option dangereuse si elle est trop utilisée et que nos tests automatisés ne sont plus exécutés.

Au fur et à mesure de l’écriture des tests, nous avons dû développer des classes utilitaires qui n’ont de sens que dans le cadre des tests : code bouchon et simulateur, mécanisme de contrôle et autres constituent un outillage complet dédié à notre code afin que nous soyons en mesure de le tester convenablement.

En marge de notre projet, Lukas se lance dans un autre projet expérimental pour proposer une version sur téléphone mobile de notre application – une cible de choix qu’il ne faut pas négliger !

Lukas est rapidement confronté à un problème simple : dans son environnement de développement, il dispose des deux projets et peut donc coder les tests de son projet noubliepaslalistedescourses-on-android en réutilisant nos utilitaires de test. Cet outillage lui simplifie grandement la tâche et lui permet d’écrire des tests pertinents et lisibles en un temps record. Seulement, lorsqu’il tente de construire son projet avec Maven, la compilation de ses tests échoue systématiquement : nos utilitaires ne sont pas vus par le compilateur.

Cette situation en apparence paradoxale est simple à expliquer. La majorité des environnements de développement intégrés ne différencient pas – contrairement à Maven – les bibliothèques utilisées pour écrire le code et celles associées aux tests. En référençant le projet noubliepaslalistedescourses, l’environnement donne accès à toutes ses classes et dépendances, sans distinction. Maven par contre s’appuie sur le JAR qui a été construit par chaque projet, et sur lui seul. Nos utilitaires de test ne sont accessibles qu’au cours de la construction du projet qui les définit et pas en dehors. Le projet de Lukas ne peut donc exploiter que les classes qui sont destinées à l’inclusion dans le JAR final, et pas la panoplie de tests qui les accompagne.

Copier-coller ces classes est évidemment hors de question, et nous ne pouvons demander à Lukas de réécrire entièrement ses tests sans ce code de support qui lui a fait gagner tant de temps. La solution, Maven la fournit via le plugin JAR, responsable de la construction de notre archive.

Comme nous l’avons vu, le plugin JAR est attaché par défaut au cycle de construction du projet lors de la phase de packaging et sa tâche jar construit l’archive – rien de très surprenant. Ce plugin définit d’autres tâches, en particulier une qui va nous sauver la mise : test-jar. Celle-ci permet de construire en parallèle du JAR du projet un second JAR, contenant cette fois les classes et ressources de test. Le Listing 4.5 montre la configuration associée au plugin JAR pour obtenir ce résultat. Le fonctionnement par défaut suffit à notre besoin, aussi l’ajout de ce traitement ne nécessite aucun élément de configuration particulier.

Cette seconde archive partage les métadonnées du projet (le POM). Il ne s’agit pas d’un second projet Maven contenant nos tests, mais bien d’un aspect secondaire de notre unique projet dont Maven se propose de gérer la construction. La différenciation entre l’artefact principal du projet et des résultats secondaires de ce type s’appuie sur un suffixe ajouté au nom de l’artefact, ce que dans le vocabulaire Maven on nomme un classifier. La tâche test-jar va construire un artefact nommé noubliepaslalistedescourses-1.0-SNAPSHOT-tests.jar.

Maven peut être configuré pour produire plus d’un artefact lors de la construction du projet et le classifier permet de différencier les artefacts secondaires du principal résultat de la construction. Il est ainsi possible de construire non seulement le JAR du projet, mais aussi le JAR de ses tests, le JAR de son code source ou le JAR de sa documentation JavaDoc. Chacun de ces artefacts secondaires pourra être référencé comme une dépendance en ajoutant l’information de classifier adéquate, comme le montre le Listing 4.6 qui présente le POM du projet de Lukas.

Nous l’avons vu, nos tests automatisés prennent toute leur valeur lorsqu’ils sont exécutés régulièrement. Chaque développeur peut compter sur eux pour vérifier qu’il n’a pas (ou au moins, pas trop, en fonction de la qualité des tests) détraqué l’application avec ses dernières modifications. Cela peut même l’aider à identifier les points à reprendre sur des parties de l’application qu’il ne connaît pas bien ou à structurer ses propres développements.

Une autre utilisation des tests est de rendre leur passage systématique sur une machine dédiée, afin de détecter le plus vite possible une erreur introduite par un développeur qui n’aurait pas identifié le problème par lui-même. Il ne s’agit pas du tout de rechercher le mouton noir qui introduit des bogues et ne vérifie rien sur son environnement. Il n’est pas rare de créer des instabilités parce qu’on a oublié de diffuser un fichier sur le gestionnaire de version ou parce qu’un fragment de code dépend de l’encodage des fichiers sur le système, d’un chemin particulier, ou de la version du JDK utilisée.

Cette machine qui va incessamment analyser notre projet en exécutant tous les tests aura l’avantage énorme sur un contrôleur humain de n’être limitée que par sa rapidité d’exécution pour signaler les problèmes. À la moindre faute, elle pourra se fonder sur la liste des dernières modifications pour signaler aux personnes concernées le problème identifié. Venant d’un automate plutôt que d’un collègue, ce genre de reproche est plus facile à accepter.

Ce contrôle automatisé et incessant fait partie (mais n’est qu’un élément) de l’intégration continue, une pratique introduite par les méthodes de développement agiles. C’est un outil puissant et facile à mettre en place que nous ne pouvons que vous recommander. Même si, dans un premier temps, vous ne l’utilisez que pour contrôler la bonne exécution des tests et identifier au plus tôt les défaillances de vos collaborateurs et les faiblesses de votre application, vous constaterez rapidement ses bénéfices et les bonnes pratiques que vous pouvez en tirer.

Le serveur qui va exécuter nos tests peut se baser sur l’un des nombreux outils disponibles. Nous citerons Continuum, Jenkins et Hudson, mais cette liste est loin d’être exhaustive.

Continuum a été développé par la communauté Maven, avec bien sûr pour objectif de prendre en charge de manière aussi intégrée que possible la structure des projets Maven et les relations de dépendance qu’ils peuvent entretenir. Il ne se limite cependant pas à ce type de projets et peut tout aussi bien accueillir vos projets Ant ou ceux outillés par des scripts.

Son point fort est son excellente intégration des projets Maven. Sur détection d’un changement dans le gestionnaire de code source, Continuum va ainsi construire uniquement le projet impacté puis enchaîner avec tous les autres projets qui l’utilisent et qui pourraient être impactés de manière indirecte par ce changement.

Son premier point faible est son interface web qui ne bénéficie pas des raffinements auxquels nous ont habitués les applications web modernes. Un peu trop de configuration et de changements de page sont nécessaires pour l’exploiter.

Son second et principal point faible est l’absence de mécanismes d’extension permettant des contributions et des adaptations de l’outil à des contextes de projets spécifiques, sans devoir entrer dans les rouages très techniques de l’outil. Par ailleurs, la lenteur de son cycle de développement, qui ne propose une nouvelle version qu’après plusieurs mois, réduit sa capacité à proposer rapidement des évolutions à ses utilisateurs.

Continuum en train de surveiller les projets de Maven 2.

Créé par Kohsuke Kawaguchi, employé de SUN, pendant son temps libre, Jenkins est rapidement devenu un outil incontournable. Son cycle de développement est extrêmement bref, au point qu’il est difficile de choisir une version, la suivante pouvant apparaître dans les jours ou les heures qui suivent. Cette très forte réactivité permet cependant d’apporter rapidement les corrections qui s’imposent et de proposer des fonctionnalités nouvelles par petites touches.

Jenkins n’est pas dédié à Maven et peut tout aussi bien accueillir des projets Ant ou simplement basés sur des scripts. Le support de Maven, bien qu’arrivé tardivement et longtemps considéré comme expérimental, est cependant d’un bon niveau et parfaitement fonctionnel.

Les points forts de Jenkins sont la qualité de son interface web et l’extrême simplicité de son installation. Son principal point faible est l’intégration, en constante amélioration mais toujours perfectible des projets Maven, en particulier ceux répartis en plusieurs modules (voir Chapitre 6).

Le point décisif qui fait de Jenkins un concurrent de choix, c’est sa réactivité de développement. Avec une nouvelle version chaque semaine et une armée de contributeurs sur son écosystème de plugins, Jenkins est un logiciel extrêmement réactif et porteur de nombreuses innovations.

Jenkins, en train de surveiller sa propre construction, respectant l’adage anglo-saxon « eat your own dog food » (« mange toi-même la nourriture de ton chien »).

Hudson est le cousin de Jenkins. Suite au rachat de SUN par Oracle, ce dernier a fait valoir ses droits sur le nom « Hudson », marque déposée et nom historique du projet. Voulant imposer ses règles à la communauté des développeurs, Oracle a provoqué un divorce, qualifiée de fork dans le vocabulaire de l’Open Source. Ainsi est né Jenkins d’une part, continuité naturelle du projet, et Oracle Hudson® de l’autre, développé et supporté par Oracle et ses partenaires.

Techniquement parlant, les deux projets sont relativement identiques à l’heure ou nous écrivons ces lignes, mais ils ne suivront pas les mêmes choix techniques ou organisationnels à l’avenir.

Husdon, lui aussi en train de surveiller la construction de Maven 2, dans la forge Sonatype, partenaire d’Oracle.

Le choix de votre serveur d’intégration continue va dépendre de nombreux critères. Techniquement parlant, il faut qu’il soit adapté à vos environnements, qu’il sache communiquer avec votre gestionnaire de versions et éventuellement à votre outil de suivi de bogues. Il faudra aussi qu’il puisse facilement remonter de l’information aux développeurs, par mail, messagerie instantanée, plugin dans l’environnement de développement ou autre. Dans tous les cas, il faudra vérifier que la compatibilité est au rendez-vous.

Ce ne sont pas les seuls critères à retenir. Nous n’avons vu ici qu’une utilisation très superficielle de l’intégration continue, qui se contente de compiler et de tester régulièrement notre projet pour signaler les erreurs. La pratique d’intégration continue va très au-delà, comme nous le verrons au chapitre suivant. En fonction de votre utilisation, certaines fonctionnalités vous sembleront indispensables et d’autres, inutiles. Les possibilités d’extension et de configuration de ces serveurs sont nombreuses et répondent à des usages et à des règles de fonctionnement très variés.

Quelques pistes pour vous guider :

Les tests unitaires sont des acteurs de premier plan pour introduire la qualité logicielle dans le cycle de développement du projet. Maven les considère comme tels, et son fonctionnement même participe très activement à la promotion de cette pratique.

L’intégration de tests dans un projet nécessite un changement de pratiques et l’appropriation de nouveaux outils, elle n’est donc ni instantanée, ni totalement gratuite. Le « retour sur investissement » est cependant sans commune mesure une fois les bonnes habitudes en place. Un projet outillé par des tests rassure tout le monde sur son niveau de qualité et sa stabilité dans le temps. Livrer un logiciel dont tous les tests sont au vert est autrement plus rassurant pour l’équipe que d’appliquer les derniers correctifs en espérant ne pas avoir introduit d’erreur à quelques heures de la livraison.

Quand nous parlons de tests unitaires, nous considérons des tests simples, ciblés, exécutés dans un environnement léger et totalement sous contrôle. Ces tests sont éligibles à une exécution systématique, car ils peuvent être exécutés rapidement, sans nécessiter de préparation particulière de la machine.

Avec cette définition, nous mettons donc de côté un grand nombre de tests que nous pourrions tout de même automatiser : tests d’interopérabilité, tests de charge et d’endurance, tests nécessitant l’installation du logiciel sur un serveur – typiquement, l’interface web d’une application WAR…

Laisser de côté une gamme aussi large de tests juste parce qu’ils n’entrent pas dans la logique du « tester souvent » de Maven n’est pas une option qui nous mènera bien loin. Ce que nous voulons, c’est intégrer dans la construction du projet de nouvelles tâches mais les conserver optionnelles pour la majorité des développeurs qui ne seront pas concernés. Le mécanisme de profil de Maven offre une solution simple pour que chaque développeur puisse activer les spécificités qui conviennent à sa tâche en cours, sans perdre le bénéfice d’avoir toute la configuration et tout l’outillage nécessaire (ou du moins le maximum) configurés dans le seul fichier POM.

Une autre utilisation des profils consiste à adapter la configuration Maven du projet à l’environnement de l’utilisateur. Il est aussi possible de conditionner l’activation du profil à une spécificité de l’environnement d’exécution, par exemple le système d’exploitation ou la version de Java qui exécute Maven. Une propriété système (définie avec l’option -Dnom=valeur de la ligne de commande) peut aussi servir de condition pour activer un profil. Enfin, le profil peut être activé en fonction de la présence d’un fichier particulier.

Olivier, qui travaille sous Solaris, se sent un peu exclu lorsqu’il voit apparaître dans le projet des dépendances de type DLL pour Windows. Celles-ci sont nécessaires pour un de nos outils de développement mais elles sont également disponibles dans des versions pour Mac ou Linux. Plutôt que d’obliger chacun de nous à télécharger ces trois variantes juste pour être sûr de satisfaire tout le monde, Olivier utilise les profils pour établir une liste de dépendance par type de système.

Le Listing 5.2 montre un autre cas d’activation d’un profil lorsque le système qui exécute Maven est Windows. Cette particularité est exploitée pour ajouter une dépendance qui n’aurait aucun sens sur un autre système : une bibliothèque native DLL.

Un profil peut aussi être déclaré « actif par défaut », auquel cas on considère que le fait de ne pas exécuter les tâches qu’il déclare est une exception au mode de construction standard du projet mais qui peut se justifier dans certains cas. Un profil actif par défaut peut être désactivé (à partir de Maven 2.0.10) depuis la ligne de commande via l’option -P, mais en faisant précéder son nom du symbole « ! », qui représente la négation, comme en Java. Supposons, par exemple, que votre projet exploite des règles de codage strictes, mais que vous admettez que vos développeurs puissent vouloir tester leur code avant de s’assurer qu’elles sont strictement respectées. Le Listing 5.3 présente une configuration de ce type. La commande suivante permet de déroger à cette règle le temps d’une exécution de Maven :

Les profils sont ainsi un mécanisme puissant que propose Maven pour offrir plusieurs visages à un projet, sans perdre le bénéfice d’une configuration unique pour tous. En activant les profils qui correspondent à son rôle dans l’équipe, un développeur peut faire coller le comportement de Maven à sa tâche courante. Il ne devra pas perdre un temps précieux à chercher de lui-même des moyens de contournement pour des traitements qui lui importent peu ou qui ne le concernent pas.

Le serveur d’intégration continue est utilisé pour l’instant pour valider l’exécution de nos tests unitaires. L’objectif est qu’il réagisse très vite pour nous signaler une maladresse ou une défaillance de l’un de nos neurones, ce qui est plus fréquent qu’on le voudrait.

Avec tous nos nouveaux profils, comment configurer l’intégration continue ? Nous voulons une couverture aussi complète que possible, mais sans réduire le temps de réaction du serveur. Une pratique courante est d’avoir une intégration continue en plusieurs passes :

Bien sûr, cela suppose de disposer de davantage de machines disponibles, mais n’oubliez pas ce que peut coûter un bogue identifié tardivement sur un projet, surtout si c’est pour constater finalement qu’il s’agit d’une étourderie, d’un « TODO » laissé négligemment dans le code, d’un copier-coller maladroit, ou d’une petite modif' sans grande importance qui en a finalement eu plus que prévu. Tout cela alors qu’on dispose de tout l’outillage nécessaire pour identifier de telles âneries. Les machines ne dorment pas, ne se plaignent pas, et surtout ne relâchent jamais leur attention lorsqu’il s’agit d’épier nos défaillances !

Notre déclaration de dépendance est-elle incorrecte ? Peut-être n’utilisons-nous pas le bon identifiant de groupe en spécifiant com.oracle, alors qu’il faudrait indiquer com.oracle.jdbc, com.oracle.driver ou encore oracle tout court ? Nous pouvons, bien sûr, nous lancer dans une recherche manuelle mais cela risque rapidement d’être pénible et pas forcément très concluant.

D’autres ont eu ce même problème et ont donc mis en place des moteurs de recherche spécialisés pour Maven, par exemple, le site mvnrepository.com qui offre une indexation du dépôt central utilisé par défaut par Maven. Nous y faisons une recherche sur le mot « oracle », et nous obtenons rapidement la confirmation attendue sur l’identité de notre pilote JDBC (voir Figure 06-01).

Recherche d’un artefact via un moteur de recherche spécialisé.

Nous voilà au moins rassurés pour l’identification de notre dépendance : nous avons spécifié les groupe, artifactId et version corrects. Mais alors, pourquoi Maven ne parvient-il pas à télécharger ce pilote JDBC ?

La réponse est relativement évidente si vous vous connectez au site Oracle : la distribution de cette bibliothèque est soumise à l’accord d’Oracle, et elle ne peut être téléchargée qu’après enregistrement sur le site de l’éditeur. L’équipe Maven qui gère le dépôt ne peut donc pas la mettre librement à disposition de chacun, tout juste peut-elle proposer un fichier POM et un groupe clairement défini pour ce pilote.

Il revient donc à chacun d’aller télécharger manuellement le fichier indiqué.

Quel intérêt y a-t-il à publier sur central le POM du pilote Oracle si la bibliothèque ne l’accompagne pas ? Un élément de réponse figure dans le paragraphe qui précède : toute personne utilisant Maven qui recherche ce pilote va au moins utiliser des identifiants de groupe, d’artefact et les versions déjà référencées. Cela assure l’homogénéité des projets. Ensuite, le fichier POM compte de nombreuses métadonnées qui peuvent informer sur la bibliothèque, en particulier :

L’intégralité de ces métadonnées n’est cependant pas toujours disponible ce qui est fort dommageable. En particulier, l’information de licence devrait être plus généralement indiquée, car elle peut fortement impacter les projets qui utilisent une dépendance.

Grâce aux informations du POM, nous sommes enfin en mesure de récupérer la bibliothèque du pilote JDBC Oracle en suivant la procédure légale de téléchargement, après avoir lu en détail la longue page d’acceptation de la licence.

La solution que propose spontanément Maven, c’est d’installer la bibliothèque manquante à la main. La commande à utiliser a été fournie dans le message du Listing 6.1. Il nous suffit de faire un copier-coller dans notre console en indiquant le fichier en question… ce qui suppose tout de même que nous l’ayons trouvé quelque part et, bien sûr, que nous soyons parfaitement certains de l’identité du fichier.

Le numéro de version à 5 chiffres utilisé par Oracle n’est pas très rassurant de ce point de vue. Il y a de toute évidence de nombreuses microversions, sans doute des correctifs successifs dont nous n’avons pas strictement besoin, mais qui sait ?

C’est une solution rapide, tout à fait légitime si nous disposons de la bibliothèque en question par un autre moyen.

Nous avons donc une solution pour le pilote Oracle ; cependant, chacun de nous doit l’installer dans son dépôt local. Même si nous nous le passons par mail, clé USB ou partage de répertoire interposé (ce qui sous-entend que nous n’avons pas très bien lu la longue page de licence du site Oracle), ce n’est pas très pratique.

D’un point de vue légal, chaque développeur doit accepter individuellement la licence Oracle pour obtenir le fameux pilote. Une façon courante de l’obtenir est donc de télécharger et d’installer l’environnement de développement Oracle (client natif et autres outils) qui comprendra entre autres le fameux pilote. Dans ce cas bien précis, nous pouvons indiquer une dépendance system sous la forme :

Le scope system utilisé ici permet de pointer vers un emplacement du poste de développement pour accéder à une ressource locale qui ne peut pas être gérée par le mécanisme de téléchargement des dépendances, pour des raisons légales la plupart du temps. Les dépendances de ce type sont accompagnées d’un élément supplémentaire systemPath (qui n’est pas valide en dehors de ce cas). Ce chemin indique l’emplacement physique de l’artefact.

Évidemment, ce cas de figure correspond à une lecture stricte du contrat de licence Oracle, et, pour des questions pratiques, vous préférerez très certainement partager entre développeurs d’une même équipe le fichier JAR téléchargé une fois pour toutes. Il est très improbable qu’Oracle vous envoie ses brigades antipirates pour violation de la licence, surtout si vous venez de l’acheter pour installer la base de données sur votre serveur bi-processeur quad-core ^[26] assortie d’un contrat de support ;-).

Nous pourrions aussi être tentés de détourner ce scope et d’intégrer le JAR dans le gestionnaire de code, ce qui permettrait à chacun d’en disposer d’une manière simple sans se poser plus de questions :

Cela nous évite de devoir échanger le fichier à la main. Cependant, stocker des binaires dans notre gestionnaire de code source est quelque peu contre-nature. Par ailleurs, si chaque projet qui utilise une base Oracle doit intégrer un répertoire lib, nous allons être témoins de la multiplication rapide des fichiers JAR sur nos postes de développement.

Le dépôt de bibliothèques ne contient pas seulement le fichier POM de notre pilote JDBC, mais aussi deux fichiers suffixés md5 et sha1 associés à l’archive JAR. Il s’agit des sommes de contrôle de l’archive – qui, elle, n’est pas disponible dans le dépôt. Ces sommes de contrôle sont l’équivalent de nos empreintes digitales. Un bit modifié dans le JAR donnera une somme de contrôle différente. C’est donc un excellent moyen pour valider un téléchargement, toujours sujet à un risque de défaillance du transfert réseau.

Ce contrôle, Maven le fait de manière systématique et totalement transparente… du moins tant que le contrôle n’échoue pas ! Dans notre cas, la bibliothèque téléchargée ne correspond pas aux sommes de contrôle mises à disposition dans le dépôt Maven.

Ce n’est cependant qu’une alerte, car dans un monde imparfait, certaines sommes de contrôle mises à disposition sont malheureusement incorrectes. Dans le doute, nous téléchargeons à nouveau le pilote JDBC Oracle. Il est vrai que la connexion ADSL n’est pas très en forme aujourd’hui, sans parler de ce satané virus qui a infecté notre réseau la semaine dernière.

Le résultat est sans appel : le second fichier téléchargé, une fois installé dans notre dépôt privé, corrige le problème. Peut-être aurions-nous constaté un problème immédiat avec ce pilote, peut-être ne serait-il apparu que très tardivement, mais dans tous les cas, remonter jusqu’à l’origine du problème aurait été bien délicat. Qui aurait l’idée de mettre en question le JAR Oracle alors qu’il y a tant de raisons pour que notre application ne fonctionne pas ?

Notre problème de dépendance sur le pilote JDBC Oracle est enfin résolu de manière satisfaisante. Mais voilà que nous obtenons à nouveau un message d’erreur comparable, concernant cette fois l’API Java Messaging Service (JMS pour les intimes).

La solution est toute trouvée, puisque le problème est équivalent à celui que nous avons rencontré avec Oracle. Un rapide coup de fil à Carlos permet de mettre à disposition le JAR manquant sur notre dépôt privé.

Cependant, il ne s’agit pas d’un produit propriétaire mais bien d’une API standard de Java, et même pas spécialement exotique ou récente. Comment est-il possible que Maven ne dispose pas de cette bibliothèque ? Il doit bien y avoir des millions de développeurs à l’utiliser chaque jour sur des projets JavaEE.

Une lecture approfondie de la documentation, et plus particulièrement de la Sun Binary Code License, répond à cette question. Comme de nombreuses API, JMS en version 1.0.2 a été diffusé par SUN sous une licence contraignante, interdisant la libre distribution de l’archive Java. Il est donc légalement interdit de mettre ce fichier à disposition d’autres utilisateurs, et en particulier central, le dépôt officiel de Maven, doit se plier au respect de cette règle.

La licence SBCL impose en fait à chaque utilisateur de cocher la petite case « J’accepte la licence d’utilisation » avant de pouvoir obtenir l’archive Java tant convoitée. Ce petit raffinement qui paraît anodin est un obstacle incontournable au téléchargement automatisé des bibliothèques.

Pourquoi Maven ne propose-t-il pas d’accepter la licence ?

Au même titre que le site de téléchargement de SUN, Maven pourrait — techniquement parlant — proposer d’accepter la licence avant d’effectuer le téléchargement. Cela serait satisfaisant sur le plan légal et éviterait ce genre d’aberration pour les utilisateurs. L’équipe du projet Maven n’a cependant pas suivi cette option.

D’une part, cela introduit une interaction avec l’utilisateur qui n’est pas compatible avec le mode de fonctionnement « batch » prévu par Maven (qui peut aussi s’exécuter sur des machines automatisées).

D’autre part, l’équipe étant très attachée aux valeurs du logiciel libre, elle a fait front pour faire évoluer l’approche de SUN pour ses licences, au point que Java 7 est aujourd’hui totalement libre ! Une belle victoire, qui nous permet de télécharger librement la bibliothèque JMS 1.1 depuis le dépôt central. SUN n’a cependant pas poussé la courtoisie jusqu’à changer la licence de ses anciennes bibliothèques, d’où notre problème avec JMS 1.0.2.

Ce second exemple montre bien à quel point la problématique des licences ne doit pas être négligée. Si, honnêtement, personne ne lit attentivement les détails de ces textes plus ou moins abscons, leur influence sur un projet peut être énorme. Le téléchargement automatique des bibliothèques par Maven est bien pratique, mais tend à nous faire oublier que nous ne vivons pas dans un monde de Bisounours où tout est gratuit et librement diffusable. Chaque bibliothèque introduit des contraintes d’utilisation, parfois les restrictions d’une licence commerciale, parfois les obligations d’une licence libre.

Notre première idée est d’établir un site miroir du dépôt central de Maven, ce qui nous permettra de faire abstraction de la connexion Internet lorsque celle-ci est défaillante, ou tout simplement d’économiser la bande passante.

L’idée est simple, facile à mettre en œuvre avec les outils courants. Nous constatons cependant très vite qu’elle a ses limites. D’une part, le miroir occupe plusieurs gigaoctets pour un grand nombre de bibliothèques obsolètes ou totalement dénuées d’intérêt pour notre développement. Ensuite, nous ne disposons toujours d’aucun outil pour maintenir de manière fiable et ergonomique le contenu de ce site. Les métadonnées Maven peuvent être complètement aberrantes, les artefacts dupliqués en de nombreux endroits, sans qu’aucun outil d’audit nous en informe. Bref, cette solution n’apporte rien de plus, il faut un outil dédié.

En marge du projet Maven, la communauté des développeurs a créé le projet « Maven Repository Manager », devenu par la suite Archiva ^[28]. Cet outil n’est pas seul dans cette catégorie et doit faire face à la concurrence de Nexus ^[29] ainsi que d’Artifactory ^[30]. Tous sont disponibles en open source, les deux derniers proposant une option de support professionnel qui peut être indispensable si l’on considère qu’une entreprise confie la productivité de ses développements à ces outils. Pour ne pas faire de jaloux, nous avons choisi de proposer une capture d’écran pour chacun (voir Figures 06-02 à 06-04).

Ces outils sont des applications web dédiées à la gestion de dépôt Maven. Ils assurent un grand nombre de fonctionnalités :

La fonctionnalité de miroir est probablement celle qui vous fera installer Archiva pour votre entreprise. En disposant d’un miroir sous votre contrôle du dépôt central, vous pourrez économiser la bande passante de votre accès Internet, ne pas dépendre de la bonne santé d’Internet et obtenir des temps de réponse impressionnants pour les demandes d’artefacts déjà placés dans le cache.

C’est en effet ce que Carlos met en place : notre dépôt privé sert désormais à la fois d’hébergement pour nos bibliothèques non publiques et de miroir pour les téléchargements depuis central. Le gestionnaire fonctionne en mandataire (proxy) : pour chaque demande d’artefact non encore placé dans le miroir, il va consulter les dépôts configurés et compléter le cache en conséquence. Ainsi, les demandes suivantes seront traitées immédiatement, sans dépendance à Internet. Ce fonctionnement est nettement moins consommateur qu’un miroir complet du dépôt central dont nous n’exploiterons qu’une infime partie des gigaoctets de bibliothèques.

En fonction des besoins des projets, Carlos va rapidement ajouter d’autres dépôts à la configuration : le dépôt java.net apparaît vite indispensable, car il contient un certain nombre d’API Java standard ; le dépôt de JBoss, qui propose les dernières versions d’Hibernate ; le dépôt SpringSource, qui offre les dernières versions MileStone du framework Spring ; et ainsi de suite…

Plutôt que de nous obliger à déclarer un <mirror> dans notre fichier settings.xml à chaque nouvel arrivant dans la configuration du gestionnaire de dépôt, Carlos met en place un dépôt virtuel, comme le montre la Figure 06-02. Désormais, sous l’appellation publique, se cachent cinq dépôts de bibliothèques, dont nous complétons au besoin le contenu via l’interface d’administration. Notre fichier settings.xml évolue alors comme suit :

Configuration d’un dépôt dans Nexus.

Les mécanismes d’audit permettent à Carlos de contrôler la bonne santé de son dépôt. Il peut même programmer des purges et obtenir des statistiques d’usage. Enfin, le mécanisme de gestion des droits des utilisateurs lui permet de déléguer certaines tâches à ses collègues. Certains d’entre nous sont ainsi autorisés à publier sur le dépôt les artefacts de nos composants communs, sans pour autant risquer de compromettre la cohérence globale.

L’énorme point fort d’un gestionnaire de dépôt sur un simple serveur HTTP est qu’il prend en charge les métadonnées Maven, fusionnant plusieurs dépôts à la volée. Du point de vue de l’utilisateur, le gestionnaire apparaît alors comme un unique dépôt. La gestion manuelle des métadonnées est complexe et source d’erreur ; son automatisation est un point fort de ces outils.

Les outils d’indexation et d’audit fournissent une synthèse des problèmes identifiés, et la programmation de tâches de fond permet de purger et de corriger automatiquement les erreurs courantes dans le dépôt sans intervention humaine. La Figure 06-03 montre par exemple le rapport d’audit sur un dépôt administré par Archiva, et les différents problèmes qu’il a su y détecter.

Rapports d’audit d’Archiva.

Le gestionnaire de dépôt permet aussi une recherche globale, fournissant une vue graphique des métadonnées, comme le montre la Figure 06-04. La recherche peut s’effectuer sur le nom de l’artefact, mais peut aussi se baser sur une classe définie par une bibliothèque ou servir à identifier un JAR en calculant son empreinte et en la comparant à l’index. Le gestionnaire expose également ses index pour une intégration dans les environnements de développement (voir le Chapitre 9). Enfin, un espace de stockage permet la diffusion des développements au reste de l’équipe, servant de dépôt « public-privé ».

Page de recherche d’Artifactory.

Plein de bonne volonté, Carlos a vite compris que la gestion d’un dépôt Maven n’est pas aussi simple qu’il y paraît. La gestion purement manuelle trouve ses limites et est bien incapable de prendre en charge la complexité liée à la quantité et à la diversité des artefacts. Un outil dédié comme Archiva est non seulement utile mais rapidement indispensable. Ses fonctionnalités annexes sont incontournables pour une gestion fiable du dépôt interne.

Notre équipe de développement est désormais sereine face à la gestion de ses dépendances. Nous passons systématiquement par notre serveur Archiva via la syntaxe <mirrorOf>* et sommes assurés de ne pas dépendre volontairement ou non d’un dépôt non configuré dans notre gestionnaire de dépôt. Nous ne sommes plus fondamentalement dépendants de l’accès à Internet et pouvons obtenir en un temps record les dépendances de nos projets. Enfin, nous pouvons au besoin publier en interne les artefacts qui nous manqueraient.

Maven utilise certes un format XML pour l’écriture du POM, format par ailleurs étrangement verbeux comparé à d’autres outils, mais il ne faut jamais perdre de vue qu’il ne s’agit pour lui que d’une représentation de son modèle interne. Les développeurs de Maven ont donc choisi non pas une logique de morcellement par inclusion, mais une logique d’héritage, très familière à tout développeur Java. Un POM peut hériter d’un autre POM et reçoit les attributs définis par son parent, sauf s’il les redéfinit lui-même.

Comme en Java, un POM ne peut avoir qu’un seul parent, déclaré par la balise… <parent> ! Ce parent est lui-même considéré comme un artefact Maven. Il est donc identifié par le triplet groupId : artifactId : version.

Notre POM parent est donc lui-même un autre projet Maven, mais celui-ci ne va pas produire de JAR, de War ou même de binaire exécutable. Il va se contenter du seul fichier POM qui permet de mutualiser notre configuration. Le packaging pom est prévu à cet effet. La construction d’un projet de ce type utilise un cycle de vie simplifié qui se limite à publier le fichier POM dans le dépôt. Le Listing 7.1 montre le POM parent sur le projet noubliepaslalistedescourses. Il nous permet de configurer en un seul endroit l’utilisation de Java 5 comme cible de compilation.

La configuration et les plugins déclarés dans le POM parent seront ainsi appliqués à tout projet qui déclare cet héritage. Voilà la réponse à notre problème de mutualisation ! Nous pouvons même aller au-delà, en spécifiant un super-parent qui définira une configuration Maven propre à notre organisation et applicable à tous ces projets. On y trouvera, par exemple, la configuration des plugins liés à nos règles qualité et des serveurs propres à nos machines de développement.

Cette pratique est même recommandée par Maven, c’est ce qu’on appelle un peu pompeusement un « corporate POM ». Les données qui y sont placées sont souvent plus descriptives que techniques, mais elles définissent au moins un endroit unique commun à tous. Il n’est pas rare qu’un POM de ce type utilise un numéro de version réduit à un seul chiffre, vu qu’il n’est pas réellement sujet à des évolutions mineures ou correctives.

Maven lui-même est un bon exemple de cette pratique : le projet est décomposé en de nombreux modules qui héritent d’un POM parent commun, qui lui-même hérite du POM parent Apache, commun à tous les projets de la fondation du même nom.

Hiérarchie des POM Apache Maven

L’héritage d’un POM parent simplifie l’existence, mais elle nécessite cependant que nous disposions dans notre dépôt Maven du POM en question. Sa mise au point se complique donc singulièrement, car nous devons l’installer à chaque modification avant de pouvoir constater ses effets sur les projets qui en héritent.

Maven a heureusement prévu le coup : en plus de l’identification par le triplet groupId : artifactId : version, triplet qui nous est maintenant familier, la balise <parent> propose un élément inhabituel, <relativePath>. Comme son nom l’indique, il fournit le chemin physique d’accès à ce POM parent à partir de la racine du projet courant. Et pour combler notre désir d’en faire le moins possible, Maven prévoit une valeur par défaut pour cet élément : « ../pom.xml ».

Autrement dit, Maven va rechercher avant toute chose le POM parent dans le répertoire père de notre projet — sous réserve que les indications de groupe, d’artefact et de version concordent. Cette recherche hiérarchique est un mécanisme puissant qui va profondément orienter votre façon de travailler. Chaque projet pourra ainsi se décomposer en sous-modules sous forme de sous-répertoires. Chaque groupe pourra organiser facilement son information en rassemblant tous ses projets sous une arborescence commune, dont la racine hébergera un majestueux corporate POM.

Un élément du fichier POM que nous n’avons pas encore utilisé répond à ce besoin, il s’agit du <dependencyManagement>. Cette balise n’est utile que dans le cadre d’un POM parent, ce qui explique que nous ne l’ayons encore jamais rencontrée. Comme la balise <dependencies>, elle se compose d’une suite de dépendances mais, contrairement à elle, il ne s’agit ici que de définir les versions par défaut de ces dépendances. Notre fichier POM parent va ainsi lister quelle version de chaque bibliothèque fait office de référence sur le projet. Dans chaque sous-projet, nous pourrons alors déclarer nos dépendances sans indication de version, auquel cas celle indiquée par le dependencyManagement sera utilisée.

Autre avantage de cette pratique, si une bibliothèque est introduite par la gestion transitive des dépendances, et même si nous ne l’utilisons pas explicitement dans nos projets, nous pouvons tout de même imposer l’utilisation d’une version précise via le dependencyManagement.

La gestion centralisée des versions est une pratique simple qui assure la cohérence des projets décomposés en modules. Elle n’empêche pas au besoin un module de déclarer explicitement une version autre que celle recommandée par le POM parent, pour bénéficier d’une fonction particulière.

De la même façon, si les règles de l’entreprise l’imposent, un corporate POM peut définir les versions validées et supportées des bibliothèques, que chaque projet pourra alors utiliser en toute confiance.

Hériter d’un corporate POM juste pour partager la déclaration d’un <dependencyManagement> est cependant une contrainte un peu lourde, étant donné qu’on ne peut hériter que d’un seul POM parent. Maven, depuis sa version 2.0.9, propose une autre option via import, un scope particulier. Une dépendance marquée de ce scope ne sera pas ajoutée au classpath du projet. Par contre, sa déclaration <dependencyManagement> sera « importée » dans le projet comme si elle y avait été copiée-collée. Cette option permet ainsi de construire des POM communs définissant des versions des bibliothèques courantes dont vous avez validé la bonne intégration. Avec la multiplication des frameworks, un POM indiquant les versions compatibles entre Spring, Hibernate, Wicket, Hibernate-validator, AspectJ et EH-Cache ne sera pas un luxe pour lancer rapidement un projet sans avoir ce problème à gérer !

Au même titre que pour nos dépendances, les versions de nos plugins Maven ne doivent pas être négligées. Même en supposant qu’aucune régression ne soit constatée entre deux versions d’un même plugin, l’utilisation de versions incohérentes est source de bizarreries, voire de bogues très délicats à identifier.

Le POM parent peut, là aussi, nous aider via son élément <pluginManagement>. Comme pour la gestion des dépendances, il nous permet de centraliser les versions des plugins utilisés par chaque module du projet.

Le format du fichier POM n’impose pas de déclarer pour chaque plugin utilisé un numéro de version. Il est cependant fortement recommandé de fixer cette version car sans cela, Maven considère que vous désirez utiliser la dernière version stable du plugin. Si les développeurs font très attention à la compatibilité ascendante, ils ne sont pas à l’abri d’une régression et peuvent au fil de versions successives déprécier puis supprimer certaines fonctionnalités ou certains paramètres. Si vous intervenez sur un projet ancien après qu’un plugin a subi de telles évolutions, Maven utilisera la dernière version et votre projet ne pourra pas être construit à l’identique, voire ne pourra plus être construit du tout !

Indiquer systématiquement la version des plugins comme si l’élément <version> était obligatoire est contraignant et source d’hétérogénéité dans un projet multimodule. Le pluginManagement va permettre de centraliser au niveau du projet parent les versions de tous les plugins utilisés.

Fort de ces nouveaux concepts, Raphaël reprend les POM du projet pour centraliser notre gestion de version. <dependencyManagement> et <pluginManagement> sont renseignés après une revue complète de tous nos fichiers POM. La tâche est complexe et source d’erreurs tant les risques d’oubli sont nombreux. Raphaël cherche donc un moyen pour s’assurer qu’il n’a omis aucune déclaration de version pour un plugin. Par ailleurs, il voudrait être sûr qu’à l’avenir un plugin ajouté dans un module ne risquera pas de passer entre les mailles du filet. Si aucun de nos POM ne déclare de version pour les plugins, nous savons que par mimétisme les nouveaux plugins seront déclarés de la même manière.

Raphaël trouve la solution à ce problème dans le plugin Enforcer. Celui-ci ne contribue pas à la construction du projet, mais fait partie d’une catégorie un peu particulière de plugins qui visent à outiller l’utilisation de Maven. Enforcer va analyser notre modèle de projet pour vérifier certaines règles. L’une des règles prédéfinies exige justement de vérifier que chaque plugin du projet a une version correctement définie.

Enforcer ne fait pas une analyse de notre fichier POM en tant que document XML, ce qui serait peu utile puisque la version du plugin peut être définie dans un parent ou dans un bloc <pluginManagement>. Il utilise le modèle objet du projet qui est le résultat de l’analyse de notre POM et de ceux dont il hérite. Si une version est définie quelque part, il saura donc la détecter et, à l’inverse, il saura détecter son absence !

Enforcer propose de nombreuses autres règles d’usage de Maven permettant de s’assurer que le projet est utilisé selon les bons usages ou les contraintes spécifiques définies par le projet. Il peut ainsi vérifier que le développeur utilise une version précise de Maven ou du JDK, mais aussi que certains fichiers existent (ou n’existent pas), qu’aucun SNAPSHOT n’est utilisé en dépendance, ou encore interdire l’utilisation de certaines dépendances (par exemple, pour éviter des problèmes de licence).

Les mécanismes de modules et d’héritage ne sont pas nécessairement liés l’un à l’autre, cependant ils se complètent de manière naturelle. Il est très fréquent que le POM parent soit celui qui déclare un projet comme module. En fait, les cas où une autre organisation est nécessaire sont assez rares et répondent à des contraintes d’organisation très particulières. La structure hiérarchique des projets est donc une structure très courante pour les projets Maven, généralement reflétée par l’organisation physique des répertoires.

Comment va se comporter notre serveur d’intégration continue face à ce nouveau découpage en modules ? Les outils que nous avons retenus supportent parfaitement cette approche de Maven. Ils vont donc identifier chaque module comme un projet à ajouter dans la configuration de l’intégration continue.

Continuum a néanmoins ici un coup d’avance sur la concurrence : en détectant une modification dans le code du projet, il va lancer la construction du module concerné, puis exploiter la gestion des dépendances entre projets pour lancer la construction de tous les autres modules qui en dépendent et pourraient donc être impactés, mais pas de ceux qui n’ont aucun lien direct ou indirect avec la modification. Mais Hudson le talonne de près et commence à supporter lui aussi une gestion plus intelligente de Maven… à suivre !

L’avantage de ce fonctionnement, détaillé dans la figure 07-02, est que la construction d’un module (ou de plusieurs) est plus rapide que celle du projet dans son ensemble. Le serveur sera ainsi plus réactif : une modification erronée sur un module sera identifiée rapidement, son impact sur un autre module apparaîtra en quelques instants, alors qu’une construction complète aurait pu prendre de longues minutes, impliquant de nombreux modules non concernés par la modification.

Réaction du serveur d’intégration continue à une modification.

Certains utilisateurs n’apprécient pas le découpage en nombreux modules qu’encourage Maven. Ils ont l’impression que leur projet s’effrite en petits bouts de code sans grande valeur et délicats à identifier pour les utilisateurs finaux.

Cette impression découle d’une habitude prise avant l’apparition de Maven, qui consiste à proposer un gros JAR avec tout ce qui est nécessaire à l’intérieur pour que les utilisateurs n’aient pas à se soucier des dépendances. Paradoxalement, cette pratique est plus périlleuse qu’elle n’y paraît et introduit des incompatibilités sans solution lorsqu’on veut marier deux outils construits avec cette optique.

Les utilisateurs de Maven n’ont plus à se préoccuper des problèmes de dépendances, et chaque module peut préciser finement ce qui lui est nécessaire. Au contraire, un artefact unique devra :

Dans les deux cas, les utilisateurs de Maven sont pénalisés, et ceux qui ne l’utilisent pas ne sont pas beaucoup plus avancés dans leur gestion manuelle des dépendances.

Le découpage en modules permet aussi de renforcer nos règles d’architecture logicielle. Si notre structuration JavaEE impose par exemple que « seule la couche métier est autorisée à manipuler les objets de la couche d’accès à la base », la déclaration des dépendances permet d’interdire à tout autre module de l’utiliser : en l’absence de dépendance sur le module persistance, aucun risque de le voir utilisé par mégarde ! Fini la mauvaise surprise de découvrir un tag JSP qui effectue sa propre requête en base pour construire une liste de sélection.

Stéphane aboutit à une structure de projet claire et bien organisée, où chaque composant trouve sa place dans un module : un module pour notre code métier, un module pour notre couche d’accès à la base de données, un module pour notre IHM web, un module pour nos services web REST, un autre pour nos batchs de sauvegarde…

Dans un premier temps, nous trouvons cela d’une grande élégance, surtout parce que cela nous permet de ne travailler que dans un module et donc d’alléger d’autant notre « vue » de l’application. Par contre, pour compiler tout ça il nous faut toujours lancer un gros mvn install, même si un seul module isolé est modifié, ou bien lancer la commande dans le répertoire de chaque module impacté en respectant l’ordre de construction. C’est tout de même dommage d’avoir un outil qui gère l’ordre des modules et de devoir gérer ce problème à la main !

Pas de panique nous rassure Emmanuel : même si le fonctionnement par défaut consiste à enchaîner tous les modules du projet, Maven propose des options avancées pour filtrer quels modules intégrer au build et quels modules ignorer.

Nous pouvons ainsi réduire le nombre de modules construits par un mvn install aux modules impactés par une modification. Bien, mais nous sommes exigeants et en voulons encore plus !

Stéphane a gardé une carte dans sa manche. Face à un build qui enchaîne encore plusieurs modules, il nous propose d’ajouter une dernière option, -T 4. Il ne s’agit pas de demander de l’aide à Skynet en invoquant Terminator IV, mais de lancer Maven en parallélisant la construction des modules sur les 4 processeurs de nos machines de développement — car depuis la création de notre start-up, nous avons tous reçu un magnifique MacBook Pro core i7. Maven peut alors traiter en parallèle certains de nos modules et nous économiser un temps précieux. La seule limite est la dépendance de nos modules entre eux, que Maven doit tout de même respecter.

Bien, mais nous sommes exigeants et en voulons encore plus ! Stéphane, en fin stratège, a gardé sa toute dernière réplique pour la fin, et nous invite à refaire le monde autour d’une bière. Voilà qui met tout le monde d’accord !

La première étape consiste à créer l’archive WAR de notre application web, en incluant son descripteur de déploiement. En tant que fichier binaire, un WAR n’est rien d’autre qu’une archive JAR avec une extension spécifique, donc rien de bien compliqué. Nous devons cependant suivre la structure définie par la norme JavaEE, en particulier le répertoire WEB-INF qui doit contenir :

Sur un projet utilisant un répertoire lib fourre-tout pour placer ses bibliothèques, le troisième point serait traité avant même qu’on ne se pose la question, mais sur notre projet Maven ?

Vincent s’attaque à la construction automatisée de notre WAR. Il trouve rapidement un allié de choix dans le plugin war de Maven. Celui-ci a été conçu pour répondre de la manière la plus souple et la plus transparente qui soit à ces contraintes d’assemblage. Ce plugin va bâtir dans le répertoire de construction (target) la structure ouverte de l’archive WAR à partir des éléments de notre projet et de nos déclarations dans le POM. Il va donc y recopier tous les éléments statiques de notre application web (pages html, images, scripts…), ainsi que nos classes compilées par le plugin compiler, notre descripteur de déploiement et nos bibliothèques — du tout cuit !

Cerise sur le gâteau, Vincent n’a même pas besoin de déclarer explicitement ce plugin comme nous l’avons fait jusqu’ici : puisque notre projet ne produit pas un JAR, il remplace la déclaration de <packaging> pour indiquer la construction d’une archive WAR. Ce packaging, supporté par défaut par Maven, provoque automatiquement une sélection différente des plugins associés par défaut aux phases du projet, et en particulier l’activation du plugin war lors de l’assemblage.

Vincent aurait-il tiré le gros lot en prenant en charge cette tâche ? Une ligne de configuration à éditer en tout et pour tout, c’est plutôt reposant ! Eh bien non ! Au lancement de notre application sur le serveur de test Tomcat, nous avons droit à une erreur qui pourrait faire sourire si nous étions un 1^er avril, mais qui nous laisse perplexes :

Nous devons explorer un peu plus la logique de JavaEE pour comprendre. Un serveur JavaEE isole chacun des composants qu’on y déploie afin qu’ils ne se perturbent pas mutuellement. Cette isolation se fait via des chargeurs de classes dédiés. Notre application web aura donc son propre chargeur de classes, incluant les bibliothèques de notre WEB-INF/lib et nos classes de WEB-INF/classes. Celui-ci hérite d’un chargeur père qui contient les classes du serveur d’application permettant la mise en œuvre de l’API servlet. Le serveur sera donc en mesure de manipuler nos servlets parce que nous partageons avec lui les classes de cette API. La Figure 08-02 compare cependant ce modèle théorique et ce que nous observons.

Comparaison de la structure des chargeurs de classes : théorie vs pratique.

Lorsque le serveur d’application tente d’initialiser un de nos servlets, il manipule tout naturellement le type javax.servlet.Servlet, à partir des classes présentes dans son chargeur de classes. Notre servlet LoginServlet a cependant été instancié dans le chargeur de classes de l’application web ; aussi, pour que tout fonctionne bien, il faut que le type javax.servlet.Servlet, lorsqu’il est manipulé depuis l’application web, soit le même que depuis le code du serveur d’application.

En jetant un coup d’œil à notre WEB-INF/lib, nous y découvrons le coupable : servlet-api-2.5.jar. Un servlet créé dans notre application web aura comme type parent une classe qui est chargée elle aussi par l’application web, et pas le javax.servlet.Servlet commun à tout le serveur d’application. D’où cet étrange message d’erreur. Vincent est rassuré sur sa santé mentale.

Cette dépendance javax.servlet:servlet-api:2.5 est pourtant indispensable à notre application pour qu’elle soit en mesure de compiler. Nous faisons de nombreuses références directes à ces classes dans notre code ! Nous avons déjà exploré les scopes que nous pouvons affecter à nos dépendances. Le scope par défaut (compile) signifie que la bibliothèque associée est nécessaire pour compiler et s’exécuter, c’est donc a priori bien le cas. Il existe cependant un autre scope, provided, qui est très proche avec une nuance significative : il déclare une dépendance nécessaire pour compiler et s’exécuter mais qui est fournie par l’environnement d’exécution, typiquement notre serveur JavaEE.

La modification suivante sur nos dépendances corrige donc ce problème assez déboussolant et nous permet enfin de lancer l’application web sur notre serveur Tomcat.

Notre exploration du monde JavaEE se poursuit avec un Entreprise Java Bean, c’est-à-dire un macrocomposant métier qui sera potentiellement distribuable sur l’ensemble de notre cluster.

Nous avons donc isolé notre code métier dans un module (voir le Chapitre 7) dédié, chargé de construire un composant réutilisable. Fort de son précédent succès, Vincent se porte volontaire pour explorer la « mavenisation » de cet aspect de notre application.

La même recette donne le même résultat, ce qui finit par nous faire penser que Vincent a décidément le nez fin : <packaging>ejb</packaging> dans le POM suffit pour changer la configuration par défaut du cycle de vie et produire un EJB. La seule chose que nous devrons y ajouter est la configuration de la version de l’API EJB que nous voulons utiliser, à savoir EJB3 ce qui n’est pas la valeur par défaut (2.1).

Cette formalité passée, nous obtenons l’EJB tant attendu, dont nous pouvons tester le déploiement sur un serveur de test OpenEJB.

Il nous reste à faire le lien avec notre application web. Celle-ci doit disposer des classes client de l’EJB, c’est-à-dire de la partie de l’EJB qui définit son utilisation (interfaces, objets paramètres). Cela ne va pas nous coûter beaucoup d’efforts puisque le plugin ejb a la bonne idée de créer une archive avec ces classes pour nous, en ajoutant simplement à sa configuration <generateClient>true</generateClient>. Nous obtenons donc finalament deux archives Java :

Dans notre application web, il nous suffit donc de déclarer une nouvelle dépendance vers ce client pour pouvoir utiliser notre EJB :

Reste à faire le lien entre les deux composants, via les descripteurs de déploiement. L’objet de ce livre n’est pas de vous faire un exposé complet sur JavaEE ; pourtant, nous ne pouvons pas honnêtement vous laisser sans réponse si près du but… Les Listings 8.1 et 8.2 montrent les deux descripteurs de déploiement de notre application, le premier permettant à l’EJB de s’identifier et de demander une ressource de type base de données, le second permettant à l’application Web d’obtenir une référence vers notre EJB, potentiellement installé sur un autre serveur, voire distribué sur un cluster.

Il ne nous reste plus qu’à prendre nos composants et à les grouper dans un joli paquet-cadeau avant de l’envoyer à notre hébergeur. En terme JavaEE, le paquet-cadeau est une archive d’entreprise EAR.

Pour produire ce nouvel artefact, Vincent applique la recette qui lui a jusqu’ici réussi et fait mouche une nouvelle fois : un nouveau module, avec comme packaging ear suffit pour produire un artefact EAR. Si tout pouvait être aussi simple… enfin, passons.

La seule chose à déclarer dans le POM de ce nouveau module est la liste de dépendances, pointant vers nos composants JavaEE, à inclure dans l’EAR – dans notre cas, l’application web et l’EJB, mais potentiellement plusieurs composants de ce type et/ou des connecteurs RAR ou autres subtilités JavaEE propriétaires ou non.

Le plugin ear compte de nombreuses options qui permettent d’ajuster finement le nom de chaque composant à l’intérieur de l’archive EAR. Il propose même de générer pour nous le descripteur de déploiement application.xml, ce qui nous fera toujours un fichier de moins à maintenir.

Nous avons un bel EAR prêt pour une mise en production, cependant un détail chagrine Vincent : notre application web, comme notre EJB, utilise plusieurs bibliothèques utilitaires, telles que commons-lang ou commons-io. Dans sa structure actuelle, nous retrouvons ces fichiers en double, une fois dans le WEB-INF/lib de l’application web, une fois dans le fichier EJB. Ce n’est pas intellectuellement très satisfaisant.

Le modèle JavaEE a prévu le découpage des composants en modules mais n’a pas non plus négligé la mutualisation des bibliothèques. Le métafichier MANIFEST permet de déclarer des bibliothèques nécessaires à l’exécution d’un module JavaEE, bibliothèques qui seront alors mises à disposition via l’EAR.

Maven n’a pas non plus négligé cet aspect du packaging JavaEE, et nous devons revenir dans notre projet application web pour marquer les dépendances que nous voulons à présent exclure de WEB-INF/lib pour les mutualiser.

À la première étape, on demande au plugin war de construire, dans les métadonnées de l’archive, l’indication de classpath :

Pour chaque dépendance que nous voulons voir apparaître dans ce chemin de classes commun, et donc exclure de notre WEB-INF/lib, il suffit d’indiquer le statut optionnel de la dépendance : <optional>true</optional>. La déclaration peut sembler un peu contre-nature, puisque dans la majorité des cas la dépendance en question n’est pas du tout optionnelle. Il s’agit, avouons-le, d’un détournement de la notion de dépendance optionnelle, qui, de toute façon, n’a pas vraiment de sens pour un projet WAR.

Dans notre projet EJB, nous appliquons au plugin ejb la même déclaration <archive> que pour le plugin war. L’EJB produit aura alors dans son MANIFEST une déclaration de classpath à la place de l’inclusion de ses dépendances. Il ne nous reste plus qu’à déclarer ces dépendances dans notre projet EAR pour que celui-ci les intègre dans l’archive EAR et qu’elles soient ainsi partagées entre nos deux composants JavaEE.

Pour éviter un travail fastidieux de cohérence entre les trois modules, nous remontons dans le projet parent ces déclarations de dépendances, qui deviennent alors elles-mêmes mutualisées. Comme déclaration de dépendances, notre projet application web ne contient alors que les bibliothèques spécifiquement web qu’il emploie. La Figure 08-03 indique la structure finale de notre projet Maven.

Multiprojet JavaEE avec mise en commun des dépendances via l’EAR.

Selenium ^[32] est un outil qui n’est pas limité au monde Java mais s’y intègre très bien. Il s’agit d’un système complet d’enregistrement et de pilotage du navigateur web à des fins de test — rien que ça.

Il se compose de deux parties :

Le grand intérêt de cette approche par rapport à de nombreux autres outils de test est que l’on peut tester une application web dans un véritable navigateur, avec ses particularités, ses bogues, sa façon bien à lui d’interpréter les balises HTML et le code JavaScript.

L’enregistreur peut sauvegarder le scénario de test selon de nombreux formats, dont deux vont particulièrement nous intéresser. Le premier est une simple table HTML, listant les actions réalisées sur le navigateur (cliquer, attendre la page suivante…). Le second utilise notre bon vieux langage Java et le framework de test jUnit. Cette seconde option nous permet d’éditer le scénario pour y ajouter les contrôles qui nous plaisent en utilisant notre langage de programmation habituel. Nous n’avons donc pas à apprendre les secrets d’un nouveau langage !

Le Listing 8.3 montre le code d’un test Selenium utilisant la syntaxe Java. Du point de vue du programmeur, l’API de Selenium offre une vision de très haut niveau du navigateur sous contrôle, ce qui rend la programmation très rapide et agréable.

Si la syntaxe du test est celle de jUnit, l’exécution d’un test Selenium nécessite un peu plus que le simple framework de test. Selenium repose sur un composant contrôleur, chargé de lancer le navigateur de la machine hôte et d’en piloter le comportement. Nous devons donc intégrer le démarrage de ce contrôleur dans notre processus de construction Maven si nous voulons en exploiter la puissance :

Le plugin selenium vient à notre secours : il propose deux tâches complémentaires, chargées de faire démarrer et d’arrêter proprement le contrôleur Selenium, respectivement au cours des phases pre-integration-test et post-integration-test. Ce qui nous laisse donc la phase integration-test pour exécuter nos tests, comme ça tombe bien !

Nous l’avons vu, Selenium peut stocker les scénarios sous forme de fichiers HTML. Le plugin selenium propose une tâche dédiée à ce format qui permet de les exécuter au cours du build Maven. Il est donc facile d’outiller une application de tests de non-régression : il suffit d’enregistrer des scénarios au format HTML et d’ajouter la configuration du Listing 8.4 ; les tests seront alors rejoués à l’identique à chaque construction complète du projet.

La seconde option, fondée sur l’enregistrement et l’enrichissement éventuel de nos scénarii de test au format jUnit, va utiliser le plugin standard surefire pour l’exécution des tests. Il sera simplement configuré de manière spécifique pour s’exécuter lors de la phase integration-test.

Magique ! Vincent s’empresse d’ajouter à notre projet le plugin surefire – qui prend en charge l’exécution de tests jUnit – et de l’associer à cette phase de test d’intégration. Sitôt dit, sitôt fait, mais là gros problème : nos tests sont exécutés avant que le contrôleur Selenium ne démarre. Nous l’avions oublié, mais Surefire est déjà configuré pour s’exécuter au cours de la construction de notre projet, car c’est lui qui est chargé de l’exécution de nos tests unitaires, et il ne sait pas différencier sans notre aide les tests Selenium des tests plus classiques.

Une première solution est d’utiliser des règles de nommage pour différencier facilement les deux catégories de tests. Nous n’avons alors qu’à configurer Surefire avec des patrons complémentaires d’inclusion/exclusion pour que chaque test se déroule dans la phase adéquate. Le Listing 8.5 montre la configuration dans le fichier POM qui met en œuvre cette stratégie. Les tests Selenium sont suffixés Selenium au lieu de Test pour les différencier.

Une autre solution consiste à créer un second projet, destiné aux tests d’intégration, dans lequel nous les placerons, ce qui évite toute ambiguïté. La configuration est alors plus simple, et nous disposons d’un emplacement dédié pour la définition de nos tests d’intégration.

Les deux approches sont valides et couramment appliquées selon les goûts de chacun. La première utilise de manière assez logique les phases *integrations-test de Maven, la seconde isole cette catégorie de tests un peu hors normes dans un projet dédié qui concerne une catégorie différente de développeurs.

Nous savons donc lancer un navigateur et lui faire suivre un scénario prédéfini. Reste à le faire pointer vers notre application. Mais au fait, où est-elle notre application ? Nous avons bien une archive WAR, mais sans serveur où la déployer, elle n’affichera jamais de page HTML !

Cargo ^[33] est un autre outil majeur pour notre boîte à outils de test. Son objectif est de prendre en charge l’installation d’un serveur JavaEE, sa configuration, son démarrage et le déploiement de composants JavaEE, le tout pour tous les serveurs existants (à l’exception notable de Websphere, récalcitrant à toutes les tentatives) et via une API simple et homogène — vaste programme !

Dans notre cas, nous allons utiliser Cargo pour exécuter notre application sur un serveur JBoss. L’automatisation qu’offre cet outil par le biais de son plugin Maven est telle qu’il propose de télécharger pour nous le ZIP de ce serveur, de l’installer dans un répertoire temporaire et d’en configurer une instance à la demande lors de la construction de notre projet. Tout ça en une seule ligne de commande, c’est tout de même pas mal. Bien sûr, la configuration est un peu moins facile que pour un plugin plus « simple » (voir Listing 8.6). Cet extrait de notre POM définit les paramètres d’utilisation de Cargo :

Après avoir ingurgité la hiérarchie un peu lourde de cette configuration XML, Vincent lance la commande magique mvn install et constate avec plaisir le téléchargement puis le démarrage d’un serveur JBoss sur son environnement, et le déploiement de notre application, prête pour les tests Selenium qui ont enfin du grain à moudre.

Nous nous serions bien contentés de cette solution, mais Vincent est un perfectionniste. Tout ce XML, toute cette mécanique, pour tester un bout de code JavaEE ça lui semble démesuré. Cargo fait très bien son boulot, mais n’est qu’un outil de déploiement. Il faut lui greffer une bonne dose de complexité pour en faire un outil de pilotage de nos tests d’intégration.

Notre projet EJB est un élément assez délicat à tester confortablement. Le cycle de vie de l’EJB doit être respecté pour que son code fonctionne et il repose sur la fourniture par l’environnement de ressources gérées par le serveur. Nous avons découpé notre code pour pouvoir tester unitairement les aspects essentiels, mais nous voudrions pouvoir l’exécuter en mode EJB réel, au moins pour quelques tests d’intégration.

Une fois de plus, la force d’une norme comme JavaEE va apporter des solutions. Comme nous ne développons pas du code dépendant d’un serveur particulier, nous pouvons le changer d’environnement pour le tester. La portabilité est garantie par la certification JavaEE qui valide le respect de la norme par chaque serveur JavaEE candidat.

OpenEJB nous propose de déployer notre EJB dans un environnement particulièrement léger, à tel point qu’on peut facilement l’intégrer dans un test unitaire. La seule chose que nous ayons à faire, c’est de lancer l’annuaire JNDI d’OpenEJB, qui se chargera automatiquement dans la foulée. Le Listing 8.7 montre, par exemple, le code excessivement complexe J qui permet de lancer notre EJB au sein d’un test unitaire.

Plus d’excuses pour ne pas développer une couverture de test de qualité autour de nos composants métier !

Ce dernier exemple montre qu’il ne faut pas tout attendre des plugins Maven, et que de nombreux outils fournissent des moyens de tester notre code dans des conditions confortables directement depuis nos tests jUnit. Le déploiement sur un serveur, même piloté par Cargo, reste une opération lourde que nous réservons aux tests fonctionnels ou aux tests de charge.

Premier constat, pour tester notre modification de JSP, notre serveur Tomcat va décompresser notre archive WAR, retrouvant ainsi exactement la structure que le plugin war a construite dans notre répertoire de construction (target). Le mécanisme de configuration de Tomcat permet de pointer directement sur ce répertoire, plutôt que de passer par une archive WAR.

Nous pouvons même faire mieux : pourquoi recopier notre JSP à chaque modification dans le répertoire de construction alors que la structure de l’application web existe quasiment sous src/main/webapp ? La seule chose qui manque pour avoir une application web conforme JavaEE, ce sont les répertoires WEB-INF/classes et WEB-INF/lib. Sous réserve d’une configuration correcte de notre gestionnaire de code source pour ignorer ces deux répertoires, il n’est pas compliqué de construire ces deux répertoires manquants – et c’est d’ailleurs ce que propose le plugin war avec sa tâche inplace.

mvn war:inplace va préparer l’application web, prête à être exécutée sur un serveur d’application qui supporte ce mode de fonctionnement. Une modification dans une page JSP sera alors appliquée immédiatement, via le mécanisme de recompilation des JSP qui est intégré à tout serveur JavaEE.

Nous faisons de nets progrès, mais nous devons encore invoquer une commande Maven à chaque édition d’une classe de l’application ou relancer le serveur lorsqu’un fichier de configuration est modifié.

Le conteneur de servlets (comme Tomcat, ce n’est pas un serveur JavaEE complet) Jetty propose un mode de fonctionnement particulièrement adapté à notre utilisation. Grâce à un plugin dédié, il se lance sur un projet Maven sans nécessiter la moindre phase de préparation. Il référence directement les bibliothèques de notre dépôt local, pointe sur notre répertoire de compilation (target/classes) et démarre l’application web en un temps record avec la seule commande mvn jetty:run.

Jetty va encore plus loin car il peut fonctionner en mode scrutation : il va surveiller le répertoire de compilation et identifier une modification sur une classe ou sur un fichier de configuration. Il lancera alors un rechargement immédiat de l’application. La réactivité de l’environnement de développement est alors excellente : lancement de l’application en un minimum de temps et sans aucune préparation, prise en compte rapide des modifications.

Pour ceux qui n’apprécient pas la ligne de commande, les IDE ont planché, de leur côté, sur le manque de productivité lié au modèle JavaEE. Eclipse Web Tools Platform se propose par exemple de redéployer automatiquement l’application lors d’une modification, ce qui permet de contrôler l’impact d’une modification sans intervention manuelle. Il suffit de configurer le serveur cible pour qu’Eclipse prenne en charge la procédure de redéploiement.

L’équipe de développement de m2eclipse a eu pitié des développeurs et leur évite de devoir configurer chaque projet pour adapter la configuration WTP à leur projet Maven. Via une extension optionnelle, m2eclipse déclarera automatiquement les modules war comme projets WTP avec les chemins et les dépendances extraites de la configuration du plugin war. Elle est pas belle la vie ?

Histoire de ne pas faire comme tout le monde, Nicolas n’utilise pas WTP sous Eclipse mais un petit plugin Made in France : Sysdeo Tomcat, distribué par le site de veille technologique www.eclipsetotale.com. Ce plugin tout simple permet de lancer un serveur Tomcat, qui a l’avantage d’être léger et rapide à démarrer et largement suffisant tant qu’on n’exploite que les technologies de l’API servlet, ce qui est le cas d’une grande majorité des applications web.

Ce plugin pour Eclipse a son pendant pour Maven ^[34], lequel va configurer le plugin Eclipse en fonction du projet Maven et des multiples modules impliqués. Ce plugin Eclipse a la particularité d’exploiter la souplesse de Tomcat pour pointer sur les répertoires de compilation de chaque module présent dans l’IDE plutôt que sur l’archive JAR qu’il produit. Une modification dans un module est donc exploitable sans manipulation particulière de l’IDE qui se contente de recompiler, après que vous avez simplement cliqué sur le bouton relancer Tomcat.

Cette combinaison apporte un support limité de JavaEE, mais permet de bénéficier d’un environnement léger et raisonnablement réactif. Elle montre surtout que WTP a raté sa cible en apportant certes le support JavaEE sous Eclipse, mais en choisissant la voix la moins productive.

Comme tout composant d’Eclipse, le support de Maven passe par l’installation de plugins. Le mécanisme de sites d’installation et de mise à jour permet d’effectuer l’opération en quelques clics à partir d’une connexion à Internet. Un redémarrage est préférable pour terminer l’installation.

L’import d’un projet Maven commence par un simple clic droit, qui lance un assistant. L’utilisateur indique le chemin du projet, et le plugin analyse le fichier POM, identifie correctement les répertoires de code source, ainsi que ceux associés à des générateurs de code qu’il exécute automatiquement. Il est également capable de configurer l’environnement de programmation orientée aspect AspectJ, si celui-ci est installé, ou d’établir un lien avec les gestionnaires de code source CVS et Subversion si le plugin adéquat est installé sous Eclipse.

Après import, l’ensemble des dépendances Maven apparaît dans un conteneur dédié, au côté de l’environnement d’exécution Java. L’IDE ne différencie cependant pas les dépendances de scope test. D’un simple clic, on peut demander au plugin de télécharger les archives de sources des dépendances, ce qui permet le cas échéant de poser des points d’arrêt avec le débogueur dans les classes manipulées.

L’import peut également s’effectuer directement depuis le gestionnaire de code source dont on saisit l’URL. Cette possibilité est utilisée dans une fonctionnalité annexe qui consiste à matérialiser une dépendance sous forme d’un nouveau projet dans l’environnement, à condition bien sûr que la dépendance en question déclare dans son POM le chemin correct de son gestionnaire de code source.

Dans tous les cas, les dépendances dont le projet est présent dans l’espace de travail d’Eclipse sont référencées comme projet, et non via l’archive JAR, permettant de tester rapidement l’impact d’une modification.

Une nouvelle entrée dans le menu contextuel nous permet d’exécuter les tâches liées à Maven. Nos projets Maven sont reconnus et décorés d’une petite icône « M » ; quant à notre POM, il a droit à une icône dédiée qui permet de facilement le différencier des autres fichiers du projet (voir Figure 09-01).

Un projet Maven vu sous Eclipse au travers de m2eclipse.

L’utilisation courante de Maven est totalement enrobée dans des assistants et la ligne de commande n’est plus du tout nécessaire. Maven est automatiquement invoqué lors des rafraîchissements de l’environnement de travail, permettant ainsi d’exécuter les tâches associées aux plugins en complément de la compilation Java par l’IDE. Les deux environnements se complètent donc, Eclipse ne conservant à sa charge que la compilation des sources Java.

Un éditeur graphique est proposé pour le POM. Il permet de saisir les métadonnées sans avoir à se soucier de la structure XML sous-jacente. La gestion des dépendances propose une assistance à la saisie des identifiants de groupe, d’artefact et de version, basée sur un index du dépôt de bibliothèque mis à jour périodiquement en tâche de fond. Un onglet dédié permet de consulter les dépendances du projet et d’identifier le jeu de transitivité à travers lequel elles apparaissent dans le projet (voir Figure 09-02).

Gestion des dépendances.

Une vue permet d’obtenir un graphe des dépendances. Esthétique, ce n’est au mieux qu’un gadget pour impressionner ses collègues et justifier son statut d’expert Maven.

La vue XML bénéficie également d’enrichissements par rapport à l’éditeur XML de base. Elle permet de saisir rapidement les structures répétitives du POM via un patron type, comme les <dependency> ou les <execution>, ou d’inclure la configuration de quelques plugins récurrents, comme pour les plugins war ou aspectj. L’utilisateur peut d’ailleurs définir ses propres patrons pour les plugins ou structures XML qu’il utilise régulièrement. Comme dans l’éditeur graphique, l’éditeur XML propose une assistance à la saisie pour les identifiants de groupe, d’artefact et les versions.

La configuration des plugins, qui se fait exclusivement dans la vue XML, est, elle aussi, assistée : m2eclipse identifie les paramètres des plugins et les propose par complétion automatique, ce qui évite de devoir consulter la documentation et de faire une malheureuse faute de frappe dans leur nom. La figure 09-03 montre m2eclipse en action proposant cette assistance.

Édition de la configuration des plugins.

Lors de l’import du projet, m2eclipse lit la configuration de quelques plugins clés pour adapter le paramétrage du projet en conséquence. Le plugin compiler permet ainsi de définir l’environnement d’exécution Java associé au projet. Ce support peut même être étendu par des plugins complémentaires qui exploitent les API de m2eclipse. C’est par exemple le cas pour le plugin Eclipse-cs qui exploite la configuration du plugin checkstyle de Maven pour aligner les deux environnements.

Lors de la construction du projet dans l’environnement de développement, m2eclipse exécute les plugins Maven associés aux premières phases du cycle de vie, en particulier les générateurs de code et de ressources. Cela lui permet d’identifier les répertoires de code généré, mais a pour effet de bord d’être assez fortement consommateur en ressources : à chaque modification ou sauvegarde d’un fichier de ressource ou d’une classe, l’IDE lance une construction qui se traduit donc par une exécution de Maven. Selon le nombre de plugins concernés et leur rapidité, cela peut vite devenir pénalisant comme le montre la Figure 09-04 : l’IDE se fige en attendant la fin de cette exécution, et affiche le message très agaçant « user operation waiting for building workspace to complete ». Il s’agit d’une limite de l’IDE dans sa gestion des tâches de fond et de la construction incrémentale des projets, et celle-ci peut devenir très gênante pour son utilisation quotidienne. Les choses devraient aller mieux avec la prochaine version du plugin m2eclipse…

Veuillez patienter…

Le plugin Maven vient compléter les fonctionnalités de correction rapide (Quick Fix) d’Eclipse. Lors de l’utilisation d’une classe non référencée, d’un simple clic droit vous obtenez une liste de dépendances qui définissent la classe considérée (voir Figure 09-05). Il n’est donc pas nécessaire de passer par l’édition du POM pour ajouter une dépendance suite au copier-coller d’un fragment de code intéressant.

Correction rapide par ajout d’une dépendance.

Pour finir sa démo, Nicolas passe dans la vue dépendances, effectue une recherche sur commons-logging et obtient au bout de quelques instants une liste de bibliothèques variées et les chemins par lesquels nous récupérons ce JAR controversé dans notre projet. Un simple clic droit permet de l’exclure en ajoutant les nombreuses exclusions qui s’imposent. Ceux d’entre nous qui se sont déjà battus avec la gestion des dépendances de Maven, parfois un peu trop généreuse, apprécient ce raccourci.

Les versions successives de m2eclipse apportent corrections et nouvelles fonctionnalités et montrent un réel dynamisme pour proposer une intégration fiable et productive de Maven avec Eclipse. Il reste cependant assez déconcertant de voir deux plugins, dont l’architecture est relativement incompatible, hébergés par l’incubateur de la fondation Eclipse. Si quelques points de collaboration sont possibles, une fusion pure est simple n’est pas envisageable. Que va-t-il en ressortir, et surtout à quelle échéance ?

Idea étant, comme tous les IDE récents, basé sur des mécanismes d’extensions, il nous faut d’abord installer le plugin Maven. Cette formalité réglée, il ne nous reste qu’à demander l’import de notre projet en indiquant son répertoire racine (ou son URL Subversion), et à fournir quelques paramètres de base comme le JDK à utiliser et les profils Maven à activer dans notre environnement. On laisse ensuite l’IDE analyser et indexer tous les éléments du projet et de ses dépendances. Cette phase d’import peut être assez longue et nous permet de découvrir un premier lot d’astuces d’Idea, ou encore de vérifier le bon fonctionnement de la machine à café.

Après cette première étape incontournable, Idea présente chaque module du projet comme un projet Java, en ayant identifié les répertoires de code généré, le niveau de langage à utiliser pour la syntaxe Java et l’ensemble des dépendances. Comme sous m2eclipse, les références intermodules sont définies comme telles (sans passer par l’archive JAR), ce qui nous permettra d’éditer librement les sources des différents modules et de constater immédiatement leur impact.

Jusqu’ici, notre projet Maven est donc parfaitement bien pris en charge par l’environnement de développement (voir Figure 09-06). Nos modules sont clairement identifiés et présentés dans une vue dédiée. Celle-ci nous permettra de lancer depuis l’IDE les opérations gérées par Maven, par exemple une construction jusqu’à une phase précise du cycle de vie ou l’exécution d’un plugin particulier.

Le projet Maven après import dans Idea.

L’édition du fichier POM se fait via sa représentation XML, avec cependant de nombreux assistants. Idea identifie, par exemple, toutes les dépendances qui ne sont pas compatibles OSGi et propose de rechercher pour une version OSGi-ready, dans un dépôt spécialisé (typiquement celui géré par SpringSource pour son DM server). Bien sûr, tous ceux qui ne ciblent pas un environnement de ce type n’y verront qu’un gadget, mais l’engouement récent pour cette plateforme modulaire n’est pas à négliger ; aussi, est-il intéressant de constater que nos outils sont déjà à niveau pour la gérer.

Au sein de l’éditeur XML, Idea propose une assistance à la saisie dédiée à Maven, par exemple pour saisir les identifiants d’une dépendance ou d’un plugin. Ces références agissent comme des hyperliens et permettent de naviguer dans les POM du projet de manière fluide. Idea ne propose cependant aucune vue graphique des métadonnées Maven. Pas de synthèse ni d’outil d’analyse des dépendances. On reste donc un peu sur sa faim.

La vue de configuration du module (au sens Idea du terme) reflète cependant parfaitement les métadonnées de notre projet Maven (voir Figure 09-07). On y retrouve tous nos répertoires de code source (et de code généré), que nous pouvons au besoin compléter, mais dans ce cas la configuration Idea ne sera plus synchrone avec le projet Maven.

La configuration du module Idea à partir des métadonnées Maven.

De la même façon, les dépendances du projet sont clairement identifiées, avec un petit raffinement propre à Idea qui différencie le code de test du code principal, ainsi que les bibliothèques qui sont séparées en deux catégories (voir Figure 09-08). Les bibliothèques non exportées ne seront pas visibles depuis un autre projet qui fait référence au module considéré. Pas de risque ainsi d’introduire involontairement des imports parasites.

Les dépendances Maven vues sous Idea.

Les plugins qui génèrent du code lors des premières phases de la construction du projet sont invoqués lors de l’import du projet, ce qui permet à Idea d’identifier les répertoires associés. Pour le reste, Idea ne sait pas exploiter la configuration des plugins Maven pour ajuster la configuration des siens. Le développeur doit donc manuellement configurer le plugin Idea Checkstyle pour s’adapter aux règles déclarées dans son POM.

Cette restriction est valable pour tous les IDE, car elle demande au développeur de chaque plugin pour un environnement donné de faire l’effort de s’interfacer avec le support Maven, autrement dit de mettre un pied dans trois mondes différents (Maven, l’IDE et l’outil supporté par le plugin). Une telle gymnastique n’est pas facile et est généralement réservée aux outils majoritaires pour lesquels l’effort en vaut la chandelle.

Ce résultat en demi-teinte est rapidement compensé par la démonstration que nous fait Stéphane de l’utilisation courante de l’IDE. Il édite quelques classes, ajoute des dépendances, puis lance un test. Dans tous les cas, l’environnement répond promptement et ajuste sa configuration en fonction des directives du POM. Stéphane résume les choses en disant qu’il marche, « tout simplement », faisant référence à son rival Eclipse dont le building workspace n’amuse plus personne.

L’intégration de Maven dans Idea se fait donc sans fioriture visuelle qui sorte du lot, mais tout simplement avec une solution totalement fonctionnelle et parfaitement intégrée dans le fonctionnement de l’IDE. Contrairement à ce qui se passait avec Eclipse, nous n’avons pas l’impression de voir s’exécuter une surcouche au-dessus de l’environnement qui tenterait de faire le lien entre deux mondes. C’est bien notre IDE qui sait parler le Maven, peut-être pas dans toutes ses subtilités, mais bien assez pour nous permettre de travailler confortablement.

Stéphane explique que ce qui oppose Eclipse à Idea, c’est la philosophie de l’outil : Eclipse tente de masquer la complexité des outils en intégrant tout leur fonctionnement dans son fameux build incrémental. Il en résulte qu’à chaque changement dans le code, un build Maven est lancé, parfois suivit d’un redéploiement par WTP, et qu’en conséquence une machine haut de gamme s’avère vite nécessaire. Idea est avant tout un éditeur et se focalise sur cette tâche pour fournir les assistances à la saisie de code les plus pointues. L’intégration des outils est présente, mais nécessite une configuration parfois manuelle et une exécution explicite. L’IDE reste en permanence disponible pour son utilisateur, et utilise les ressources de la machine pour offrir de meilleures analyses du code en cours de rédaction.

Nicolas grogne un peu dans son coin, se demandant s’il a choisi le bon camp, mais il est vite repêché par une question du jury : si les équipes sont habituées à Eclipse, largement diffusé dans les entreprises, l’apprentissage d’Idea est-il rapide ? Il faut bien l’admettre, apprivoiser un nouvel IDE prend du temps et les raccourcis que nous avons mis tant de temps à mémoriser sont désormais bien ancrés. Certes, le support de Maven dans Idea semble très bon, mais entre le coût de licence, le coût de (re)formation et l’éventuelle perte de productivité des développeurs contraints à migrer, il va falloir faire passer la pilule !

Avant que le débat ne s’enlise dans de stériles discussions sur le temps nécessaire pour apprivoiser un nouvel environnement et sur la compensation que peut apporter un outil plus efficace, nous décidons de passer à notre troisième candidat.

Le support de Maven est nativement intégré dans NetBeans, nous n’avons donc aucun plugin à installer. C’est prometteur : les développeurs de NetBeans ont pris à bras-le-corps la problématique du support de Maven dans l’IDE et n’ont pas délégué à une équipe externe l’intégration de cette fonctionnalité. Le reste de l’environnement n’a rien de fondamentalement déconcertant et la visite guidée proposée par Raphaël n’effraie pas grand monde.

Seconde bonne surprise, que Raphaël ne manque pas de souligner, NetBeans n’importe pas un projet Maven, il se contente de lire nativement le POM. Autrement dit, NetBeans ne va pas chercher à traduire le POM pour créer sa propre configuration comme le font Eclipse ou Idea, mais il va entièrement se baser sur le POM. Nous sommes ainsi assurés que les modifications qui lui seront apportées seront prises en compte sans nécessiter une quelconque synchronisation, de même que nous ne risquons pas de tomber dans le travers de modifier la configuration de l’IDE sans que le POM soit cohérent. La Figure 09-09 montre l’import d’un projet Maven, et, comme le souligne avec insistance Raphaël, le POM n’est pas dans cet environnement un format annexe, mais bien un descripteur de projet à part entière qui se suffit complètement.

Ouverture native d’un projet Maven.

Nos dépendances, répertoires de sources (y compris le code généré) et sous-modules sont parfaitement détectés, NetBeans ayant même le bon goût de séparer nos dépendances de test, ce qui améliore la lisibilité du projet qui compte plusieurs dizaines de bibliothèques. Le lancement d’une construction du projet dans l’IDE exécute tout naturellement Maven dans une console, et nous pouvons évidemment exécuter à la demande une tâche particulière.

L’édition des métadonnées du POM se fait ici aussi selon le formalisme XML. À l’intérieur de cet éditeur, NetBeans ne propose pas d’assistance à la saisie spécifique de Maven. Par contre, nous pouvons introduire de nouvelles dépendances via un menu contextuel (clic droit sur l’icône qui regroupe nos bibliothèques). L’assistant propose alors un outil de recherche, basé, comme ses concurrents, sur les index mis à disposition par les gestionnaires de dépôts.

NetBeans ne propose pas d’intégration particulière des plugins Maven pour lesquels il dispose de plugins équivalents. Cette passerelle semble donc être une spécificité d’Eclipse, que certains apprécieront mais à laquelle d’autres, comme Raphaël, préféreront un environnement réellement fonctionnel. Une rapide démonstration de développement suffit d’ailleurs à le prouver, et Raphaël rejoint ainsi Stéphane dans son combat tout sauf Eclipse.

NetBeans prend en charge la gestion des bibliothèques Maven de manière particulièrement intégrée dans les rouages de l’IDE. Les assistants de correction (Quick Fix) proposent par exemple de corriger un import non résolu en ajoutant la dépendance adéquate, via une recherche dans le dépôt. Comme l’indique la Figure 09-10, Raphaël ne se prive pas de nous montrer cette fonctionnalité comme preuve de la première place qu’occupe Maven dans son environnement préféré.

Intégration de la gestion des dépendances au plus profond de NetBeans.

La toute première version publique de « noubliepaslalistedescourses » a été particulièrement héroïque. Tout commence par plusieurs semaines de tests intensifs pour identifier tous les bogues qui auraient pu nous échapper. Les derniers correctifs sont appliqués, avant de se lancer dans une ultime journée de vérification pour être sûr de ne rien laisser au hasard. Après quoi, il nous faut préparer le logiciel enfin stabilisé et validé pour la diffusion. Emmanuel prend en charge la préparation de cette toute première mouture.

Il commence par parcourir tous les fichiers de configuration du projet pour indiquer comme numéro de version la fameuse valeur 1.0.0. Le projet, reconstruit avec cette nouvelle configuration, est testé une dernière fois avant d’être rendu public. Emmanuel marque dans notre gestionnaire de code source ce moment crucial, ce qui se traduit par la pose d’un « tag ». La journée se termine donc tard autour d’une bonne bouteille pour fêter le succès de notre belle aventure. « noubliepaslalistedescourses » est désormais en ligne et attend de pied ferme ses utilisateurs.

Une mauvaise surprise nous tombe dessus lorsque nous devons en urgence appliquer une correction pour un problème de performances. Soumise à un succès inattendu, l’application a commencé à cafouiller et il a fallu trouver des palliatifs immédiats. Le tag posé par Emmanuel nous permet de récupérer le code source associé à cette fameuse version 1.0.0 et de préparer aussi vite que possible une version 1.0.1 corrigeant ce problème. Et là, impossible de reconstruire le projet. Lors de la première livraison, les modifications n’avaient pas été complètement intégrées dans le gestionnaire de code source lors de la pose du tag. Emmanuel doit donc gérer dans l’urgence deux problèmes là où un seul lui suffisait déjà largement.

Pour ne pas reproduire la même erreur, il décide de poser le tag de la version 1.0.1, puis d’extraire du gestionnaire de sources le code associé au tag encore tout frais et de s’en servir pour construire le logiciel qui sera validé une toute dernière fois avant d’être publié. Si jamais nous détections un problème de dernière minute, il nous suffirait d’apporter les corrections nécessaires, de poser un nouveau tag et de reprendre la procédure.

Les choses semblent enfin maîtrisées, mais nous déchantons vite quand d’autres problèmes apparaissent sur la version 1.0.1. Après analyse, on comprend que ces problèmes auraient dû être détectés par notre outillage de tests. Alors, que s’est-il passé ?

Ces tests sont malheureusement associés à un profil qui doit être activé à la demande. Comme ils portent sur les accès à la base de données, et pour ne pas pénaliser les autres développeurs, nous les avons isolés dans un profil dédié, comme nous l’avons vu au Chapitre 4. Était-ce une fausse bonne idée ?

L’équipe de développement, malgré le fiasco de cette version corrective, n’en est pas convaincue. Les profils permettent à chacun d’être correctement outillé sur la partie qui le concerne sans être handicapé par des temps de construction interminables ou par des prérequis sur l’environnement de développement.

Lors de la construction de notre projet avant livraison, nous devons tout simplement ne pas négliger d’activer tous les profils adéquats pour valider au maximum l’application. Nous pouvons même ajouter, à cette phase cruciale, des profils spécifiques pour adjoindre des informations dans le livrable : date de livraison, auteur de la livraison, numéro de révision dans le gestionnaire de code source…

La version 1.0.2 sera donc la bonne, maintenant qu’Emmanuel tient enfin une procédure de livraison fiable et… connue de tous ?

La procédure peut être aussi bétonnée qu’on le voudra, elle n’est fiable que si elle est appliquée scrupuleusement. Autrement dit, le facteur humain reste comme toujours l’épée de Damoclès qui menace les projets.

La plupart des entreprises répondent à ce problème par une documentation lourdement contrôlée, répondant à des règles très strictes de contrôle qualité et à des nomenclatures précises. En supposant que tout le monde soit rompu aux pratiques de qualité et vive dans un monde labellisé AFAQ et ISO-900x, cela devrait garantir le succès du projet en toute circonstance. Seulement, nous ne vivons pas dans ce monde — est-ce réellement regrettable ?

D’autres préfèrent une approche plus souple et réactive en faisant appel à l’auto-organisation, par exemple via une documentation supportée par un wiki.

Emmanuel documente ainsi la procédure de livraison dans notre wiki, accessible rapidement et sans les ambiguïtés d’une classification documentaire complexe. Elle a aussi l’énorme mérite de permettre à celui qui applique la procédure de venir compléter la documentation pour préciser un point qu’il trouve mal expliqué, ou donner des indications sur un point pas assez détaillé. Certains seront très à l’aise avec les commandes Unix alors que d’autres auront besoin qu’on les prenne par la main.

Est-ce vraiment la panacée ? Pourquoi acceptons-nous que le moment de la livraison — le plus crucial de la vie du projet — soit le seul à ne pas bénéficier de l’approche que Maven a apportée au projet : l’automatisation aussi complète que possible via une commande unique. Emmanuel a pris le soin de documenter dans le détail la procédure, et le principe du wiki permet à chacun de la compléter si un point restait obscur. Cependant, nous construisons tous nos projets, quelles que soient leur complexité ou leur technologie, par la commande universelle mvn install. La procédure de livraison ne pourrait-elle pas elle aussi être homogénéisée ? Emmanuel part donc à la pêche aux bonnes pratiques du côté de Maven et de ses plugins…

Comme vous pouvez le constater, la démarche est plus que rigoureuse et elle est entièrement automatisée. Finalement, le projet dispose, dans son gestionnaire de versions, d’un tag pour la version à livrer, et la version courante (trunk) correspond à la prochaine version à développer. L’état « version livrée » n’est apparu que furtivement dans l’historique du gestionnaire de code source, ce qui correspond bien à la réalité de cet événement aussi ponctuel que capital.

La production du logiciel livrable est réalisée à partir du tag placé dans le gestionnaire de sources. Nous pourrions effectuer cette manœuvre manuellement, mais ici encore le plugin release simplifie la tâche :

Le point capital ici est que la description de la configuration et des commandes nécessaires à la construction correcte du livrable est entièrement documentée dans le POM lui-même. Pas de document à connaître, à retrouver dans la bonne version ou à ne surtout pas oublier de mettre à jour.

Un projet Maven utilisant le plugin release permet de réaliser une livraison totalement maîtrisée, contrôlée et synchronisée avec le gestionnaire de code source en une simple commande :

Emmanuel est plus que satisfait par cette simplicité. Maven prouve ici son efficacité : une commande unique pour réaliser un traitement loin d’être simple et applicable sur tous nos projets, toutes complexités et technologies confondues. Reprenez le document PROCx589002-02.1-Procédure de livraison.doc que vous aviez jusqu’ici et servez-vous-en pour caler votre armoire bancale. Et si votre responsable qualité vous réclame un document de procédure, faites-lui une photocopie de la Figure 10-01 !

Étapes réalisées par le plugin release_._

La préparation de la livraison comprend de nombreuses étapes et contrôles. Si l’une d’elles échoue, le plugin va évidemment s’interrompre. Après avoir identifié et corrigé le problème, nous avons deux options :

La seconde solution est évidemment moins stricte ; cependant, vous pouvez parfois être bloqué par un problème purement local et indépendant de la stabilité du projet, comme un contrôle de votre environnement par le plugin enforcer qui échoue, ou la construction qui n’aboutit pas parce que vous n’avez pas attribué suffisamment de mémoire à l’exécution de Maven.

Dans les deux cas, la résolution du problème ne nécessite pas de modifier le projet lui-même, et le plugin release permet de reprendre le processus : par défaut, lancé une deuxième fois sur le même projet, il va reprendre sa tâche là où il en était resté, sauf si on lui indique explicitement de tout reprendre de zéro via l’option -Dresume=false.

Notre processus est désormais bien rôdé. Reste un dernier point à régler : sur quel environnement faire la release ? Dans notre build, nous avons tenté de blinder au maximum toute dépendance à l’environnement, clarifié tous les prérequis. Mais nous savons bien qu’un grain de sable se faufile si vite entre les rouages…

Nous sommes tous d’accord : un poste de développement n’est pas idéal pour faire la release. Il contient par définition des éléments de test, des fichiers modifiés, des simulateurs en tout genre que nous risquons d’incorporer sans le savoir dans le livrable. Pourtant, il y a un membre de l’équipe qui est irréprochable sur le sujet : notre intégration continue !

Avantages majeurs :

Notre serveur Jenkins dispose justement d’un plugin qui correspond à toutes nos attentes : « Maven Release Plugin », un plugin pour lancer une release depuis notre fauteuil par un simple click — sitôt essayé, sitôt adopté !

La livraison de la version 1.2.0 de « noubliepaslalistedescourses » n’a pas été une de ces journées de stress sans fin, qui se terminent bien après le coucher du soleil. Elle n’a pas non plus été menée par un expert rompu à tous nos outils et spécialiste de la procédure. C’est notre stagiaire qui l’a réalisée, le plus naturellement du monde, et sans même se rendre compte de ce qu’avaient pu être les livraisons précédentes.

L’approche par convention et l’excellente extensibilité de Maven montrent toute la force de celui-ci dans le plugin release. Un seul fichier, utilisant un formalisme XML certes verbeux mais simple, permet de décrire toutes les étapes de construction et toutes les options nécessaires pour obtenir un résultat fiable.

L’outil de Geegol est assez simple d’utilisation. Il est écrit en Java, et on l’invoque depuis la ligne de commande en fournissant la liste des fichiers sources .java à analyser. Il faut également que le classpath soit configuré pour inclure toutes les bibliothèques référencées dans ce code source. Hervé s’attaque donc à l’application de ce nouvel outil sur notre projet, en l’intégrant dans notre processus de construction par Maven.

Une étape préalable à toute solution basée sur Maven est de mettre à la disposition de celui-ci la bibliothèque de notre outil gea-check sous forme d’artefact Maven. Nous devons donc le placer dans notre dépôt de bibliothèques, accompagné d’un fichier POM fournissant les métadonnées adéquates, en particulier la liste précise de ses dépendances. Nous avons déjà évoqué au Chapitre 2 l’identification des bibliothèques et de leur version. Hervé prépare soigneusement un fichier POM et le télécharge avec l’archive JAR dans notre dépôt de bibliothèques.

De nombreux projets utilisent Ant pour leur construction – ou l’ont utilisé avant de passer à Maven – avec les limites que nous avons déjà vues. Le groupe a développé pour son outil une tâche Ant qui lance la génération documentaire, nous ne partons donc pas de rien.

La solution la plus rapide consiste à utiliser la tâche Ant telle quelle dans notre projet Maven. Hervé pourra ainsi rassurer tout le monde en prouvant que le choix de Maven ne met pas des bâtons dans les roues. Cela est possible grâce à un plugin standard : AntRun, lequel, comme son nom le suggère, va exécuter un script Ant lors de la construction du projet par Maven. Voilà qui pourrait bien nous sauver la mise ! Le Listing 11.1 montre la configuration que nous avons ajoutée au projet pour gérer cette étape.

Ce fragment de script Ant réutilise des variables Maven pour pointer vers les répertoires du projet, conformément aux conventions de Maven, et manipuler les listes de dépendances du projet et du plugin. Par défaut, le plugin AntRun ne propose dans le ClassPath d’exécution du fragment de script que la bibliothèque Ant standard (la version d’Ant utilisée par défaut dépend de la version du plugin, Antrun 1.3 utilise par exemple Ant 1.7.1). Pour invoquer notre tâche spécifique, nous devons y ajouter la bibliothèque maison GEACheck (et ses dépendances) via un bloc <dependency>, appliqué au plugin.

Cette petite manipulation nous permet donc d’utiliser sans souci les outils en place. Fin du Chapitre 11 ? Non, bien sûr.

Cette solution est très pratique car elle permet de réutiliser en peu de temps du code existant. Dans la même veine, nous pourrions exécuter un script Groovy ou BeanShell. Cependant, cette pratique n’est pas tout à fait satisfaisante :

Hervé n’est pas prêt à se contenter de cette solution qui n’est, pour lui, qu’un pis-aller : d’une part, nous sacrifions l’idée phare de Maven de ne pas devenir un nième langage de script. Où est l’approche déclarative dans ce que nous venons de faire ? D’autre part, l’intégration de notre bout de script Ant dans Maven est très imparfaite. Nous devons explicitement déclarer les dépendances de l’outil de génération dans notre fichier POM – ce qui signifie que nous devons les connaître, donc aller consulter sa documentation pour en extraire cette information. Cela ne vous rappelle rien ? Alors, retournez au Chapitre 2 !

AntRun a été conçu comme un outil de transition pour faciliter la vie des projets basés sur Ant. Les concepteurs de Maven, conscients qu’il était impossible de proposer des plugins pour toutes les tâches Ant existantes, ont introduit ce plugin utilitaire, en insistant bien sur son rôle de roue de secours en attendant mieux. Nous l’utilisons donc provisoirement pour répondre aux exigences du groupe, mais lançons immédiatement une nouvelle tâche : l’écriture d’un plugin Maven pour notre outil de génération documentaire. C’est donc à cette tâche qu’Hervé va s’attaquer à présent.

Créer de toutes pièces un plugin peut faire peur a priori. Nous allons voir, pourtant, que cela ne nous dépaysera pas beaucoup de notre développement classique avec Maven. Nous allons dérouler, au cours des paragraphes suivants, la construction pas à pas de ce plugin.

La première étape nécessite de créer un projet Maven pour notre plugin. Ce projet est tout ce qu’il y a de plus classique, à la seule exception de son type d’assemblage, qui est maven-plugin.

Le reste du projet est tout ce qu’il y a de plus classique. Répertoires de sources, de ressources et de tests, dépendances et compagnie. Pas de quoi fouetter un chat !

La tâche check que nous voulons créer dans notre plugin sera associée à une classe spécifique. Ces classes sont appelées dans le vocabulaire Maven des mojos (Maven Old Java Object), par allusion au concept de POJO ^[38] qui a fait le succès des bibliothèques Spring et Hibernate. Ce terme a aussi été choisi avec malice pour faire référence au nom donné au Cameroun à des amulettes – inutile de chercher un lien avec le personnage de super-vilain associé à ce nom dans le comics X-Men ;-).

En fait, ce sont de simples classes qui implémentent l’interface org.apache.maven.plugin.Mojo, et, dans la très grande majorité des cas – dont le nôtre –, on se contente d’étendre la classe AbstractMojo. Le Listing 11.3 présente la structure générale de notre classe GEACheckMojo.

Toutes les caractéristiques liées à Maven sont déclarées dans des balises Javadoc spéciales de notre classe Mojo. C’est ici qu’Hervé va indiquer le nom de la tâche et éventuellement des indications sur les contraintes que le projet doit respecter pour l’utiliser.

Le Listing 11.3 montre le bloc de commentaires Javadoc de notre mojo. L’annotation @goal indique le nom de la tâche. @phase indique la phase dans le cycle de vie pour laquelle notre mojo a été conçu, et à laquelle il sera greffé par défaut. Nous associons le plugin à la phase d’analyse des sources, qui a lieu avant la compilation.

Nous avons donc un projet Maven capable de produire un plugin qui exécutera notre code Java lors de la phase process-sources. On vous l’avait bien dit que ce n’était pas bien compliqué !

Le plugin d’Hervé est un peu tout seul dans son coin. On doit encore lui associer des paramètres qui permettront d’ajuster son fonctionnement aux besoins de nos projets.

L’outil d’analyse que nous cherchons à intégrer produit un fichier de compte-rendu. Hervé va dans un premier temps permettre à l’utilisateur de définir le nom et l’emplacement de ce fichier, tout en proposant une valeur par défaut qui devrait convenir à la majorité des cas.

Comme la configuration générale du Mojo, les paramètres sont déclarés via des annotations « à l’ancienne » dans le Javadoc (aussi connu sous le nom de doclets). Chaque paramètre peut définir une valeur par défaut, qui servira donc de convention pour l’utilisation du plugin. Cette valeur par défaut peut être une expression faisant référence à un élément du fichier POM. Dans l’exemple précédent, nous identifions par exemple le paramètre output où l’outil d’analyse va écrire son rapport. Les utilisateurs de notre plugin pourront modifier ce paramètre dans leur fichier POM en ajoutant dans la configuration un élément <output> avec le chemin de leur choix.

L’expression délimitée par « ${ » et « } » permet d’identifier des nœuds du modèle objet du projet ; rappelez-vous que Maven charge les données XML de notre POM en mémoire sous forme d’un arbre d’objets, après fusion avec les parents dont il peut hériter et activation des profils. project.build.directory équivaut ainsi à l’élément <project><build><directory> du fichier POM.xml du projet, de son parent ou de la valeur par défaut de cette propriété. Dans la très grande majorité des cas, il s’agira du répertoire target, mais ne présumons pas de la façon dont notre plugin sera utilisé et des contraintes que vont rencontrer nos projets. Conventions ne signifie pas obligations !

Dans sa première version, le plugin d’Hervé, pour analyser notre code source, utilisait un paramètre basé sur l’expression project.build.sourceDirectory, qui renvoie pour un projet standard le chemin src/main/java. Hervé lance donc son plugin sur le projet devant nos yeux pleins d’impatience et il est fier de nous présenter le rapport généré quelques secondes plus tard dans le répertoire target. Applaudissements, puis désillusion : le code analysé est bien celui de notre projet, mais il en manque toute une partie !

Notre projet utilise un plugin générateur de code, transformant un modèle UML en code source Java. Ce code est créé sous target/generated-sources/plugin et n’a pas été exploité par l’outil d’analyse. Oups, boulette. Hervé retourne rapidement à son code, quelque peu gêné par ce petit contretemps.

Un projet Maven comprend, au niveau du modèle du projet, non pas un répertoire source mais une liste dynamique d’emplacements. Chaque plugin qui génère du code source va ajouter le répertoire qu’il utilise sur cette liste. De la même façon, les plugins qui exploitent le code source, à commencer par le plugin de compilation, vont reposer sur cette liste dynamique de répertoires.

Pour accéder au modèle objet du projet et consulter le moment voulu cette liste de répertoires, nous devons manipuler directement l’objet MavenProject que Maven met à notre disposition. Nous définissons donc un nouveau paramètre au plugin, bien que celui-ci soit un peu particulier :

Nous découvrons en passant deux autres annotations qui peuvent s’appliquer aux paramètres. @required permet de stopper le build avec un message d’erreur adéquat si la configuration est incomplète, et @readonly signale que le paramètre est extrait des structures internes de Maven et non spécifié par l’utilisateur dans son POM.

Nous pouvons ainsi mettre un pied dans les API de Maven et sa modélisation objet d’un projet. Selon la tâche à réaliser, cela pourra être nécessaire. L’invocation de la méthode project.getCompileSourceRoots() donnera la liste courante de tous les répertoires de fichiers sources.

Pour étoffer son plugin, Hervé veut dans notre cas proposer une archive ZIP du rapport (très verbeux) généré par l’outil d’analyse Geegol, pour que l’utilisateur puisse plus facilement le télécharger et en conserver l’historique. C’est ici qu’intervient la notion de composant, une brique logicielle réutilisable. Les briques en question dépendent de la technologie sur laquelle tourne une application.

Maven utilise le conteneur Plexus ^[39] pour l’exécution de ses composants. Vous êtes probablement familiarisé avec l’un de ses concurrents qui remporte un grand succès en entreprise : SpringFramework. Le fonctionnement de Plexus est relativement comparable, en dehors du mécanisme d’annotations qui jusqu’il y a peu de temps ne s’appuyait que sur des balises Javadoc à la place des annotations de Java 5.

Plexus et Maven mettent à disposition un large choix de composants utilitaires que vous pouvez référencer dans des plugins. Hervé a besoin d’exploiter les capacités d’un outil d’archivage, il ajoute en dépendance à son projet Maven la bibliothèque plexus-archiver. Il lui reste à présent à y accéder depuis le plugin.

Comme Spring, Plexus met en œuvre le patron d’injection de dépendances ^[40] (eh oui, bien que méconnu, Plexus était très novateur en son temps !). Ce n’est donc pas le plugin qui va aller chercher un composant mais le conteneur qui va initialiser le plugin avec les composants déclarés comme indispensables. Un composant est référencé via l’annotation @component et sera injecté lors de l’exécution de Maven directement au niveau de l’attribut. Le composant est identifié par une chaîne de caractères qui est, par convention, le nom complet de l’interface qu’il réalise. Lorsque plusieurs variantes sont disponibles, Plexus propose soit de compléter l’identificateur par un qualificateur complémentaire identifié par le caractère « # », soit de préciser plus explicitement un attribut hint (voir l’exemple suivant). Pour faire appel à un composant de décompression d’archive ZIP par exemple, on ajoutera l’attribut suivant dans notre plugin :

Il faudra évidemment ajouter à notre plugin une dépendance vers la bibliothèque plexus-archiver qui contient ce composant. L’écosystème Plexus compte de très nombreux composants, permettant de traiter un grand nombre de tâches. La documentation de ces composants est malheureusement souvent un peu minimaliste, et même leur liste complète est délicate à obtenir en dehors du code source sous SVN.

En plus des composants Plexus, Hervé a besoin de faire de nombreuses manipulations de fichiers, entre autres pour sélectionner la liste des fichiers .java dans nos répertoires de code source.

Une bibliothèque un peu à part dans l’écosystème Plexus est plexus-utils. Elle ne propose pas de composants au sens où nous l’avons vu précédemment, mais un ensemble de classes utilitaires. En particulier, on y trouve une série de méthodes de manipulation de fichiers FileUtils ainsi qu’un DirectoryScanner, qui permet de sélectionner des fichiers à partir d’un répertoire en fonction de patrons Ant d’inclusion et d’exclusion.

Nous avons donc une méthode qui retourne la liste complète des fichiers sources Java de notre projet, code généré inclus ! Reste à passer l’outil de contrôle Geegol dessus.

Une difficulté à traiter est que le classpath de notre plugin sera constitué en fonction des dépendances qu’il déclare, et non en fonction du projet sur lequel nous allons l’utiliser. Nous devrons donc construire un ClassPath combinant le projet avec la dépendance gea-check de notre plugin pour exécuter notre outil dans les conditions nécessaires à son bon fonctionnement.

Pour gérer la séparation de ses classes internes et de celles de ses plugins, Maven repose sur la bibliothèque ClassWorlds ^[41]. Celle-ci définit la notion de royaumes (realm) dans lesquels on vient ajouter des éléments de classpath et, éventuellement, exporter des packages. Maven met ainsi ses API à disposition des plugins sans exposer pour autant ses classes internes. Il est intéressant de voir que cette même problématique est relevée de manière indépendante par OSGi, sur lequel on aurait sans doute bâti Maven s’il avait été créé en 2009 !

Vous avez sans doute déjà rencontré des problèmes de ClassLoaders, de sombres histoires de classes qui ne sont pas ce qu’elles disent être, ou encore des problèmes pour la configuration de la bibliothèque commons-logging. C’est un sujet complexe, aussi nous ne nous attarderons pas ;).

Pour notre plugin, nous allons construire un realm dédié à l’exécution de GEACheck, incluant ce dernier et ses dépendances ainsi que les chemins d’accès au code source. La figure 11-01 montre la structure que nous devons mettre en place.

Figure 11-01

Arbre des royaumes ClassWorlds.

Le Listing 11.4 montre le code du plugin pour :

Par souci de clarté, nous n’avons pas indiqué dans ce listing les diverses gestions d’exception qui sont rendues nécessaires par la manipulation d’URL. Cette gymnastique est la plus grande difficulté rencontrée lors du développement d’un plugin Maven, d’une part parce que le commun des développeurs n’est pas suffisamment à l’aise avec le concept de ClassLoader, d’autre part parce que l’API Maven-project manque de documentation.

Il ne reste plus à Hervé qu’à utiliser le ClassLoader que nous venons de construire pour charger l’outil GEACheck et à l’invoquer avec la liste de fichiers sources java que nous avons construite précédemment. L’invocation d’une classe depuis un classloader différent du nôtre nous oblige à passer par la réflexion Java (voir Listing 11.5).

Olivier revient tout juste d’une conférence sur l’avenir de Java et les plans de développement de JavaEE 7, et nous trouve tous au chevet de notre plugin. Sa première réaction est la stupeur : nous sommes en train de développer du code en injectant des dépendances via des annotations dans du JavaDoc, le genre de choses qu’on faisait … en 2004 avec Apache commons-attributes ! Nous avons mis dans notre projet le top du dernier buzz en termes de technologies, et nous voilà ramenés une décennie en arrière.

La cause de ce choc technologique, c’est que nous utilisons l’API Maven 2.0, qui date de la création de l’outil. Pour offrir une compatibilité sans faille à ses utilisateurs, Maven 3 reste 100% compatible avec cette API historique, alors qu’en interne les choses ont beaucoup changé.

Dans l’équipe, nous utilisons tous Maven 3, Java 7, JavaEE 6, pourquoi s’encombrer de ce passé obsolète ?

Olivier s’attaque donc à moderniser notre socle technique. Bye Bye Maven 2, ce qui se traduit dans note POM par un prérequis sans appel :

Voilà qui rappellera à l’ordre les éventuels distraits.

Dans notre plugin, Olivier convertit nos attributs JavaDoc dans leurs équivalents en annotations Java, sur la base de l’API maven-plugin-toolss-java5 et de l’injection de dépendances @JSR-330.

Attention

Olivier se base sur du code qui n’est pas encore disponible en version finale. Sonatype est très actif sur ce chantier (projet Sisu : https://github.com/sonatype/sisu) qui vise à homogénéiser son offre logicielle, aussi à l’heure où la seconde édition sortira des presses, nous espérons que ce code sera intégré dans la version courante de Maven 3.x

Maven propose une suite de tests sous forme d’objets simulacres (« mock ») pour ses API et un mécanisme simple pour configurer une instance du plugin à tester. Un extrait de fichier POM est utilisé pour définir la configuration de test du plugin, et l’environnement de test se charge d’exécuter le plugin.

La mise en œuvre est simple, puisqu’il s’agit d’écrire une classe de test jUnit très classique et de faire appel au plugin-testing-harness pour configurer le plugin que nous désirons tester à partir d’un pseudo POM, limité à sa seule section <plugin>. Le Listing 11.7 montre le code de ce test, qui va exécuter le plugin et vérifier son fonctionnement. Le Listing 11.8 montre le pseudo fichier POM qui lui sert de base pour construire et configurer le plugin testé.

Une seconde option consiste à exécuter la construction d’un projet Maven de test, mais dans un mode automatisé. C’est l’option retenue par le plugin invoker, qui va enchaîner un build Maven parallèle lors de la phase de test d’intégration de notre projet de plugin. Contrairement au plugin plugin-testing-harness, il ne s’agit pas d’exécuter le plugin dans un environnement de test « unitaire », mais de lancer une construction Maven complète, indépendante et d’en valider a posteriori la bonne exécution.

Recherchant les fichiers POM placés dans le répertoire de tests src/it, invoker va utiliser un script Groovy ou BeanShell pour vérifier le résultat de l’exécution. Ce script va typiquement s’assurer que des fichiers attendus en résultat de l’exécution sont présents et/ou correctement renseignés.

Le Listing 11.9 présente la configuration du plugin invoker pour exécuter un projet Maven de test. Le plugin recherche dans notre répertoire src/it tous les sous-répertoires contenant un fichier pom.xml, les recopie dans le répertoire de travail et y exécute un build Maven (jusqu’à la phase package). Nous pouvons donc organiser notre répertoire de tests d’intégration en ayant un sous-répertoire par test d’intégration, contenant le projet Maven d’intégration à tester. Le Listing 11.10, quant à lui, présente le fichier groovy que nous utilisons pour vérifier que l’exécution s’est déroulée comme prévu et que le fonctionnement du plugin est donc correct.

Hervé configure le serveur d’intégration continue pour surveiller, en plus de notre projet, la bonne santé de son plugin, lequel, outillé de tests, est maintenant prêt pour vivre sa vie et répondre au besoin à des demandes d’évolution ou de nouvelles contraintes. Hervé n’a plus qu’à documenter ce plugin et son utilisation… mais pour cela il devra attendre le chapitre suivant !

Une première catégorie d’outillage concerne l’analyse statique du code. Il s’agit d’une relecture du code par un outil qui va rechercher des patrons particuliers et calculer des métriques. En Java, il existe plusieurs outils de cette catégorie, lesquels peuvent extraire :

Le premier type d’indication est évidemment celui qui attire tout de suite nos décideurs : comment résister à un outil qui, en quelques clics, va identifier tous les bogues si coûteux que nous avons négligemment laissés traîner ?

Les outils d’analyse statique font déjà de grandes choses, mais ils ne peuvent pas faire de miracle. En particulier, ils ne sont pas en mesure de deviner comment est utilisée réellement l’application. Pour cela, il faut la faire tourner dans un environnement et une utilisation réalistes. Or, nous avons déjà, depuis le Chapitre 4, une belle panoplie de tests qui exécutent notre application, par petits morceaux, en se focalisant sur des scénarios d’utilisation issus de nos besoins fonctionnels (rappelez-vous les règles du développement dirigé par les tests !).

Cobertura, Clover ou Emma sont des outils d’analyse dynamique qui visent à déterminer quelle portion de notre code est exécutée au cours de nos tests, censés couvrir les fonctionnalités de notre application. Leurs rapports indiquent le taux de couverture du code et remontent jusqu’au code source pour nous indiquer quelle ligne a été exécutée au moins une fois au cours d’un test.

Comment exploiter un tel outil ?

Olivier, qui est venu épauler Vincent, évalue avec lui ces outils et l’information qu’ils fournissent. L’indication synthétique est un taux de couverture de notre code par des tests : 65 %. Est-ce bien ou pas ?

Brute, cette information n’a aucune utilité ou presque. Son intérêt est plus de voir comment ces 65 % se répartissent sur notre code. En descendant à un niveau de détail plus fin, on découvre dans le rapport qu’une majorité de nos packages sont couverts à environ 70 % et que deux mauvais élèves se contentent de 30 %. Nous tenons nos coupables : deux packages pas assez testés, ou mal testés, ou peut-être même du code inutile !

Sur ce constat, reposons donc la question : comment exploiter un tel outil ?

Si nous établissons comme règle d’or le taux de couverture des tests doit dépasser 75 %, que va-t-il très probablement se passer ? Vous pouvez parier que le package beans va rapidement être testé à 100 % afin d’atteindre ce taux de 75 %. Le développeur étant par nature feignant, il choisira la solution de facilité, surtout si son chef l’assomme de reproches sur le non-respect de la règle d’or !

L’outil fournissait pourtant une information capitale : remoting, couche critique de notre application, est celle qui est la moins bien testée. Il nous encourage effectivement à retrousser nos manches pour mieux instrumenter ce code, peut-être en le réarrangeant afin qu’il soit plus modulaire et plus testable, peut-être en développant des simulateurs plus faciles à intégrer dans un test unitaire.

Vincent prend cela en considération et établit notre première règle d’or :

Un taux de couverture inférieur à la moyenne doit être justifié. Pas de taux absolu et inexplicable à atteindre, mais, par contre, interdiction de délaisser une partie de l’application sans bonne raison.

Il considère ensuite le reste de l’application : la couverture de code est homogène, mais est-elle suffisante ? Comment va-t-elle évoluer ? Comment doit-elle évoluer ? Si nos classes de JavaBeans gonflent suite à l’ajout de méthodes get/set, notre taux va irrémédiablement baisser, mais ce ne sera pas significatif. Par contre, si l’ajout de nouvelles fonctionnalités dégrade le taux de couverture, c’est que ces nouvelles fonctionnalités ne sont pas au moins aussi bien testées que le code en place.

Cela inspire donc une seconde règle d’or, que nous pourrions qualifier de protectionniste :

Le taux de couverture ne doit pas baisser avec le temps sans justification.

Vincent arrive donc rapidement à la conclusion qu’il va devoir trouver un moyen pour contrôler l’évolution dans le temps de nos indicateurs. Être capable d’estimer la couverture de test apporte des informations utiles, mais savoir si elle est en perte de vitesse et sur quels packages est bien plus important.

Notre boîte à outils est désormais comprise et correctement configurée. Il reste à Vincent à automatiser son utilisation pour mettre ces indicateurs à la disposition de tous et permettre leur suivi dans le temps. L’assurance qualité ne fonctionne que si elle est la préoccupation de tous. Donner à quelqu’un la tâche de suivre les rapports d’analyse n’a aucun sens, il passerait rapidement pour le casse-pieds de service. Mobiliser quelques instants d’attention de toute l’équipe est peu coûteux individuellement et nettement plus efficace.

Vincent pourrait continuer ainsi son tour de table des outils d’analyse de code, mais toute cette instrumentation ne sera vraiment productive que si elle vient s’intégrer dans nos outils. Nous avons déjà confié la construction de nos binaires à Maven, pouvons-nous également lui passer la main sur notre suivi qualité ?

Doxia est donc le moteur qui va formater notre documentation. Utilisé par le plugin site, il produit des pages HTML. Utilisé par le plugin pdf, il produit un fichier PDF regroupant toute la documentation du projet. La commande mvn pdf:pdf permet ainsi de produire une documentation format papier, toujours à jour en fonction des diverses sources que nous avons agrégées.

Comme le plugin site et son fichier site.xml, le plugin pdf s’appuie sur un descripteur pdf.xml qui lui indique comment assembler les éléments documentaires pour produire le résultat. De la même façon, et avec les moteurs de rendu adéquats, Doxia pourrait produire notre documentation dans tout un ensemble de formats qu’il reste à imaginer (voir Figure 12-01).

Figure 12-01

Génération de la documentation en différents formats grâce à Doxia.

Rapidement, un besoin nouveau s’exprime : lorsque nous constatons qu’un élément du projet est sous-documenté, nous ajoutons quelques fichiers APT pour combler le manque. La perception de ce défaut de documentation est totalement subjective, mais nous arrivons rapidement à un consensus sur le niveau obtenu. Par contre, le rapport indiquant le taux de couverture de nos tests est plus délicat à interpréter. 68 %, est-ce bien ? Est-il utile de vouloir pousser ce taux au-delà, ce qui pourrait rapidement nous amener à écrire des tests sans intérêt juste pour approcher des 100 %. Pire, nous pourrions être tentés d’écrire de nombreux tests faciles pour obtenir un bon chiffre en délaissant des parties de code moins évidentes à tester.

68 %, ça ne veut rien dire. Ce qui est intéressant, c’est de voir que le mois dernier, nous étions pour le même package à 82 % ! Il semble que nous avons laissé cette partie du projet se dégrader ! À moins que nous n’ayons une bonne explication pour cette baisse, une action doit être entreprise pour corriger le tir.

Les indicateurs qualité sont rarement très pertinents tels quels, et, en tout cas, la valeur cible à respecter dépend du contexte du projet, de ses objectifs et souvent de l’élément technique considéré. Notre code d’accès à la base devrait être proche de 100 % de couverture de test, sinon cela voudrait dire que certaines requêtes ne font pas l’objet de tests et qu’une modification dans notre modèle ne serait pas détectée. De même, tous les aspects fonctionnels (le code métier utile) doivent être largement couverts. En revanche, d’autres parties de notre code, présentant de nombreux cas d’erreurs qui ne donnent pas lieu à un traitement précis autre que « erreur interne, merci de réessayer plus tard », peuvent légitimement obtenir une couverture moindre.

Il n’existe pas de juste milieu absolu. Néanmoins, on constate l’application universelle du second principe de la thermodynamique : le code tend toujours à se dégrader pour devenir moins organisé et moins bien testé. Des tests obsolètes sont supprimés, le nouveau code écrit dans la chaleur d’un coup de bourre est peu ou pas instrumenté… Juste maintenir le code au même niveau demande une débauche d’énergie, de temps et donc de budget !

Pour détecter rapidement une telle dérive, rien ne vaut un bon graphe synthétique historisant l’évolution du projet. De manière assez amusante, on peut souvent deviner les dates de livraison sur de telles courbes : on constate un infléchissement de la courbe dans la semaine qui précède la livraison et (dans le meilleur des cas) une reprise lente dans les semaines qui suivent.

Le spécialiste en thermodynamique de l’équipe c’est Vincent, et c’est donc lui qui nous propose spontanément un outil pour être en mesure de mesurer l’entropie de notre projet. Il a déjà passé de longues heures à analyser les nombreux rapports produits par Maven dans notre site et a rapidement compris que ce ne sont que des données brutes. Il faut être capable de les lire à des altitudes différentes :

Ce Google Earth pour code existe, il s’appelle Sonar.

Sonar ^[43] est une application web qui va stocker dans une base de données tous les indicateurs et statistiques extraits par nos rapports d’analyse de code. En outil convivial et soucieux de sa simplicité d’utilisation, il est proposé avec un serveur d’application et une base de données embarqués, ce qui limite la procédure d’installation au strict minimum. Pour une utilisation en entreprise de manière plus stratégique, on pourra cependant le déployer sur un serveur et le configurer pour utiliser une base de données dédiée.

Les données de Sonar sont accessibles via un frontal web synthétique, qui donne les grandes tendances du projet. C’est notre vue à 30 000 pieds du projet (voir Figure 12-02).

Synthèse de nos indicateurs qualité dans Sonar.

La représentation du projet en blocs colorés est particulièrement compacte et pertinente. Pour un critère donné – ici, le respect des règles de codage –, un bloc de grande surface correspond à un grand volume de code et la couleur au niveau de satisfaction du critère. Un petit bloc rouge dans un ensemble vert pourra donc être acceptable si on sait le justifier, alors qu’un grand bloc orange sera de très mauvais augure. Chaque élément de cette synthèse est un lien vers plus de détails. On va ainsi descendre de lien en lien jusqu’aux classes du projet puis ouvrir son code source pour constater la ligne de code qui a été identifiée par l’analyse de code (voir Figure 12-03).

Détail des violations constatées par Sonar dans notre code source.

Sonar va extraire de notre projet Maven l’ensemble des indicateurs qu’il prend en charge via un plugin dédié. Celui-ci va directement enrichir la base de données du serveur Sonar pour la construction en cours. Le serveur exploitera ensuite les données pour fournir une synthèse ainsi qu’un historique. Le Listing 12.4 montre la configuration de ce plugin dans notre POM. Le plugin sonar utilisant de nombreuses propriétés, il est plus simple de les configurer comme telles et d’invoquer la tâche mvn sonar:sonar.

Pour produire ces métriques de notre projet à intervalles réguliers, nous décidons de laisser notre serveur d’intégration continue effectuer une construction dédiée toutes les nuits – il faut bien rentabiliser la machine. Sur notre serveur Hudson, nous avons la bonne surprise de découvrir un plugin dédié à Sonar, qui nous économise la configuration de cet outil dans notre POM. Il suffit de fournir quelques paramètres dans la console d’administration de Hudson et de configurer une construction du projet à heure fixe.

Nous constatons que la complexité mesurée de notre code grimpe régulièrement (voir Figure 12-04). C’est une dérive typique qui prend pied de manière maligne, répartie un peu partout dans le code et sans que personne s’en sente responsable. Il est temps de sensibiliser l’équipe, par exemple en lui montrant cette simple courbe, sur l’influence que peut avoir un petit effort quotidien de clarification et de simplification du code.

Évolution de nos indicateurs qualité.

La Figure 12-05 indique également le Top 10 des violations constatées, ce qui nous dira immédiatement sur quoi nous devons mettre l’accent. Notre session mensuelle de débriefing est déjà toute tracée !

Sonar n’est définitivement pas un outil de flicage, c’est un assistant extrêmement puissant pour accompagner le travail d’une équipe et pointer du doigt ses dérives. Le développeur parfait n’existe pas, mais le développeur bien outillé peut tenter de s’améliorer.

Classement des violations les plus souvent identifiées

Une solution consiste à produire des binaires dont le numéro de version est complété par un compteur de construction, que le serveur d’intégration continue incrémente à chaque tentative de construction. Le serveur d’intégration continue a le bon goût de nous fournir la valeur courante sous forme d’une variable système, que nous pouvons donc exploiter dans le build Maven. Le Listing 13.1 montre la configuration de notre POM pour exploiter cette variable et produire les livrables en conséquence. Nous utilisons un profil qui n’est activé que sur le serveur d’intégration continue, afin de ne pas perturber les autres environnements.

Notre livrable est ainsi construit sous le nom noubliepaslalistedescourses-1.2.0-SNAPSHOT-build-792. La consultation de l’historique de notre intégration continue indiquerait immédiatement à quel code source correspond ce build 792. Nous pouvons d’ailleurs demander au serveur d’intégration continue de conserver soigneusement les traces d’une construction dont nous livrons le résultat à l’équipe de test et de placer une marque dans le gestionnaire de code source en conséquence.

Une solution alternative, liée à l’utilisation du gestionnaire de code source Subversion, est la notion de révision. Sur Subversion, à chaque commit c’est tout le référentiel qui voit son numéro de révision incrémenté, et pas juste le fichier modifié. On arrive ainsi rapidement à des numéros de révision à cinq ou six chiffres.

Si cela n’a aucune influence sur le développeur, cela fournit un moyen de lier un livrable à son code source de manière extrêmement précise : si le binaire a été construit à partir de la révision 4704, il suffit d’extraire de SVN l’état du code source associé. Nous pouvons d’ailleurs demander a posteriori à Subversion de poser une marque pour le code associé à cette révision particulière.

Avantage par rapport au numéro de construction, ce numéro de révision n’est pas lié au serveur d’intégration continue et peut être obtenu sur n’importe quel poste de développement. La même construction donnera donc le même résultat, ce qui est la moindre des choses ! Le Listing 13.2 montre l’utilisation du plugin buildnumber pour obtenir ce numéro de révision et l’exploiter sous forme de variable Maven. À noter qu’il est déclenché dans la phase prepare-package disponible dans Maven 2.1 et versions ultérieures.

Décidé à ne pas se faire avoir deux fois, Lukas met en place cette solution et fait produire par notre serveur d’intégration continue des binaires portant systématiquement l’indication de révision SVN dans le nom du fichier. Il est cependant rapidement ramené à la dure réalité lorsqu’il constate que la dernière version disponible de l’EAR dans notre gestionnaire de bibliothèque s’appelle… noubliepaslalistedescourses-1.2.0-SNAPSHOT.ear – oups !

Nous avons jusqu’ici cherché à modifier le nom du fichier produit par Maven. C’est oublier que la phase de déploiement dans notre dépôt de bibliothèques n’en tient pas compte : le binaire qui est déployé respecte scrupuleusement les indications d’artifactId et de version ! Malgré nos efforts, et même si le répertoire target contient bien finalement un fichier noubliepaslalistedescourses-1.2.0-SNAPSHOT-rev-4704.ear, le fichier que nous retrouvons dans notre dépôt ne possède plus ce complément d’information.

En fait, nous avons aussi cherché à réinventer la poudre. Le format d’archive Java (JAR, WAR ou EAR) n’est pas juste une extension maison pour une compression de type ZIP. Ce format définit aussi un mécanisme de métadonnées via le répertoire spécialisé META-INF, et en particulier le descripteur MANIFEST.MF.

Ce fichier n’est rien d’autre qu’un fichier texte, dont le formalisme est un peu déroutant parfois, mais qui ressemble globalement aux fichiers de propriétés que vous manipulez déjà certainement. Pour une clé donnée, on associera une valeur, par exemple pour la clé build le numéro de construction de notre serveur d’intégration continue.

Comment compléter ce fichier MANIFEST ? La construction de nos projets par Maven en produit naturellement un, avec des informations minimalistes. Il suffit de demander aux plugins jar, war ou ear d’ajouter d’autres informations. Le Listing 13.3 montre la configuration mise en place par Lukas pour aboutir à une solution enfin satisfaisante et pleinement reproductible. Notez aussi l’utilisation d’un profil dédié à l’intégration continue qui permet de compléter ces métadonnées, lorsque des informations complémentaires sont disponibles, et de ne pas perturber le fonctionnement de Maven sur les postes de développement (le plugin buildnumber ^[44] n’est pas très performant).

Avec cette configuration, chacun de nos binaires portera désormais les informations complètes de ses origines. En cas de besoin, il nous suffira de les exploiter pour retrouver rapidement le code source associé, et éventuellement les traces de sa construction dans notre serveur d’intégration continue.

La production réclame une archive Unix tar.gz répondant à une structure très précise :

Nous avons déjà vu un joli panel de plugins qui nous ont bien aidés dans notre travail ; nous allons faire appel au plugin assembly, l’un de leurs petits frères. Ce plugin va exploiter un fichier XML qui décrit le livrable à assembler. Dans ce fichier, nous indiquerons les constituants de notre archive.

Le fichier assembly comptera trois parties, correspondant aux trois constituants clés de notre archive cible. Ce fichier est structuré par un schéma XML qui nous aidera à éviter les erreurs de syntaxe. L’en-tête du fichier indique le format d’archive à produire : une archive TAR compressée GZip. Nous pourrions aussi bien produire une archive ZIP ou un TAR non compressé.

La suite du fichier indique au plugin assembly les éléments du projet à ajouter dans l’archive. La première partie va piocher dans notre projet multimodule (voir le Chapitre 7) celui qui produit l’archive EAR. Nous pourrions le désarchiver ou le faire accompagner de ses dépendances. La deuxième va inclure une liste de fichiers identifiés dans un répertoire prédéfini. La dernière va parcourir tous les modules du projet et en extraire le code source. Le Listing 13.5 montre ce fichier magique qui nous fera franchir la dernière ligne droite avant une production 100 % automatisée de notre livrable.

Le format de ce fichier utilise un schéma XML qui nous assistera dans sa saisie et qui est largement documenté sur le site web du plugin ^[46].

Pour produire notre livrable tant désiré, il nous suffit de lancer la commande mvn assembly:assembly. Nous l’avons déjà vu, cette syntaxe correspond à l’invocation d’une tâche spécifique d’un plugin et non d’une phase de construction du projet. Cependant, ce plugin va provoquer l’exécution de la phase package du projet (et de tous ses modules). C’est au cours de cette exécution qu’il découvrira les constituants de chaque projet et identifiera les répertoires de code source (y compris le code généré) et les binaires produits.

Notre serveur d’intégration continue produit déjà, à intervalles réguliers, nos binaires, prêts à être testés au-delà de ce que nos tests automatisés savent contrôler. Il serait dommage de ne pas lui demander de produire aussi notre livrable, ne serait-ce que pour nous donner un moyen de vérifier le respect de son format.

L’idée paraît bonne, mais quelle cible Maven invoquer ? Devons-nous remplacer le mvn install par le fameux assembly:assembly. Nous voudrions que la production de ce tar.gz soit mieux intégrée dans la construction du projet, qu’elle soit le résultat de sa construction par défaut.

Le plugin assembly a la bonne idée de proposer une autre tâche, laquelle est prévue pour s’exécuter au sein d’un cycle de construction du projet. À la différence du assembly:assembly, nous pouvons associer assembly:single à une phase du projet, et il sera invoqué automatiquement lors de sa construction. Le Listing 13.6 indique la configuration que nous appliquons.

Solution miracle ? Eh bien non, échec cuisant. Le plugin assembly plante lamentablement en indiquant qu’il ne trouve pas notre EAR :'(.

Quel est le problème ? Il nous faut comprendre un peu mieux les rouages de Maven pour expliquer cet échec : nous avons mis en place l’héritage naturel sur le projet, c’est-à-dire que le même fichier POM sert à déclarer nos modules et de parent commun pour mutualiser la configuration et les dépendances. Cette solution, bien pratique, est largement appliquée, mais pose ici un problème :

Ces deux contraintes contradictoires sont une voie sans issue. Pour contourner cette impasse, nous utilisons une astuce qui ressemble plus à un hack qu’à une vraie solution, mais qui va bien nous dépanner.

Nous créons à côté de notre fichier racine pom.xml un second fichier POM : pom-assembly.xml. Dans ce nouveau descripteur Maven, nous plaçons la configuration du plugin assembly, ainsi que la déclaration d’un unique module qui pointe vers le pom initial. Le Listing 13.7 montre ce nouveau fichier, particulièrement simple comparé au volume de XML que Maven peut parfois nous demander de saisir.

En lançant Maven avec l’option -f, nous pouvons indiquer le fichier POM à utiliser comme base de la construction du projet. mvn assembly:assembly -f pom-assembly.xml va donc provoquer la construction de ce POM minimaliste, l’exécution du plugin assembly, qui va, à son tour, provoquer la phase package sur l’ensemble des modules du projet.

Nous venons de résoudre le problème de l’œuf et de la poule !

Dans un monde parfait, cette solution serait optimale : une seule source, un développement profitant de l’attention de tous pour un meilleur résultat. C’est ce qu’essaie de faire la fondation Apache pour ses propres projets en partageant un POM parent (relativement simple) avec des informations communes comme la licence, les dépôts, les listes de discussion. Elle fait de même pour le code à travers le projet commons.apache.org. Le résultat est encourageant sans être prodigieux.

Dans un monde d’entreprise, cette solution est surtout source de conflits : qui assure la maintenance des composants communs ? Qui décide des évolutions de ce composant ? Sur quel budget ? Qui supporte les tests de non-régression lorsqu’un composant mutualisé évolue, alors que le projet qui l’utilise n’a aucune évolution en cours qui pourrait (discrètement) en absorber le coût ? Sauf à avoir une volonté officielle et financée de supporter cette mutualisation, c’est malheureusement une voie sans issue qui va surtout épuiser la bonne volonté des premiers contributeurs de ces composants communs.

Nous avons déjà évoqué l’utilisation d’un POM d’entreprise, dans lequel sont placées toutes les déclarations propres à l’infrastructure et aux règles de l’entreprise. On va pouvoir y référencer le serveur d’intégration continue, le gestionnaire de dépôt utilisé pour publier les artefacts. Il permet aussi de préconfigurer quelques plugins en fonction de nos règles de développement. Les plugins liés aux outils de contrôle qualité comme Checkstyle, PMD ou FindBugs, peuvent ainsi être associés aux règles dont les développeurs ont assimilé l’intérêt. Le Listing 14.1 montre le POM parent que nous proposons pour Geegol.

Ce POM commun simplifie un peu la définition des projets développés au sein de l’entreprise, mais ne fait qu’effleurer la question. Commencer un projet sur cette seule base ne va pas aider beaucoup l’équipe de développement pour un démarrage sur les chapeaux de roue.

Autre option, qui vient à l’esprit de tout le monde : le bon vieux copier-coller. La copie est une opération de base en informatique, peut-être la plus utilisée mais aussi la plus dénigrée par les architectes : dans une copie, il y a toujours un élément de trop !

Selon cette approche, Raphaël commence par reproduire la structure de base de notre projet et par copier nos fichiers POM ainsi que nos classes techniques, qui pourront donner de bonnes pistes pour la réalisation. Rapidement, le travail devient titanesque car il faut adapter ces copies : noms de package, groupId, artifactId et versions ne correspondent pas. Le risque d’erreurs est grand, et obtenir un résultat stable et complet va prendre du temps !

Pour nous convaincre, il nous fait rapidement une démonstration. Il se propose ainsi de lancer un projet de plugin Maven, faisant ainsi référence au travail que nous avons dû accomplir au Chapitre 11. Nous avons tous en mémoire le temps qu’il nous a fallu pour cela. Raphaël tape donc une commande dans sa console :

Maven propose alors une liste impressionnante de composants, parmi lesquels Raphaël identifie un archétype mojo-archetype, qu’il sélectionne. Maven lui demande de choisir pour son nouveau projet un groupId, un artifactId et une version. Après quelques traces peu compréhensibles dans la console, Raphaël nous lâche un majestueux « et voilà ». Le Listing 14.2 montre l’exécution de cette commande. Nous avons limité la liste des archétypes proposée pour ne pas occuper deux pages supplémentaires. Le Listing 14.3 montre la structure de fichiers régénérée.

Pardon ? Tu rigoles ? Avec un petit sourire, Raphaël propose de compiler son plugin et de l’exécuter. Un mvn install dans le répertoire nouvellement apparu, puis un mvn com.geegol.maven.plugins:demo-maven-plugin:1.0-SNAPSHOT:echo et nous pouvons voir apparaître dans la console le résultat simple mais tout de même inespéré :

Hello World from Maven !

C’est sûr que ce plugin n’est pas très impressionnant pour ce qu’il fait, mais tout de même il ne nous aura pas coûté beaucoup d’efforts et est totalement fonctionnel. Raphaël enchaîne donc avec l’explication.

Un archétype est la façon à la Maven de faire de la mutualisation, avec un bonus considérable : son utilisateur peut, par la suite, faire évoluer le code comme bon lui semble, voire ne toucher à rien pendant des années s’il n’en voit pas l’intérêt. Il peut proposer des évolutions de l’archétype s’il a de bonnes idées ou des corrections à apporter, mais son code ne sera jamais impacté sans son accord.

Contrairement à une dépendance, pour laquelle on récupère le résultat final binaire, un archétype fournit du code source, sur la base d’un modèle. Noms de packages, chemins et métadonnées Maven sont adaptés au projet utilisateur. Le modèle lui-même est géré comme un projet Maven à part entière, dispose d’une version et peut être enrichi par ceux qui ont du temps (et du budget) pour s’en occuper. Les équipes peuvent proposer de reporter dans le modèle soit des corrections qu’elles ont faites pour éviter à d’autres de tomber dans les mêmes embûches, soit des enrichissements pour capitaliser sur le travail réalisé.

La structure d’un archétype n’est pas très attirante a priori. Il s’agit d’un projet Maven comprenant un nième descripteur XML et une série de fichiers modèles sous forme de ressources. Le projet qui va en découler ne sera donc pas très facilement accessible, et l’édition d’un tel format pas très simple.

Sauf si l’on consulte la description du plugin archetype, et en particulier sa tâche create-from-project. Comme son nom le suggère, celle-ci propose de construire un archétype à partir d’un projet normal, pas nécessairement conçu pour servir d’archétype. En quelque sorte, il s’agit d’une rétro-ingénierie qui va extraire un modèle à partir d’une implémentation concrète.

La version 1.2.6 de « noubliepaslalistedescourses » est particulièrement réussie. Après cinq versions correctives, le code est très stable, et nous sommes très confiants sur la bonne intégration de tous les outils mis en œuvre. Pour construire un archétype sur cette base, il nous suffit de partir de son code source et de lancer la commande magique. Celle-ci va identifier dans tous nos fichiers de configuration et nos sources l’utilisation du nom de package fr.noubliepaslalistedescourses et assembler un archétype basé sur tous nos fichiers déspécialisés du nom de notre projet.

L’archétype est prêt en quelques minutes dans le répertoire target/generated-sources/archetype (il est sous sa forme de projet Maven ; il nous suffit de lancer, depuis cet emplacement, un très classique mvn install pour le convertir en binaire utilisable) !

Raphaël n’a plus qu’à lancer la commande complémentaire : mvn archetype:generate, en précisant l’argument -Dcatalog=local signalant qu’il veut utiliser ses propres archétypes, présents sur son poste de développement, et pas ceux mis à disposition par la communauté Maven. Quelques instants plus tard, le projet « malistedecadeauxpournoel » est prêt pour être enregistré dans son propre gestionnaire de sources Subversion, avec un code fonctionnel qu’il ne restera plus qu’à adapter aux besoins spécifiques du nouveau projet.

Le mécanisme extrêmement simple qui permet de créer un archétype encourage une pratique simple : développer un projet de référence, une application blanche, dans laquelle nous mettrons en place toute notre expertise. Cette application utilisera une sélection de frameworks correspondant à l’état de l’art, avec une préconfiguration claire et largement documentée.

Vous avez probablement déjà vu ces fichiers de propriétés suffixés -sample qui contiennent nettement plus de commentaires explicatifs que de valeurs de configuration. Pour notre application blanche, nous mettons un point d’honneur à ce que chaque fichier de configuration, classe ou POM présente une explication détaillée de ce qu’il réalise, pourquoi et comment. Nous accompagnons chaque framework d’une classe d’exemple, qui sert de point de départ à tout développeur novice qui le connaîtrait mal, afin de le mettre sur la bonne piste. Le développement se faisant beaucoup par imitation, les premières lignes de code disponibles sur le projet sont capitales.

Utilisée comme archétype, notre application blanche met à la disposition des projets à venir un ensemble cohérent, finement outillé et documenté, qui pourra être, par la suite, adapté à des besoins spécifiques, mais à partir d’une base validée.

Étant elle-même un projet Maven à part entière, notre application blanche peut bénéficier de l’outillage d’intégration continue pour valider son niveau de qualité et sa stabilité. Son développement et son évolution sont donc assez simples. Si un projet qui l’a utilisée comme archétype a expérimenté avec succès une nouvelle technologie, il lui suffit de proposer l’évolution associée. Notre outillage de contrôle qualité faisant le reste pour assurer la cohérence de l’ensemble.

Sébastien passe nous voir, en espérant cette fois ne pas nous trouver au milieu d’une bataille de chiffonniers (voir le Chapitre 9). Il vient nous demander conseil pour lancer une petite application expérimentale. Il ne veut pas s’embarquer dans une étude d’architecture pour si peu, mais simplement partir sur les bons outils du moment, si possible avec quelques pistes pour ne pas perdre de temps. Voilà qui ne pouvait pas mieux tomber ! Notre application blanche est encore à l’état d’ébauche, et nous y avons transféré quelques morceaux choisis de « noubliepaslalistedescourses », en constatant au passage que nous aurions pu faire un petit effort en termes de commentaires pour rendre ses aspects techniques plus compréhensibles.

Un rapide archetype:create-from-projet suivi de son petit frère archetype:generate et Sébastien peut repartir avec un socle encore très imparfait, mais déjà bien plus avancé et intégré que ce qu’il aurait pu obtenir en accumulant les conseils et fragments de code piochés à droite à gauche.

Dernier élément, un tel projet peut être fédérateur au sein de l’entreprise, en démontrant un savoir-faire et en servant de point d’échange sur les technologies.

Au démarrage de notre projet, s’est posée la question du choix d’un framework web. Dans cette situation, chacun tente d’imposer son champion, d’abord en mettant en avant ses points forts, puis en dénigrant les concurrents lorsque les arguments commencent à manquer, et finalement par une petite guerre d’influence et de désinformation :

JSF c’est naze,

GWT c’est super lourd,

Struts 2 c’est _has been.

Bref, rien de vraiment constructif.

Pourquoi ne pas proposer dans l’application blanche trois versions de la couche web (sous forme de modules Maven dédiés) ? Sur un exemple de base, nous pouvons demander à chaque framework de démontrer sa plus-value et sa force.

Nous mettons en concurrence de manière constructive nos trois experts, qui fourniront ainsi ce qu’ils considèrent comme l’état de l’art de leur technologie préférée, accompagné des meilleurs exemples pour bien démarrer. Plutôt qu’une querelle de spécialistes qui n’aboutirait à rien de positif, nous pourrons ainsi proposer à chaque nouveau projet de faire son propre choix, en fonction des personnes disponibles, de leurs compétences, des exigences du projet, etc.

Lorsque François revient nous voir pour nous féliciter du succès de « noubliepaslalistedescourses », il ne peut s’empêcher de nous taquiner en ayant l’air surpris de notre réussite alors que nous n’avons pas expérimenté plus avant la solution Flex, dont il est convaincu de la supériorité. Si nous n’avons pas choisi cette voie aujourd’hui, d’autres le feront peut-être sur une autre application, et les quelques lignes d’exemple de François intégrées dans notre application blanche seront déjà un meilleur début qu’une page blanche.

L’application blanche peut ainsi servir de support pour expérimenter une technologie directement dans le contexte de nos méthodes de travail. Faire fonctionner une application Flex, c’est très bien et sans doute facile avec le bon outillage. Réussir à en développer une en bonne entente avec le reste de nos outils est une autre paire de manches. Comment construire l’application avec le même outillage et les mêmes commandes ? Comment intégrer cette technologie avec notre infrastructure métier basée sur Spring ? L’application blanche met dès le début ces questions sur le tapis, y répondre au plus tôt permettra d’introduire Flex sur un nouveau projet sans buter sur ces problèmes.

Pour ceux qui n’ont aucune préférence, l’application blanche lancée en mode démonstration permet de se faire une idée du résultat obtenu pour un code source donné, et donc de discuter sur un exemple concret pour prendre une décision raisonnée.

Elle peut également servir de support de formation.

Jérôme veut démarrer un projet fondé sur Struts 2 et Spring, et former dans le même temps les développeurs novices à ces technologies. Pour les sessions de formation qu’il va animer, il pourrait partir des projets d’exemple qui accompagnent ces deux frameworks et donner les pistes pour que chacun fasse le lien avec l’application à développer. Après tout, ces exemples sont conçus pour cela et en principe taillés pour mettre en valeur les bonnes pratiques. Cependant, ils ne collent pas exactement à la réalité de l’application et des nombreux outils qu’elle intègre. Spring propose par exemple de nombreux mécanismes de configuration, alors que nous n’en exploitons qu’un seul – le but n’est pas de former des experts en Spring, mais des développeurs confiants et guidés dans leur travail.

Jérôme préfère donc partir de notre application blanche, y ajouter la configuration et une sélection d’exemples adéquats. Il crée ensuite un archétype.

Chaque junior qui participe à la formation va alors générer, à partir de l’archétype, sa propre application de démonstration/expérimentation et se lancer dans ses premières lignes de code sur cette base. Les classes de l’application blanche donneront l’assise de nos exercices de formation, et les exemples permettront d’expliquer les mécanismes en jeu.

Au terme de la formation, lorsqu’ils commenceront à travailler sur le projet, nos développeurs tout juste formés ne seront pas déboussolés de retrouver la même structure de projet et gagneront ainsi en efficacité.

Il y a une critique, en particulier, qui vous a probablement déjà titillé : la syntaxe XML inutilement verbeuse. L’intégration dans les IDE tend à gommer ce détail, mais il est néanmoins bien présent dès qu’on s’attaque à configurer un gros plugin comme Cargo (voir Chapitre 8).

Qu’est-ce qui empêche de modifier ce format POM pour le rendre plus compact, ou lui ajouter des fonctionnalités ? Le code qui analyse ces fichiers XML est actuellement lié à une version de Maven. Si un nouveau Maven sortait avec un format POM plus souple ou intégrant une nouvelle fonctionnalité, il ne serait exploitable que par les utilisateurs de cette nouvelle version de Maven. Au sein d’une équipe de développement, cela ne serait pas un gros problème ; la difficulté concerne les POM déployés par des projets dans un dépôt d’artefacts, en particulier les projets open source qui déploient sur central. Leur utilisation ne serait alors possible que pour les utilisateurs du nouveau Maven. Une prise en otage inacceptable !

Une deuxième limite de Maven concerne son fonctionnement en mode multimodule, en particulier lorsqu’on exploite l’héritage naturel : la construction du projet POM parent doit se terminer avant que celle de ses modules ne commence, afin qu’ils puissent y faire référence. Il n’est donc pas possible d’intégrer dans notre projet parent un plugin qui s’exécuterait après la construction des modules. Ce problème, Stéphane l’a rencontré et contourné au Chapitre 13. Il peut sembler anecdotique, mais sa correction complète nécessite une refonte assez profonde de Maven et de sa gestion du cycle de vie.

Un autre souci concerne les expressions, qui permettent de mutualiser des numéros de version comme dans l’exemple ci-après :

En utilisant systématiquement cette propriété, nous pouvons être sûrs que toutes nos références aux différents modules de spring utilisent une même version cohérente, c’est donc bien pratique. Cependant, la propriété spring.version peut être déclarée ailleurs dans le POM, mais aussi dans son parent, dans un profil, dans le fichier settings de l’utilisateur ou via la ligne de commande. Si elle est déployée telle quelle, comment pouvons-nous être sûrs qu’elle sera interprétée à l’identique dans un contexte très différent ? En tant que responsable de notre livrable, Emmanuel a dû se battre contre les comportements qui dépendent de l’environnement. Une construction de projet fiable doit être totalement reproductible.

La liste est encore longue des fonctionnalités manquantes, mal fichues, des bogues et autres anomalies, et peu sont simples à traiter…

Sortons des limites liées au fonctionnement propre de Maven et intéressons-nous à la norme OSGi qui connaît un intérêt croissant. Celle-ci accompagne une archive Java (un bundle en terminologie OSGi) de métadonnées dans un format propre, mais qui ressemblent beaucoup aux concepts de dépendances de Maven.

Comment éviter de dupliquer l’information ou, du moins, comment assurer la cohérence entre ces deux mondes ? Même constat pour la norme Java modules qui fait l’objet d’une JSR et devrait être intégrée à Java 7 (JSR-277). Comment Maven gérera-t-il ces nouveaux formats qui viennent marcher sur les plates-bandes de la gestion des dépendances, en particulier le standard OSGi dont l’ordre de résolution des conflits n’est pas exactement équivalent ?

Olivier signale également la difficulté pour identifier un plugin qui réponde à un besoin précis et pour en qualifier la pérennité. Or, Maven ne vit que par ses nombreux plugins. Les besoins précis sont soit une intégration d’une nouvelle technologie dans le build (comme GWT), soit une optimisation du build propre à un projet (comme compiler, déployer sur un serveur Tomcat tout en modifiant sa configuration…).

Le projet Apache Maven n’héberge officiellement qu’un nombre réduit de ces plugins, utilisés pour sa propre construction ou pour des besoins fondamentaux du développement Java. Il s’ensuit que les plugins, qui sont finalement l’élément principal manipulé par l’utilisateur final, sont plus ou moins laissés dans la nature, attendant le bon vouloir d’une communauté hétéroclite. Le projet Mojo encourage un regroupement visant à donner à ces plugins un cadre et une culture communautaire, mais le développement reste peu structuré et dépend du temps libre ou des intérêts des développeurs impliqués. De nombreux plugins peuvent ainsi rester des années dans le bac à sable, zone de test permettant de faire naître de nouvelles idées, sans passer à un état stable qui leur donnerait une plus grande crédibilité.

Par ailleurs, de nombreux développeurs peuvent être tentés de créer leur propre plugin en dehors de la communauté officielle Maven, et les héberger sur SourceForge, GoogleCode ou en interne dans leur entreprise. Ces efforts non coordonnés peuvent encourager une certaine créativité, mais laissent surtout passer l’occasion de construire une solution plus viable avec un accueil plus large par la communauté des utilisateurs.

De manière plus générale, l’utilisateur qui ne trouve le plugin adéquat pour un besoin donné ni dans ceux de Maven, ni sur la liste des plugins stables de Mojo, est confronté à un choix délicat :

L’utilisation de Maven est simple si on suit ses conventions et qu’on dispose des bons plugins ; elle peut devenir assez vite délicate, si on n’a pas les bons réflexes, voire totalement insurmontable, si on tente de plier Maven à des utilisations pour lesquelles il n’a pas été prévu. Le support est donc un élément clé de son utilisation, et Vincent ne manque pas de le souligner (la question allait venir d’elle-même de toute façon). Il ne fait aucun doute que vous y aurez recours à un moment ou un autre même en ayant lu avec attention les pages de ce livre.

Le support de Maven est centralisé sur une liste de diffusion (users@maven.apache.org) qui réunit ses utilisateurs et une majorité de ses développeurs. Les messages y sont nombreux, touchent tous les sujets, et les réponses viennent rapidement en raison du grand nombre d’utilisateurs en ligne. Il n’y a cependant aucune obligation de résultat et aucun moyen d’accentuer l’appel au secours, sauf à relancer sa question au risque de se faire rejeter plutôt qu’aider par les membres bénévoles.

Si vous faites appel à la communauté, pensez à poser des questions précises en détaillant clairement votre besoin, votre environnement (vous pouvez toujours lire ce petit guide ^[48], et n’hésitez pas à répondre aux autres utilisateurs : nous avons tous commencé de cette façon et c’est ainsi qu’on apprend le mieux à utiliser Maven. La liste des utilisateurs de Maven a dépassé la taille critique et s’autoalimente : les utilisateurs avertis aident les novices. L’équipe des développeurs n’a plus besoin d’assurer elle-même le support de premier niveau et peut donc se concentrer sur les développements et les corrections.

Vous pouvez aussi retrouver une partie des développeurs du projet ainsi que des utilisateurs sur l’IRC ^[49] (serveur irc.codehaus.org, canal : #maven). Ce média a l’avantage d’être en direct et peut donc vous apporter des réponses plus rapidement que la liste de diffusion, si vous avez la chance de tomber sur les bons interlocuteurs. Par contre, contrairement à cette dernière, comme il n’est pas possible d’accéder aux discussions qui ont eu lieu pendant une déconnexion, n’espérez pas qu’une personne vous réponde si elle n’était pas là au moment où vous avez posé votre question. Enfin, n’oubliez pas qu’il y a beaucoup de personnes dans l’équipe Maven qui ne sont pas sur le même fuseau horaire que nous. N’espérez pas contacter les membres outre-Atlantique le matin heure française.

Seule contrainte : tous ces échanges se font en anglais, parfois avec une syntaxe qui doit désespérer ceux dont c’est la langue maternelle. Heureusement, les francophones sont réputés pour leur compétence en langues étrangères ;). Si, malgré tout, ce n’est pas votre cas, le site developpez.com héberge un forum francophone consacré à Maven ^[50], ainsi qu’une FAQ ^[51] bien remplie.

Hervé rebondit sur la question du support en évoquant le prix de revient de Maven sur un projet. Maven est un projet libre, téléchargeable et utilisable gratuitement. Son coût d’utilisation n’est cependant pas nul, comme tout projet open source. Le simple fait que vous ayez ce livre entre les mains est déjà un élément de réponse : il n’est pas si facile à utiliser et nécessite un certain apprentissage. Il ne s’applique pas à n’importe quel projet et sans un certain effort d’organisation. Il nécessite donc un minimum d’expérience. Les sociétés de services ne s’y sont d’ailleurs pas trompées et vendent consultants et formations autour de ce sujet.

Comme de nombreux outils, Maven coûte bien plus cher par la formation qu’il induit que par son prix d’achat (qui est particulièrement attrayant dans le cas d’un projet libre). Sa documentation en ligne est perfectible, mais elle est épaulée par de nombreuses autres sources. Ce livre fait partie de cet effort et vient compléter les livres Better Builds with Maven ^[52] et Maven – the definitive guide, bible de 500 pages qui présente tous les aspects de Maven, sans compter les innombrables blogs, articles, forums et tutoriels qui décrivent des points plus spécifiques de son utilisation.

Nous avons tenté au cours des chapitres précédents de vous démontrer en quoi l’approche proposée par Maven est d’un niveau supérieur au simple script de construction de projet. Il faut cependant admettre que Maven n’est pas bon partout et mal adapté à certains projets.

Maven part du principe que 99 % des projets ont des besoins comparables et peuvent s’appuyer sur les mêmes outils et bonnes pratiques s’ils acceptent des conventions communes. Il reste cependant 1 % de projets qui ont des besoins vraiment très spécifiques – tout le monde dira que son projet est différent des autres, mais soyons honnêtes, à part quelques cas extrêmes, nous faisons tous plus ou moins la même chose. Nous pourrions comparer la standardisation de la construction à celle du démarrage : qui de nous a besoin d’une JVM customisée avec 12 paramètres en "-XX:" pour lancer son application ?

Google Web Toolkit rentre dans les projets « spécifiques ». La compilation des sources doit marier du code natif pour Windows, Linux et mac OS, l’inclusion de code source Java dans l’archive JAR, et bien d’autres subtilités. Construire un tel projet avec Maven serait possible, mais il faudrait alors considérer la plus-value qu’il apporterait aux développeurs. Le mécanisme de test de ce projet est ultraspécifique, les artefacts construits – si, finalement, ils sont des archives JAR – sont composés d’éléments peu courants. La configuration nécessaire dans Maven pour obtenir un résultat convaincant serait significative. Ce projet ne rentre pas dans le cadre des 99 %.

Spring 2 a lui aussi choisi de ne pas utiliser Maven pour sa construction. Pour ce projet devant mixer la compilation de classes destinées à Java 1.4 et Java 5, en plus de divers raffinements dont la compatibilité OSGi, il faut bien reconnaître que Maven se serait assez mal prêté au jeu.

Enfin, d’autres projets de développement basés sur des outils propriétaires ou non (pensons à Liferay ou Alfresco) imposent généralement leurs propres scripts de compilation et donc ces types de projets rentrent, là encore, dans le 1 %.

Maintenant, nous ne sommes pas nombreux à travailler sur des projets aussi particuliers. Cela n’interdit pas de regarder ce qui se fait ailleurs pour déterminer si Maven est le meilleur choix. Il est intéressant de noter que Spring 3 sépare ses packages principaux en modules dédiés et intègre même un fichier POM expérimental ^[53].

This POM cannot be used to build Spring; it is a work in progress and should only be used as part of a Maven repository upload bundle using artifacts created by the spring build system.

Comme quoi, l’idée fait tout de même son chemin…

Nous avons déjà parlé d’Apache Ant, qui a été longtemps le standard de fait pour la construction de projets en Java. Ivy est un projet qui lui apporte une gestion des dépendances très proche de ce que Maven propose – Ivy sait d’ailleurs exploiter les POM de Maven et ses dépôts de bibliothèques. Le couple Ant + Ivy permet donc de faire globalement la même chose que Maven pour ce qui est de la gestion des bibliothèques.

Par contre, cela n’apporte rien en termes d’homogénéité des projets, de conventions d’organisation du code ou de réutilisation des scripts Ant. Ivy apporte à Ant une fonctionnalité clé de Maven, mais ne change en rien sa philosophie générale. La comparaison entre Ant et Maven ne doit pas se faire en comptant le nombre de lignes de XML nécessaires pour compiler des classes, mais en fonction de l’esprit général de l’outil et de ce qu’il apporte ou impose sur un projet.

On peut faire le choix d’Ant, de la liberté qu’apporte un langage de script pour faire à peu près tout ce qu’on veut. Il ne faudra alors pas s’étonner que cette liberté ait un prix en maintenance et en évolutivité du projet.

EasyAnt ^[54], comme son nom le suggère, vise à simplifier l’utilisation d’Ant. Il propose une surcouche qui intègre Ivy et un certain nombre de conventions, permettant de passer des commandes de construction sans avoir à établir une configuration répétitive d’un projet à l’autre. Un mécanisme de plugins permet de préparer des fragments de script Ant pour être partagés entre projets.

L’approche est intéressante dans le sens où elle rejoint le constat qui est à l’origine de Maven : des projets comparables doivent sans cesse réécrire la même configuration, alors qu’ils vont dérouler globalement les mêmes procédures. EasyAnt n’est cependant pas aussi easy qu’il le prétend si l’on considère qu’il exploite les namespace dans un langage de script XML, ce qui n’est pas d’une grande lisibilité pour le développeur novice. De ce point de vue, Gradle est nettement plus innovant.

Depuis des mois déjà, Grégory nous interpelle sur notre projet en dénonçant la lourdeur du fichier XML de notre outil de build et son manque de flexibilité. Lui voudrait bien imposer Gradle, son outil de prédilection.

Gradle ^[55] s’appuie lui aussi sur Ant et Ivy, et met en place un esprit de construction par conventions. Basé sur Groovy plutôt que XML, un script Gradle manipule des tâches Ant traditionnelles qui sont ses briques de base. Groovy est mis à contribution pour créer un Domain Specific Language (DSL), un langage de programmation dédié à une tâche particulière : la construction de projet. L’intégration d’Ivy dans Gradle se fait via ce DSL plutôt que par les tâches Ant Ivy, ce qui simplifie sa manipulation.

Gradle définit également la notion de plugin, plus ou moins comparable avec la signification de ce terme dans Maven. Un plugin Gradle est plutôt un ensemble de conventions, tâches et extensions Gradle réunies et réutilisables sur plusieurs projets.

Le Listing 15.1 donne un exemple de script Gradle que nous présente Grégory pour la mise en place d’un projet Java. La syntaxe est particulièrement compacte.

Nous ne rentrerons pas plus en détail dans Gradle, dont la documentation en ligne ^[56] est très complète si cette alternative vous intéresse. Gradle reprend beaucoup d’éléments de Maven en termes de conventions plutôt que configuration, cycle de vie, approvisionnement à partir de dépôts, plugins… Par contre, Gradle réhabilite en même temps le concept de scripting, permettant d’embarquer des tâches spécifiques dans le build. Par ailleurs, Gradle est un outil encore très jeune et disposant de peu de plugins (comparé à l’écosystème Maven ou Ant), aussi l’écriture de scripts est quasiment nécessaire pour en tirer quelque chose.

En tant qu’anciens de la communauté Maven, autant EasyAnt que Gradle nous rappellent énormément une vieille connaissance : Maven 1.

Maven 1 avait pour objectif de fournir au-dessus d’Ant une gestion de dépendances (Ivy n’existant alors pas encore) et une approche par conventions. Il utilisait des fichiers de script XML basés sur Ant et sur un langage de programmation XML (jelly). Les tâches les plus courantes étaient regroupées dans des plugins, qu’on pouvait importer et invoquer dans les projets.

Maven 1 a eu ses heures de succès en démontrant les apports de la standardisation, puis a montré ses limites quand les scripts des plugins ont commencé à se complexifier pour éviter des effets de bord et des interactions mutuelles. Ce demi-échec a été à l’origine de Maven 2, construit sur un modèle nettement plus robuste.

Le concept mis en œuvre dans EasyAnt nous semble ainsi obsolète, car nous avons déjà exploré cette voie et rencontré des obstacles bien délicats à franchir.

Notre avis concernant Gradle est plus ambigu ; construit sur des outils modernes, avec une syntaxe claire et compacte, il partage avec Maven certains concepts forts. La syntaxe de Gradle est compacte, claire et très spécialisée grâce à Groovy et à sa capacité naturelle à construire des DSL. Grégory nous promet monts et merveilles, nous démontre l’extrême richesse du DSL Gradle à travers quelques exemples bien choisis, pour lesquels l’outil est effectivement nettement moins verbeux que Maven, mais n’arrive pas à nous convaincre.

En ouvrant la boite de pandore du langage de script, même avec un fonctionnement « par défaut » proche de ce que propose Maven, Gradle vous tend la perche pour accumuler les astuces et autres bizarreries qui font de votre projet une usine à gaz, rien que pour produire le livrable. Dans le même esprit, Maven propose depuis ses début un plugin permettant d’exécuter des tâches Ant ou Groovy, mais ces « astuces » ne sont considérées que comme un pis-aller pour faciliter une migration rapide vers Maven le temps de trouver une solution plus propre.

Apache aime bien développer des outils de build ! En plus de Maven et d’Ant, il existe aussi le projet Buildr ^[57], se positionnant dans l’organisation des projets comme Maven. Il utilise le langage Ruby au lieu du XML, les conventions de Maven et s’intègre avec Ant et les dépôts Maven.

Nous ne détaillerons pas ce dernier candidat, sachant que nous en avons laissé d’autres en retrait, nombreux, qui se proclament tous aussi révolutionnaires et intuitifs les uns que les autres. Rappelons simplement l’un des reproches le plus souvent faits à Maven : l’absence d’une bonne intégration sous Eclipse. Si on considère les autres solutions, l’intégration est quasi inexistante ou limitée au lancement des tâches de construction. Reste comme seul argument la syntaxe XML du fichier POM, argument parfaitement recevable, mais qui est un peu court pour sélectionner un outil aussi important pour un projet.

Arnaud poursuit le travail d’évangélisation en démontrant que nous ne sommes pas de dangereux geeks qui ont misé sur un outil qui finira aux oubliettes dès que la mode sera passée.

Maven ne vit qu’au travers de la communauté de ses utilisateurs, qui assurent l’essentiel du support de l’outil. Les développeurs ne sont plus eux-mêmes mis systématiquement à contribution vu la très large base d’utilisateurs avancés qui participent activement aux discussions en ligne. La Figure 15-01 présente le nombre d’utilisateurs de la liste users@maven.apache.org ainsi que le nombre de messages par jour. Cette liste est très active et répond aux nombreuses questions de toute nature que les utilisateurs de tous niveaux formulent, parfois dans un anglais assez approximatif (c’est un moyen simple pour reconnaître des collègues francophones).

Trafic de la liste users@maven.apache.org – en rouge le nombre de messages et en bleu le nombre d’inscrits.

Autre indicateur, le trafic sur le site web maven.apache.org. Les Figures 15-02 et 15-03 affichent le compte rendu des visites pendant un mois, ce qui donne une bonne idée du nombre d’utilisateurs de Maven amenés à configurer leurs plugins (le site web étant la principale source d’information sur cet aspect). La Figure 15-04 indique le nombre de téléchargements de Maven au cours de l’année, toutes versions confondues. Ici encore, les chiffres démontrent une très large communauté.

Origine géographique des visiteurs de maven.apache.org.

Trafic sur le site web maven.apache.org.

Téléchargements mensuels de Maven sur un an, toutes versions confondues.

Si vous choisissez Maven, vous ne serez donc pas tout seul et vous trouverez rapidement des collègues utilisant le même outil. Nous avons peut-être tous tort par rapport à une autre solution parfaite ou presque, mais au moins nous pouvons nous serrer les coudes et avancer ensemble.

Arnaud poursuit en présentant le cœur du projet Apache Maven, ceux qui le développent et dont nous dépendons finalement.

Maven, c’est aujourd’hui 55 développeurs, dont une bonne vingtaine très actifs en 2009, et une très longue liste de contributeurs qui rapportent des bogues, proposent des correctifs ou discutent des évolutions. Maven, c’est surtout un très large choix de plugins qui impliquent tout autant de développeurs de toutes origines.

Cette équipe motivée est à l’origine de plusieurs ouvrages, dont celui que vous tenez entre les mains, auquel vous pouvez ajouter le Definitive Guide et Better Build with Maven, tous deux disponibles en ligne gratuitement, et Apache Maven 2 Effective Implementations, proposé en ligne, chapitre par chapitre, au fur et à mesure de sa rédaction.

Limité au monde francophone, Maven c’est encore dix membres bien de chez nous qui ont participé à cet ouvrage en corrigeant nos erreurs. C’est aussi une volonté de communiquer avec les utilisateurs, comme l’a démontrée notre présence active dans les Java User Groups.

Maven est donc un projet très dynamique, et si les versions ne s’enchaînent pas aussi vite qu’on pourrait le désirer, c’est surtout parce que la qualité de nos livrables est constamment améliorée et qu’une politique très scrupuleuse (et très complexe) de compatibilité avec l’existant est suivie.

Votre Honneur, j’appelle à la barre notre premier témoin : Jérôme.

Jérôme a testé Maven suite à nos recommandations pour lancer une nouvelle application et former son équipe. Il est en quelque sorte notre cobaye pour valider l’adoption de Maven sur d’autres projets.

Pourquoi Maven réussit-il une percée en entreprise ? Nous l’avons vu au cours des chapitres qui ont précédé, Maven est un fédérateur d’outils. La même ligne de commande permet de construire n’importe quel projet Maven bien configuré.

Quel chef de projet ne rêve pas de pouvoir affecter un nouveau développeur dans l’urgence sans devoir perdre dans le même temps une ressource, le temps de lui expliquer toutes les ficelles du projet ? Avec des projets correctement construits avec Maven, le passage d’un projet à un autre se résume à un checkout depuis le gestionnaire de code source. Jérôme abonde dans ce sens en expliquant comment nous avons pu lui apporter une aide rapide en jetant juste un rapide coup d’œil sur son projet. Via une structure comparable, il est plus facile de s’approprier en peu de temps un projet développé ailleurs.

Jérôme souligne ensuite les bonnes pratiques que véhicule Maven : une gestion stricte des dépendances, des tests qui font corps avec le développement et non comme tâche à part, l’intégration des outils de qualité logicielle, le support de l’intégration continue, etc. Pour avoir trop souvent piloté des projets peu scrupuleux et réalisés sans filet, reposant sur les épaules de quelques personnes, il apprécie d’avoir enfin un cadre solide et homogène.

En entreprise, Maven est un élément clé de ce socle qu’on appelle software factory, qui vise à proposer une solution industrialisée, reproductible et stabilisée pour les développements logiciels, sortant de plusieurs décennies de bricolage. Jérôme, en s’inspirant de notre exemple, est en train de mettre en œuvre le même type d’outillage et bénéficie des infrastructures que nous avons déjà mises en place : gestionnaire du dépôt d’artefacts, serveur d’intégration continue.

Maven 2 ne bénéficiera au mieux que de quelques versions correctrices, et encore sous réserve que des développeurs prennent le temps de se pencher à son chevet ! Maven 3.x est la branche active qui bénéficie de toute l’attention de l’équipe.

Les équipes qui utilisent Maven 2.x seront encore nombreuses, soit pour des raisons d’incompatibilité sur un projet ancien, soit par méconnaissance de la compatibilité des versions successives de Maven (ou par manque de temps pour s’en assurer). Quelle que soit la raison qui vous pousse à continuer d’utiliser Maven 2.x, n’attendez rien de nouveau de ce côté. Cependant, pour nos lecteurs qui seraient contraints à cette version pour une raison qui leur appartient, un rapide état des lieux :

Maven 3 a longtemps été connu sous le nom de Maven 2.1. Son développement correspond à une refonte profonde du cœur de Maven, travaux importants menés de manière très active par l’équipe de Sonatype, société fondée par Jason Van Zyl, développeur initial de Maven. Cette reprise lourde du code a, dans un premier temps, paralysé les évolutions sur Maven 2.0 car tout le monde attendait plus ou moins la suite. Les choses ne vont cependant jamais assez vite et l’ex-Maven 2.1 a été renommé Maven 3.x pour bien indiquer la rupture et laisser de la place pour de nouvelles versions de Maven 2.

L’un des plus gros chantiers de Maven 3, et qui explique en grande partie son retard, est la compatibilité avec l’existant. Un ensemble de tests d’intégration a été écrit pour mettre en scène Maven confronté à la plupart de ses cas d’utilisation. Projets simples, multimodules, plugins plus ou moins complexes, sont ainsi exécutés en boucle par un harnais de sécurité antirégression de plus de 450 tests. Ce n’est pas une garantie absolue, mais c’est une sécurité que peu de projets peuvent proposer.

La seconde difficulté dans le développement de Maven 3 touche à la pérennité des API internes de Maven, utilisées par certains plugins, et que l’équipe de développement voudrait pouvoir retravailler. La limite entre public et interne dans Maven 2 est en effet assez floue, et pour traiter certains besoins particuliers, les développeurs de plugins ont parfois fait appel à du code assez profond de Maven 2. Sonatype a donc développé une couche de traduction entre les API historiques de Maven 2 et leur équivalent dans le code modernisé de Maven 3.

En résumé, Maven 3 c’est un peu un épisode spécial de Extreme makeover : Maven edition ^[58]. On prend votre outillage existant, mais on refait tout de la cave au grenier !

Raphaël se fait un plaisir en expliquant le monde open source et les garanties intrinsèques qu’apporte ce modèle.

Maven est l’un des nombreux projets hébergés par la fondation Apache, surtout connue pour son excellent serveur HTTP (à tel point qu’on parle souvent d’un serveur apache, sans plus de précision). Cette fondation assure par son statut l’indépendance des projets hébergés vis-à-vis d’un éditeur et encourage le développement communautaire.

Un projet Apache est conduit par un comité de pilotage, pour lequel chaque membre dispose d’un droit de veto sur les décisions prises, et où chaque décision majeure doit être soumise au vote et obtenir au moins trois avis favorables. Cette règle de conduite assure la stabilité des projets et le soutien de ses membres majeurs. Les autres membres du projet, qui ne font pas partie du comité et ne disposent pas d’un droit de veto, peuvent exprimer leur avis librement lors des votes. Il est rare que la décision finale ne soit pas le reflet d’un compromis accepté par tous.

Maven s’est développé dans cet esprit, chaque grande décision étant soumise à la communauté des développeurs et reflétant leurs choix communs. Au sein de la fondation Apache, il n’y a donc pas de propriétaire du projet, en dehors du comité dont les membres ont des attaches très variées.

C’est une distinction notable par rapport à d’autres projets open source dont les décisions ne sont pas si ouvertes. SpringFramework, par exemple, est un projet ouvert aux suggestions de ses utilisateurs et dont le code est libre, mais dont le développement est géré par la société SpringSource ^[59]. L’excellente équipe de développeurs que SpringSource a réussi à réunir propose un outil de grande qualité, tandis que le soin apporté pour répondre aux rapports d’anomalies et aux suggestions de la communauté d’utilisateurs est exemplaire. L’ouverture de ce projet reste cependant un petit cran en dessous de ce que peut proposer un logiciel hébergé par la fondation Apache et soumis à une gestion communautaire multipartite.

Nicolas poursuit en constatant une certaine incrédulité de notre auditoire. Le monde merveilleux de l’open source tout gratuit, où des développeurs-bisounours-bénévoles offrent leur temps et leur code à la communauté, les laisse perplexes. Derrière Maven, comme partout, il y a des gens à payer et des machines qui tournent.

Vous aurez noté dans les pages qui précèdent la très forte adhérence entre le développement de Maven et la société Sonatype. Maven est en effet un projet complexe, englobant des solutions techniques très spécifiques – pensez, par exemple, à la gestion de chargeurs de classes isolés pour chaque plugin, concept qui reste assez théorique pour une grande majorité de développeurs.

Parce que Sonatype met des développeurs de talent à temps plein sur le développement de Maven, le prix à payer pour suivre les développements en tant que simple contributeur est démesuré. Les technologies engagées sont nombreuses et nécessitent un gros investissement en temps. L’évolution du développement est rapide et peu documentée, il est donc difficile de se faire en peu de temps une idée précise des tâches en cours et de leur avancement.

Maven est cependant un projet de la fondation Apache, dont nous avons vu les règles de conduite, et, à ce titre, on peut trouver choquant de le voir mêlé de si près au nom d’une seule société.

En fait, en creusant un peu, on constate même rapidement que Sonatype est bien plus qu’un contributeur de Maven : des composants majeurs de Maven 3 ne sont pas développés et hébergés par la fondation Apache, mais sous le compte GitHub de Sonatype !

Parmi la refonte réalisée pour Maven 3, un élément clé est la réécriture complète de la gestion des dépendances. Après deux tentatives infructueuses, Sonatype a proposé un développement interne, Aether ^[60], hébergé en open source dans sa propre forge, et contribué à la fondation Eclipse. Il en est de même de Sisu ^[61], qui permet à Maven 3 de fonctionner sur la base du conteneur Google Guice tout en restant compatible avec Plexus, qui jouait ce rôle dans Maven 2 et est encore très présent dans de nombreux composants.

Sonatype, qui pilote donc seul ces projets cruciaux pour Maven, a choisi d’en faire une solution open source. Bien sûr, Sonatype prend une longueur d’avance sur tout concurrent qui voudrait occuper ce terrain, et s’ouvre les portes de la fondation Eclipse et la reconnaissance associée, mais la démarche doit tout de même être soulignée. De nombreuses autres sociétés, moins imprégnées par le modèle open source, n’auraient pas suivi cette voie et auraient tenté de monnayer leur compétence.

Verrouiller l’accès à Maven serait contre-productif. Une majorité des utilisateurs – et donc des clients potentiels – se tournerait vers des solutions libres, éventuellement moins bien intégrées. Le monde Java est particulièrement marqué par le modèle open source, et le seul argument financier ne suffit pas à expliquer cet engouement. Aller contre les attentes du public pour une société comme Sonatype serait comme couper la branche sur laquelle on est assis. Par contre, une fois devenu le standard de fait, monnayer l’expertise et le support autour d’un outil devenu stratégique pour beaucoup d’entreprises est un avantage commercial sans équivalent, quitte à se froisser un peu avec les membres de la fondation Apache.

En dehors de cette considération purement stratégique, il ne faut pas non plus oublier qui constitue l’équipe de Sonatype. Vous avez affaire à des gens techno-addicts, pas à des financiers. Des gens qui se passionnent pour le code et les nouveautés technologiques, et qui ne laisseraient à personne le soin de coder à leur place. Ces gens sont imprégnés par le modèle open source et n’auraient pas l’idée de lancer un nouvel outil en dehors de cet esprit. Ils sont au cœur du projet qu’ils ont construit et vu s’imposer, rien ne leur ferait plus mal que de voir leur bébé devenir une marchandise de plus.

Par contre, ils n’aiment pas forcément se faire dicter leur conduite par des personnes qui n’apportent rien de plus que des critiques. Aussi, le modèle de développement Apache, basé sur le compromis et le consensus, est régulièrement mis à mal par des décisions unilatérales. Autant le code reste ouvert et protégé par le mécanisme de licences, autant l’ouverture propre au développement communautaire n’est pas systématique.

Cependant, l’équipe de développement de Maven ne se résume pas à ces quelques personnes. L’équipe complète ^[62] compte des individus d’origines très variées et rattachés à des employeurs de toutes sortes. Pris individuellement, ils sont peu visibles, mais, comme pour tout projet open source, c’est ensemble qu’ils ont donné vie au projet Maven, et en particulier à son large écosystème de plugins.

Si Sonatype se comporte aujourd’hui comme un exemple dans sa démarche de contribution à l’open source, qu’en sera-t-il à l’avenir ? Que deviendrait Maven si cette société venait à être rachetée par un groupe aux intentions plus lucratives ? Après tout, en moins d’un an, nous avons vu Oracle racheter Bea puis SUN pendant que VMware rachetait SpringSource qui venait d’absorber G2One. Qu’en pensent ceux qui ont misé sur la machine virtuelle Java alternative JRockit et qui ne peuvent même plus la télécharger sans passer par le service de support d’Oracle ?

Ne perdons pas de vue deux éléments clés :

Pascal tente dans un premier temps de monter un projet Maven tout neuf, pour construire la structure nécessaire à un bundle OSGi, qu’il puisse ensuite intégrer avec son environnement de développement habituel. Cette approche « POM-first » l’oblige à trouver un équivalent en termes d’outillage Maven pour gérer plugins, fragments, features, update-sites, et toutes ces subtilités qui font la particularité du développement Eclipse RCP.

OSGi utilise également le fichier MANIFEST, rappelez-vous, celui que nous avons rencontré au chapitre 2 et qui permet à un JAR d’indiquer des métadonnées sur son contenu, comme sa version. OSGi enrichit ce fichier pour ajouter les informations d’identification du bundle, de version, de dépendances entre bundles, de services exposés ou consommés. Une partie de ces informations est redondante avec ce que nous déclarons habituellement dans le POM. Ici aussi, il va falloir trouver l’outillage pour transcrire les déclarations du POM Maven dans le format attendu par OSGi.

Les recherches de Pascal pour identifier les plugins Maven adéquats l’amènent au projet Apache Felix (une implémentation d’OSGi) et à son plugin apache-felix-maven-bundle-plugin-bnd. Celui-ci incorpore l’outil bnd ^[63], qui génère le MANIFEST OSGi à partir d’un projet Java standard, en déclarant simplement les packages privés et exportés. Ce plugin nous propose donc de transcrire le MANIFEST OSGi dans le formalisme XML du POM, comme le montre le listing 16.1.

Ce plugin permet de convertir assez facilement un projet Java classique en bundle OSGi, par contre Pascal rencontre encore quelques difficultés.

Pas vraiment satisfait, Pascal tente une seconde approche. Il part donc de son environnement de développement classique pour développer un plugin, Eclipse PDE (Platform Development Environment) et tente d’y ajouter nos bibliothèques shoppinglist. Un Bundle OSGi a deux options pour intégrer une dépendance :

La figure 16-01 montre par exemple le bundle Apache Ant, disponible par défaut avec votre installation d’Eclipse. Ce plugin incorpore l’outil Ant et ses dépendances dans son répertoire /lib. Pour être en mesure de construire un bundle, Pascal va donc devoir configurer Maven pour reproduire cette structure, à l’aide du plugin maven-dependency-plugin et de sa tâche copy-dependencies.

Figure 16-01

Le bundle Apache Ant dans une distribution Eclipse

Eclipse dispose d’un outillage complet pour le packaging des bundles, qu’il va falloir intégrer dans notre build Maven. Comme nous l’avons fait de nombreuses fois déjà, nous partons en quête du plugin adéquat et – bingo – trouvons rapidement le plugin pde-maven-plugin ^[64] du projet Mojo. Ce plugin lance Eclipse en mode « headless » (sans interface graphique) et exécute la chaîne d’assemblage du bundle.

Après de longues, trop longues heures de mise au point, Pascal arrive enfin à construire son bundle avec Maven. Tout cela lui semble tout de même bien compliqué pour un résultat sans grande plus-value.

La semaine suivante, Pascal prend part à notre stand-up hebdomadaire pour nous exposer ses progrès. Il lâche le morceau : la solution qu’il a retenue, c’est de ne pas utiliser Maven… Indignation, hurlements, la cacophonie qui s’en suit ne permet pas à Pascal de terminer sa phrase. Cependant, le calme qu’il affiche semble montrer qu’il ne craint pas pour sa période d’essai et a donc quelque chose à ajouter. Nous finissons donc par l’écouter. Son argumentaire est le suivant :

Admettons, et alors ? Pascal nous montre alors le fichier POM qu’il a utilisé pour construire le prototype de notre client lourd, présenté au listing 16.2.

Non, ne cherchez pas, il ne manque pas une page à ce livre, c’est bien tout ce qu’il suffit dans le POM pour gérer ce plugin Eclipse. Le secret de Pascal, c’est qu’il n’utilise pas le même Maven que nous : il utilise Sonatype Tycho.

Maven 3

Tycho est un des nombreux projets satellites de Maven, sur lequel Sonatype a énormément investi. L’idée de Tycho est de couper la poire en deux : laisser Maven faire ce qu’il sait bien faire, et laisser Eclipse PDE gérer les aspects d’OSGi pour lequel il est imbattable. Cette hybridation est rendue possible par le socle technique Maven 3, qui isole beaucoup mieux que son prédécesseur chaque composant de Maven et permet donc de les remplacer par une version alternative. Tycho abandonne donc la gestion de dépendance traditionnelle de Maven pour utiliser celle d’OSGi. Les dépendances ne sont donc plus déclarées dans le POM mais dans le MANIFEST OGSi.

Pascal a un peu triché dans sa démonstration, car il a en réalité placé la configuration nécessaire dans le projet parent – petit cachotier va.

D’une part, le composant principal de Tycho, tycho-maven-plugin, qui se charge d’étendre et de reconfigurer Maven pour utiliser les mécanismes OSGi là où ils sont plus judicieux que le build Maven standard :

Cette simple déclaration, déclarée comme extension, ajoute à Maven la gestion des cycles de vie eclipse-plugin, eclipse-feature et eclipse-repository. C’est globalement le même principe que nous avait montré François au chapitre 3 pour intégrer un développement Flex. Entre autres compléments au build que ce plugin incorpore, la gestion de dépendance est enrichie d’un nouveau format de dépôt, en plus du default et du legacy (dépôts Maven 1, obsolètes et plus supportés par Maven 3), le format p2. C’est ce qui permet à Pascal de référencer les bundles d’Eclipse Indigo, sur lequel est basé son client Eclipse RCP.

Autre composant du cocktail, le plugin target-platform-configuration se charge d’identifier la plateforme OSGi cible. D’une certaine façon, il s’agit d’un équivalent du dépôt local Maven à la sauce OSGi, regroupant tous les bundles OSGi référencés pendant le développement. Tycho va ainsi initialiser la plateforme d’exécution du bundle, et peut pour cela exploiter le support des dépôts P2, ou bien le classique dépôt Maven, ou bien les deux, quand on aime on ne compte pas. C’est ce qui permettra par exemple d’accéder aux bundles OSGi de Spring qui sont distribués dans un dépôt Maven.

Tycho identifie la version et la constitution de la plateforme OSGi/Eclipse sur la base des fichiers MANIFEST et feature.xml présents dans le projet de plugin. À partir de cela, il constitue le classpath et la configuration nécessaires à l’exécution de l’outillage.

Cet outillage est implicitement apporté par le packaging eclipse-plugin que Pascal a utilisé. Il associe au projet un cycle de vie particulier qui remplace celui que nous avons jusqu’ici toujours utilisé, et donc les plugins habituels du build Maven. La compilation du code Java est par exemple confiée à un plugin spécialisé, maven-osgi-compiler-plugin, qui tient compte des spécificités de la plateforme en termes de visibilité des classes déclarées dans les bundles. Comme le plugin maven-compiler-plugin, nous pouvons au besoin le déclarer explicitement pour enrichir sa configuration, par exemple activer le support Java 7, parce que mince, on est plus au Moyen Âge :

De la même façon, l’exécution des tests passe par un plugin dédié maven-osgi-test-plugin, Eclipse PDE nous imposant de séparer physiquement les tests dans un bundle dédié pour ne pas polluer le MANIFEST du bundle principal.

Pascal nous a bluffés, et même si nous avons encore un peu de mal à admettre que notre magnifique gestion de dépendance Maven vient de se faire moucher, son build Eclipse RCP est propre, simple, fonctionnel, et lui permet de développer confortablement le client riche que notre marketing nous réclame avec insistance. Nous donnons rendez-vous à Pascal pour le prochain stand-up, et courons emprunter « Eclipse - Principe, patterns et plug-in » (chez le même éditeur) à la bibliothèque technique de Geegol pour une rapide mise à niveau histoire d’avoir l’air moins bêtes la semaine prochaine.

Quelques semaines plus tard, le travail de Pascal a bien avancé, et il nous présente maintenant son build complet, qui inclut désormais la production complète de l’application RCP, incluant de nombreux plugins, bundles et features pour répondre au moindre désir de nos clients. La petite nouveauté du jour, c’est le packaging de l’application pour chaque environnement cible. Une fois de plus, les plugins apportés par Tycho permettent de limiter cette tâche complexe à quelques déclarations simples, comme le montre le listing 16.3.

Par l’universelle commande mvn install, Pascal est désormais en mesure de produire les versions Linux et Windows de notre client riche. Défis relevés avec panache, merci Pascal !

L’objectif de la JSR 294 est ambitieux, car il amène au sein de la plateforme un service qu’on avait jusqu’ici confié à notre outillage. Dans un premier temps, les travaux ont amené à envisager un nouveau système de packaging, les Java Modules (JSR 294). Les utilisateurs d’OSGi n’ont pas tardé à se faire entendre en moquant cette norme qui arrivait péniblement à la cheville de leur outillage déjà éprouvé. Cette piste a été gelée, et la JSR 294 a été revue pour élargir les participants et trouver une solution plus consensuelle.

Jigsaw vise à faire disparaître la notion de chemin des classes (classpath) au profit d’une approche déclarative et totalement automatisée. Mark nous présente un exemple de descripteur de dépendance :

Ce n’est certes pas un fichier POM, mais à la syntaxe près, ça y ressemble tout de même fortement ! Mark nous indique que plusieurs versions d’un même module pourront coexister en mémoire, pour répondre aux contraintes de dépendances définies par chaque module. C’est en effet quelque chose qui est hors de portée de Maven, mais qu’OSGi gère de longue date.

Mark nous présente aussi le prototype que constitue jigsaw ^[66], et la commande jmod destinée à rejoindre le JDK. Mimant les outils de gestion de paquet qu’on trouve sur les systèmes Linux (rpm, deb) ou encore les environnements Ruby (gem), jmod permet d’installer un composant et ses dépendances :

jmod install org.openjdk.aggregator-1.0.jar

Hum, voilà qui nous laisse bien perplexes, en particulier Olivier qui se permet de citer jpkg, l’outil GNU/Linux qui permet de créer des paquets système à partir d’une bibliothèque Java. Bien qu’imbattable sur le terrain technique, nous ne voyons pas bien où Mark tente de nous emmener avec son projet.

L’idée de la modularisation est séduisante. Nous avons en effet largement présenté l’intérêt de la gestion de dépendances, où chaque bibliothèque de haut niveau indique les composants plus fondamentaux qui sont nécessaires à son fonctionnement.

Si on regarde le fonctionnement de Java, de nombreuses API sont présentes de longue date, et bien que dépréciées elles ne peuvent disparaître avec la version suivante de Java, car Java nous assure la compatibilité ascendante : notre runtime Java 7 est en mesure d’exécuter du code de 1999 écrit en Java 1.1, comme ce fameux projet retrouvé sur une disquette au début de ce livre.

En tant qu’utilisateurs de Maven, nous pouvons dire que notre code utilise Spring 3 ou plus. Nous n’avons pas à nous soucier de compatibilité avec des versions précédentes de Spring, car toute application qui fait référence à notre POM devra implicitement utiliser au moins Spring 3, point barre.

La modularisation permet ainsi d’alléger chaque partie du runtime Java en éliminant un lourd héritage, et à chaque application de cibler précisément quels éléments de Java elle exploite. La maintenance et l’évolution de Java en seraient grandement facilitées, au même titre que les performances de notre application qui embarquerait moins de code inutile.

JigSaw ne répond pas au besoin de Monsieur tout-le-mode, mais à celui très spécifique des mainteneurs de Java. Avec huit versions de la plateforme empilées, la prochaine release de la plateforme va encore ajouter de la complexité, il est donc largement temps de trouver une solution pour faire le ménage. Les outils de modularisation que sont OSGi ou Maven se basent déjà sur Java. Pourtant il n’est, par exemple, pas possible de les utiliser pour désolidariser l’interface java.util.List de ses implémentations concurrentes dédiées à la programmation parallèle.

Mark a l’habitude de trouver un accueil un peu frais à ses explications, et a donc gardé pour la fin les éléments qui vont peut-être nous faire comprendre l’intérêt de la modularisation au sein même de la plateforme Java.

D’une part, la vérification des dépendances se fait au runtime, et non à la compilation. Plus de NoClassDefFoundException parce qu’il manque un JAR dans votre application web ! Sur ce terrain, Maven ne peut pas grand-chose pour nous, à part espérer que les métadonnées qu’il exploite soient correctes.

Le format de fichier .class va d’ailleurs évoluer. La notion d’archive JAR n’étant pas adaptée à la modularisation, c’est directement le format des classes qui va permettre la modularisation et l’accélération du chargement du code Java compilé. C’est également le choix fait par Google pour la plateforme Android, afin de ne pas surconsommer les ressources des appareils mobiles.

Le contexte d’exécution étant plus prédictible que dans le cas du classpath, où l’emplacement physique d’une classe ne peut être connu à l’avance, la résolution statique va pouvoir être utilisée et significativement améliorer les performances. C’est déjà ce qui a été employé dans le cadre de Java Card pour améliorer les performances dans un environnement très limité en ressources.

La vérification des classes, étape que nous ne voyons pas, mais qui consiste pour la JVM à valider la cohérence de chaque fichier .class qu’elle charge en mémoire, sera effectuée à l’installation du module, une fois pour toutes. Ici encore, la vitesse de démarrage de Java pourra ainsi être améliorée. Cumulée avec les autres techniques qu’il nous a indiquées, Mark nous annonce un gain sur le temps de chargement pouvant atteindre 70 % !

Ensuite, le chargement des modules peut être incrémental. L’application peut donc être disponible à son utilisateur en un temps record et attendre un peu pour charger la suite de ses composants. Ceci peut permettre à Java de perdre son image de langage lent, tout juste bon à développer de complexes applications côté serveur.

Un module pourra enfin être lié à une architecture matérielle et se substituer au lancement en fonction de l’environnement sur lequel s’exécute l’application.

Même notre ami Jim se refuse à faire des prédictions sur ce que donnera JigSaw confronté à la réalité que sont OSGi et Maven. JigSaw est prévu pour s’intégrer dans Java 8, planifié pour fin 2012 – mais bon, un projet informatique qui se termine dans les temps, ça ne s’est jamais vu. Ami lecteur, si tu lis ces lignes à cette date, envoie-nous un petit message pour nous dire si Mark a tenu sa promesse.

Nous sommes tous très dubitatifs sur ce que JigSaw va donner sur notre écosystème et notre outillage. Il faudra déjà attendre une forte adoption de Java 8, puis la mise à jour des frameworks majeurs que sont Spring, Hibernate et consorts, avant de pouvoir estimer son impact. Mark nous rassure avec une dernière démonstration. Utilisant jmod, il ajoute à son environnement des bibliothèques classiques, et pour cela doit indiquer un dépôt qui serve de source, comme le montre le listing 16.4.

Voici une URL que nous connaissons bien, celle du dépôt Maven central ! Finalement, laissons à JigSaw le temps d’arriver à maturité. Après tout, marier Maven à OSGi semblait bien difficile, et finalement Tycho nous a apporté une solution simple et performante.

Maven propose ses propres conventions mais ne les impose pas. Un projet que nous avons fait migrer sous Maven utilisait comme répertoire de sources le chemin src/java et pour les tests test/java. Les POM ont donc été adaptés pour coller à cette convention.

Nous avons perdu un temps précieux à reconfigurer de nombreux plugins, qui ont la mauvaise idée d’utiliser le chemin src/main/java en dur et pas la variable ${build.sourceDirectory}. Notre POM ne gagne pas en lisibilité, et c’est cher payé pour un petit caprice esthétique.

De la même façon, ne considérez jamais les conventions comme acquises. Utiliser le chemin /target/classes pour indiquer le répertoire de compilation du projet, c’est potentiellement s’exposer à un dysfonctionnement. Nous en avons fait la mauvaise expérience en configurant notre application pour utiliser Sonar (voir le Chapitre 12). La convention pour ce chemin est portée par la variable ${project.build.outputDirectory}. C’est un peu plus long à écrire, mais c’est une garantie d’homogénéité des métadonnées du projet.

Le respect des conventions permet :

Notre premier mauvais élève est un projet que nous avons voulu faire migrer d’Ant vers Maven. Les technologies en œuvre avaient toutes le plugin Maven adéquat, mais la structure initiale du projet était particulièrement hétéroclite. Notre erreur a été de vouloir la conserver telle quelle, ce qui imposait :

Inutile de dire que la migration vers Maven a été laborieuse et pas du tout convaincante, tant que nous n’avons pas pris la décision de revoir fondamentalement la structure du projet : des modules simples, ciblés sur une technologie ou sur un domaine fonctionnel précis, et répondant à une logique de construction standard.

Il existe quelques projets qui refusent d’utiliser Maven, sous prétexte qu’ils nécessitent d’innombrables lignes XML pour obtenir le résultat attendu, lorsque c’est possible. Spring 2 en est un exemple, le framework étant toujours construit avec le bon vieux Ant. Ce n’est pourtant pas une fatalité, et cela a été démontré dans Better Builds With Maven (disponible librement en ligne), qui propose un POM permettant de construire Spring sans acrobaties particulières.

Les développeurs de Spring sont-ils tordus ? Non ! Par contre, ils ont fait des choix qui vont à contresens des préconisations de Maven. Par exemple, Spring est disponible à la fois comme un unique JAR et comme un ensemble de sous-bibliothèques spécialisées. Ensuite, le cœur de Spring 2 est compatible à la fois Java 1.3 et Java 5, ce qui nécessite une double compilation puis le regroupement du résultat dans une unique archive JAR.

Bien que Spring ait récolté un grand succès pour ses qualités techniques, les structures de son code source et de son script de compilation le rendent inutilement complexe. Après tout, si vous travaillez sur Java 5, vous pouvez très bien déclarer une dépendance vers spring:2.0.8:tiger ^[67] à la place de spring:2.0.8. Les dépendances transitives feront le reste.

La morale de cette histoire, c’est qu’il ne faut pas chercher à plier Maven à des besoins complexes, mais plutôt essayer de comprendre comment traiter nos besoins selon la philosophie de Maven. Autant Ant permet de faire à peu près tout et n’importe quoi, autant Maven suppose qu’on adhère à sa logique pour en tirer tout le bénéfice.

Des projets comme Alfresco ou Liferay ne s’accommodent pas facilement de Maven. Il faut prendre le temps d’analyser les besoins et d’organiser au mieux le projet pour être efficace.

La pléthore de plugins d’analyse de code disponibles nous encourage à mettre en place un suivi qualité de haut niveau. Il est si simple de lancer l’un de ces nombreux outils pour analyser le code et identifier des problèmes automatiquement – il est juste dommage qu’il ne les corrige pas aussi automatiquement !

Nous avons ainsi pris un projet récemment adapté à Maven et produit quelques mégaoctets de rapports variés. Mais que faire de ces pages et des indicateurs en tout genre que nous obtenons ? Comment traiter des règles parfois incompatibles ou, en tout cas, dont nous ne voyons pas forcément l’intérêt ?

Si nous utilisons les règles par défaut de Checkstyle, établies sur les recommandations de codage SUN – qui datent des débuts de Java –, celui-ci nous insultera pour chaque méthode qui ne dispose pas de commentaire Javadoc. Issue d’une époque révolue, cette règle part du principe que tout code public doit être accompagné d’un commentaire explicatif. Elle va nous amener à écrire ce genre de chose :

Voilà un magnifique commentaire dont l’utilité est sans appel ! Soit vous générez l’ensemble des commentaires pour satisfaire Checkstyle, soit vous définissez une règle qui préconise la forme plutôt que la pertinence du commentaire ou la clarté du nom de la méthode ! Sincèrement, tout développeur préférera, même sans commentaire Javadoc, une méthode nommée :

Plutôt qu’une méthode équivalente utilisant un vocabulaire obscur, mais largement accompagnée de commentaires et qui satisfait nos outils d’analyse :

Choisir des règles de développement est une tâche qui nécessite une culture et un historique de mise en œuvre du langage. La tendance est aux noms de méthodes et de variables clairs, explicites, quitte à faire long – les écrans 16:9 ont probablement aidé à cette évolution. Fini le code sur 80 colonnes ou l’utilisation des tabulations !

Utiliser l’outillage que Maven met à notre disposition n’est pas une fin en soi. Ce doit être l’aboutissement d’une démarche qui définit les règles que nous voulons vérifier ou les outils que nous voulons mettre en œuvre. Introduits sur le projet un par un, ces outils seront bien perçus et leur plus-value reconnue. Imposés tout d’un coup sans explication, ils seront vécus comme une contrainte inutile et deviendront vite inutilisés, voire contre-productifs.

De la même façon, installer un serveur d’intégration continue n’a de sens que pour des équipes déjà familiarisées avec l’outillage de tests automatisés et la pratique du développement dirigé par les tests, et sensibilisées au surcoût d’un projet dont le code est instable.

Inutile donc de barder notre POM de plugins en tout genre et de déclarations sans fin, juste parce que le format du fichier le permet. Si personne ne les exploite ou ne sait comment en tirer parti, ce sera du temps perdu, un travail contre-productif. Maven n’est qu’un moyen qui nous aide à mettre en œuvre les bonnes pratiques actuelles du développement de logiciels. Il n’est en aucun cas une solution magique. Il permet de mettre en place différentes stratégies de tests (unitaires, d’intégration…) mais il ne le fera jamais à la place de nos équipes. Elles seules peuvent s’assurer que les bonnes pratiques sont suivies.

L’application maxiMaousse ^[68], elle aussi basée sur Maven, comprend 58 modules ! Elle suit une décomposition en couches techniques ainsi qu’un redécoupage en modules fonctionnels. Une modification fonctionnelle touche ainsi rarement plus d’un ou deux modules, réduisant – théoriquement – le travail de non-régression.

En pratique, cette application est ingérable dans notre IDE en raison de l’avalanche de modules. Les évolutions touchent rarement un seul module, et les interdépendances sont nombreuses. La construction du projet sur un poste de développement incluant les tests unitaires et de qualité devient un vrai cauchemar, elle est surtout contre-productive et l’identification du code un vrai casse-tête. Certains modules ne comptent que quelques classes ! Ici, on a visiblement confondu la notion de package et de module Maven.

La gestion multimodule de Maven est puissante, ce n’est pas une raison pour l’appliquer juste parce qu’elle existe. Nous ne créons un nouveau module que lorsqu’un nouveau besoin apparaît. Cela arrive déjà suffisamment assez vite : par exemple, pour répondre à une contrainte technique ou pour différencier deux modules qui travaillent sur des technologies différentes et dont nous voulons clairement scinder la gestion. Si la décomposition en modules fins peut avoir du sens pour une bibliothèque utilitaire, elle apporte rarement de la simplicité sur une application. Au mieux, on pourra découper celle-ci en fonction de ses couches techniques afin de permettre à des équipes de compétences différentes d’intervenir de manière plus isolée. Cependant, les modules resteront fortement dépendants ; aussi, pourquoi ne pas simplement utiliser des packages dédiés dans le même projet ?

Le seul cas pratique où la décomposition en modules peut apporter une certaine plus-value concerne la génération de code. Lorsqu’un projet est basé sur de nombreux services web, l’analyse des WSDL et la génération de code prennent du temps, même pour constater que le code généré est à jour. Pour ne pas pénaliser les développeurs sur leur poste, isoler ce code dans un sous-module peut être une bonne idée. Après tout, on ne change pas de WSDL tous les matins !

Bref, les occasions de justifier le découpage d’un module en plusieurs modules sont nombreuses. Alors, n’en faites pas plus que nécessaire. Vous testerez le réacteur de Maven bien assez tôt.

Même si mettre en place l’outillage de développement n’est pas une fin en soi, c’est un mal nécessaire, au coût non négligeable, permettant d’offrir à l’équipe un environnement aussi agréable que possible et optimisé pour travailler. De très nombreux outils peuvent y figurer :

Il est important que ces outils soient maîtrisés, mais il est encore plus important qu’ils soient mis à jour et que leur intégration soit poussée à son maximum. Celle-ci permet, par exemple, via le numéro du bogue placé dans le commentaire d’un commit sur le gestionnaire de sources, de faire le lien depuis le gestionnaire d’anomalies pour afficher les lignes modifiées par la correction. Ce genre d’intégration fait gagner beaucoup de temps pour la revue des corrections de bogues. Et les intégrations entre produits sont nombreuses. Celles unifiant tous les services au sein de l’IDE sont probablement celles qui amélioreront le plus la productivité.

Les mises à jour de chaque outil sont importantes. Prenez l’exemple de Maven. Sur un projet multimodule monstrueux provenant tout droit de l’ère jurassique (plus de 150 modules), Maven 2.0.10 mettait près de huit minutes rien que pour s’initialiser et générer l’ordre de construction des modules. Avec Maven 2.1.0 et supérieur, cela prend moins d’une minute. Même si ce cas est extrême (mais bien réel), il est représentatif des gains que l’on peut obtenir en faisant l’effort de maintenir à jour ses outils.

Les projets durent longtemps et les outils évoluent vite. Les maintenir à jour permet d’en obtenir le meilleur. Cela entraîne un coût récurrent, mais qui est finalement vite rentabilisé par les gains de productivité de l’équipe.

Sur un projet de messagerie, nous avons développé une couche complète d’abstraction autour de l’envoi/réception de messages, indépendante du fonctionnel. Nous avons voulu capitaliser dessus et la proposer à d’autres projets. Une fois ce code déplacé dans un module, il devenait exploitable sur une autre application qui profitait ainsi de nos longues heures de mise au point.

La réutilisation est un rêve de tout chef de projet. Seulement, lorsqu’une application nous a demandé d’utiliser ce module, s’est posé le problème de la gestion de sa version. Notre demandeur ne voulait pas utiliser un SNAPSHOT ; sa livraison étant prévue sous peu, il lui fallait un code stable. Notre code répondait à cette attente, mais étant lié à notre application, il partageait son numéro de version. Nous pouvions faire une livraison isolée de ce module, mais alors celui-ci référençait un parent encore en SNAPSHOT !

Nous avons donc dû figer notre POM parent dans une version 1, livrer le fameux module mutualisé en version 1.0.0 et continuer notre application en version 1.0.0-SNAPSHOT. À ce petit jeu, nous nous sommes rapidement retrouvés avec des versions dans tous les sens dans les POM des différents modules et l’impossibilité d’utiliser le processus de livraison détaillé au Chapitre 11.

La morale de cette histoire, c’est que les modules d’un projet devraient toujours partager la même version, sans quoi la gestion manuelle des numéros de version devient infernale. Le plus simple pour satisfaire ce besoin est de ne définir cette version que dans le POM parent du projet et dans les références <parent>. Toutes les autres références se font via la variable ${project.version}. Ainsi, pas de risque de se tromper.

Pour déclarer du code comme bibliothèque commune, nous devons créer un nouveau projet Maven indépendant : POM dédié, gestion de version dédiée, gestionnaire de code dédié, etc. Une fois notre code utilitaire préparé pour être réutilisable ailleurs, sous forme d’un projet à part entière, il ne peut plus être considéré comme un élément de notre application, même si celle-ci devient un contributeur privilégié de ce composant commun.

Dans un projet basé sur de nombreux modules, un travail vite pénible consiste à assurer la cohérence de versions des dépendances. Des plugins peuvent nous aider dans cette tâche, mais il existe une solution bien plus simple : le <dependencyManagement>. Cet élément, que nous allons ajouter dans le POM parent du projet, déclare pour chaque dépendance la version de référence à utiliser sur le projet. Dans les modules, nous déclarons alors les dépendances sans préciser de version, éliminant ainsi le problème.

Le <pluginManagement> permet de faire la même chose pour les plugins avec, en plus, la possibilité de définir une configuration centralisée, mais qui ne sera appliquée que sur les modules qui utilisent le plugin.

Nous avons créé une belle bibliothèque utilitaire commons-geegol dont l’objectif est d’apporter à tous nos projets des classes utilitaires, facilitant l’accès à de nombreux outils. Ce code dépend donc de très nombreuses dépendances, mais seule une sous-partie est utile pour un utilisateur, qui ne va exploiter que quelques classes de notre bibliothèque. Nous pouvons :

La philosophie de Maven nous encourage à utiliser un module dédié pour chaque technologie ou outil que nous voulons supporter. Si cela veut dire avoir dix modules, ce n’est pas un problème. La gestion des dépendances et de la livraison étant automatisée, cela n’a aucun impact sur le temps passé par le développeur sur son travail, la seule chose qui compte finalement. Par contre, nous gagnerons dans la finesse de nos métadonnées et dans la bonne décomposition de notre code.

Sur un projet comptant plusieurs (dizaines de) modules et de très nombreuses classes, il peut être pénalisant d’avoir tout le code accessible sous forme de projet dans l’IDE. Nous pouvons, par exemple, exploiter certains modules sous forme de SNAPSHOT, comme celui contenant le code généré de nos schémas XSD. Le conserver dans notre IDE n’apporte rien et pénalise l’intégration Maven qui va devoir sans cesse reconstruire ce code, ou du moins s’assurer qu’il est à jour – perte de temps que le développeur ressentira très nettement :

En reposant sur les SNAPSHOT pour tous les modules dans lesquels nous ne faisons aucune modification et qui correspondent à du code évoluant très peu, nous allégeons d’autant le travail de l’IDE. Notre serveur d’intégration continue a le mérite de ne prendre ni pause ni café. Il peut construire pour nous les SNAPSHOT de nos modules au fur et à mesure qu’une construction réussie est atteinte.

Cela fait très expert de scruter la console et de taper à une vitesse folle des commandes incompréhensibles. Si vous envisagez un rôle dans une série américaine, pourquoi pas ? Mais si vous voulez travailler confortablement et former rapidement vos équipes, cherchez plutôt de l’aide du côté de votre environnement de développement.

Trop souvent, nous perdons du temps sur les postes de développement suite à un comportement bizarre de Maven. Le cas typique se traduit par un appel à l’aide du type : « J’ai beau lancer des mvn clean install, project clean sous Eclipse, et build all, je n’arrive pas à démarrer mon serveur Tomcat à cause d’une NoClassDefFoundError. »

Le but du développeur n’est pas de passer son temps devant la Matrice ^[69], surtout en mode crypté (de toute façon, ça fatigue vite les yeux). Il faut toujours privilégier la productivité de l’équipe, sans quoi les belles méthodes et les outils préconisés seront vite oubliés dans le feu de l’action.

Nous avons vu au Chapitre 9 que cette intégration est déjà très correcte et progresse même rapidement sous Eclipse, qui est trop longtemps resté à la traîne. Apprenez à bien utiliser le support de Maven dans les IDE pour fournir à l’équipe un outil aussi transparent que possible. Les versions récentes de m2eclipse proposent, par exemple, la variable m2eclipse qui permet de différencier un build classique d’un build sous Eclipse. Un bon moyen de rendre l’IDE plus réactif est d’en profiter pour désactiver les étapes non indispensables de la construction du projet. Le Listing 16.1 montre l’activation d’un profil exclusivement en dehors de m2eclipse.

Une autre option consiste à exploiter l’intégration avancée sous Eclipse que permet le mode incrémental de m2eclipse. Le Listing 16.2 montre une telle configuration pour associer le plugin adapté à la phase de recopie des fichiers de ressources. L’astuce consiste, lors d’un build m2eclipse, à utiliser la version SNAPSHOT du plugin de gestion des ressources (qui gère ce mode incrémental) et à activer le configurateur m2eclipse associé aux projets Java.

Lorsque nous avons décidé de romancer notre ouvrage, nous nous sommes posé la question de savoir qui seraient les personnages qui allaient nous entourer dans notre aventure. La réponse fut vite trouvée. Quoi de mieux que de rendre hommage à notre façon aux membres francophones de l’équipe de développement du projet Maven ?

Laissons-les se présenter (par ordre alphabétique du prénom, comme ça, pas de jaloux).

Pour compléter notre fine équipe par quelques profils moins « Maven-addicted », nous avons invité quelques-unes de nos connaissances de la communauté Java francophone.