Voici mon retour après la lecture du livre Apache Maven.

Synthèse

Ce livre est bâti tout au long sur des exemples concrets issues de l'expérience terrain des deux auteurs (Nicolas De loof et Arnaud Héritier).
Il n'est pas une bible exhaustive de Maven. N'essayer donc pas de trouver dans ce livre le paramètre manquant pour configurer votre plugin. Néanmoins, tous les concepts de Maven et autour de Maven son présentés. En effet, chaque chapitre aborde toutes les problématiques que nous pouvons rencontrer à sa mise en place sur des projets. Et ce livre est vraiment constitué de chapitres d'une excellente qualité avec une approche très pragmatique des auteurs. Mon seul regret est que quelques concepts non pas été plus approfondis.

En résumé, si vous connaissez déjà Maven, ce livre vous permettra de conforter vos connaissances; et la démarche du livre vous servira surement lorsque vous voudrez expliquer Maven à votre entourage. Et si vous ne connaissez pas Maven, ce livre vous donnera une vision globale de Maven et vous permettra de connaître toutes les problématiques sous-jacentes à la mise en place de Maven dans les projets.

Quelques phrases clés qu'il faudra retenir:

• Maven est un fédérateur
• La philosophie de Maven est d'éviter que les développeurs passent de longues heures à mettre leur environnement au carré pour pouvoir coller aux attentes du projet
• Les conventions on été choisis pour refléter les bonnes pratiques et des règles simples d'organisation
• Quel que soient le projet Maven, la commande mvn install sera toujours le seul et unique point d'entrée pour construire le projet en intégrant toutes les étapes nécessaires
• Ne pas chercher à plier Maven à des besoins complexes mais plutôt essayer de comprendre comment traiter nos besoins selon la philosophie de Maven.

--> N'hésitez donc pas à acheter ce livre, vous devez l'avoir dans votre bibliothèque.

Les autres critiques

• Critique par Romain Linsolas sur Developpez.com
• Critique par Nicolas Giard sur NooCodeCommit
• Les critiques sur le site de Pearson

Détails par chapitre

Préface

Résumé
Le livre commence par une préface de Jason Van Zyl, fondateur du projet Maven. On y apprend l'histoire de Maven comme sa naissance au sein du projet Jakarta Alexendria et Turbine. On y apprend ensuite le pourquoi d'un référentiel Maven de librairies, utilisé aujourd'hui par la totalité de la communauté Java.
Jason conclut par le fait que c'est l'expérience projet et les retours de toute l'incroyable communauté qui a permis aujourd'hui de créer les bases de Maven 3.

Commentaire sur la préface
L'historique de Maven est présenté très clairement. Il permet de bien comprendre pourquoi Maven a été crée et qu'est-ce que l'outil aujourd'hui.

Commentaire personnel sur Maven
Jason fait une allusion sur le fait que la compatibilité entre Maven 2 et Maven 3.0 sera de 100%, mais il n'explique pas vraiment les causes de l'échec de Maven 1 et que chaque version majeure de Maven est une réécriture complète. En effet, Maven 3 est également une réécriture complète de l'outil; et des efforts phénoménaux sont faits pour garder une compatibilité avec Maven 2.
A titre comparatif, le système de build Gradle est souvent critiqué pour ses gros changements (pour le moment) entre chaque version.

Partie I : Premiers pas avec Maven

Chapitre 1 : Introduction

Résumé
À travers une histoire sur une vielle application de Nicolas De loof, on y apprend

• la problématique de faire des scripts indépendants de l'homogénéité d'une équipe ou de l'environnement d'exécution.
• que Ant est l'acronyme pour Another Neat Tool (autre chouette outil)
• que l'utilisation de Ant crée de nouveaux métiers : expert en script Ant
  

Ensuite un premier script Maven est donné, puis une explication du pattern «Convention plutôt que Configuration» est expliquée en détail. Il faudra retenir qu'on passe d'une approche programmatique à une solution déclarative en présentant en quoi notre projet est différent de ce cas stéréotypé. On notera également que les conventions de Maven permettent une très grande rapidité d'apprentissage d'un développeur lors du passage d'un projet Java à un autre, lorsque celui-ci est sous Maven.

Commentaire sur le chapitre
L'approche est génial, on adhère complètement aux principes de Maven à ce niveau du livre.
Les atouts de Maven sont présentés très clairement.
Le livre commence très bien.

Commentaire personnel sur Maven
Faisons attention car les réalités de terrain ne sont pas toujours aussi euphoriques.
A suivre...

Chapitre 2: Au-delà de java.lang

Résumé
Ce chapitre commence par nous expliquer pourquoi il n'est pas souhaitable de mettre les librairies dans un gestionnaire de sources. Ce qu'il faut retenir: c'est que contrairement à un fichier source, une librairie est une boîte noire et que l'on ne peut pas faire de différentiel entre deux binaires.
Ensuite une sensibilisation nous est faite sur l'importance d'avoir le numéro de version dans le nom du jar. Il est également présenté pourquoi il y a un risque de mettre dans son classpath tous les fichiers de son répertoire lib sans aucun contrôle, sans aucune maîtrise.

Commentaire sur le chapitre
Je regrette que cet aspect n'ait pas été plus creusé. La solution Maven nous ai présentée comme solution miracle, cela semble tombé un peu du ciel à ce niveau dans la lecture du livre.

Commentaire personnel sur Maven
L'argumentaire est exact sur de gros projets mais il a moins de poids sur de petits projets et qui resterons petits.
Avoir une librairie nommée correctement comme signalée est sans aucun doute indispensable.
Mais il est tout a fait possible de les mettre en gestion de configuration où le répertoire lib serait par exemple divisé en configurations 'compile', 'test', 'runtime'. Jason prend l'exemple de librairies utilisées à la fois durant les tests et la compilation mais encore une fois, est-ce si grave sur de petits projets? Le classpath peut être constitué effectivement de toutes les librairies de ce répertoire lib ou mettre en place plusieurs classpath par répertoire 'lib/compile', 'lib/runtime'. Certes, il y a toujours un risque comme indiqué de supprimer des librairies. Néanmoins, on peut aussi mettre en place un système de gestion de dépendances (et dépendances transitives) au niveau de son script a partir d'un répertoire de librairies. C'est ce que propose par exemple Gradle avec la notion de « client modules ». Et dans ce cas, avec ce dernier outil, on a une identification exacte des librairies comme dans Maven.

Résumé (Reprise)
Le chapitre se poursuit sur la présentation du mécanisme de dépendances Maven et son algorithme de résolution de conflits. Puis la notion de scope d'une dépendance Maven est présentée.
Ensuite, les effets de bords des dépendances transitives dues à des mauvaises métadonnées sont expliqués. Des solutions de résolution sont exposées comme l'élément <optional> et les sections d'exclusions.

Commentaire sur le chapitre
J'apprécie la mention sur l'existence du gestionnaire de dépendance Apache Ivy. Je comprends l'explication sur la problématique des mauvaises métadonnées et que tout le monde est invité à contribuer afin de les améliorer. Néanmoins, je regrette que les autres possibilités de résolution des problèmes de métadonnées de Maven (à bien ou à tord), ne soit pas présentées en profondeur.

Mais n'oublions pas qu'il s'agit d'un livre sur Maven 2 et non un comparatif sur les outils de builds.

Commentaire personnel sur Maven
Concernant la gestion des dépendances, Maven 2 est vraiment loin d'être le meilleur outil sur le marché. Apache Ivy, son principal concurrent sur cet aspect, propose un ensemble de services bien plus avancés, avec en plus la capacité de lire et écrire des métadonnées Maven.. Il offre par exemple la possibilité de désactiver la transitivité d'une dépendance, évitant une liste d'exclusions. Il n'est pas mentionné non plus que Maven ne permette pas la notion d'exclusions globale, ce que fait Gradle.

Chapitre 3: Un peu plus que compiler

Résumé
On y apprend que par défaut, Maven assume que le code source est au format Java 1.3 et il génère du bytecode au format 1.2. La configuration nécessaire dans le pom.xml pour une compilation en Java 5 est donnée. Il est également présenté comment modifier le plugin par interpolation. Puis, la structure conventionnée d'un projet est présentée en détail. Ensuite, il est décrit comment déclarer un plugin et comment invoquer ces tâches. Puis une section détaille comment invoquer un plugin depuis le cycle de vie Maven ou depuis une invocation directe. Le chapitre se poursuit sur un exemple de génération de code source dans le cas de web services SOAP. Et enfin, un exemple de l'utilisation de Flex avec Maven est donné.

Commentaire sur le chapitre
Ce chapitre nous présente des cas d'utilisation concrets qui sont utilisables au quotidien.
J'apprécie la note sur l'interpolation que je ne connaissais pas.
Il s'agit d'un bon chapitre de ce livre (et cela ne sera pas le seul...).

Commentaire personnel sur Maven
Maven est naturellement un outil vieillissant nécessitant de s'adapter aux nouvelles normes.
Ses concurrents (nés des bons et mauvais retours de Maven), de part leur âge de création, exploitent directement les nouvelles conventions et les configurations usuels. C'est le cas de Gradle.
Ainsi, espérons que Maven 3, assume par défaut que le code à compiler est du Java 5.

Chapitre 4: Mettre en place des tests unitaires

Résumé
Le chapitre commence par nous sensibiliser à la notion des tests et pour quoi faire? Des exemples de code de tests unitaires avec le framework JUnit sont donnés. Le chapitre se poursuit par l'intégration des tests unitaires dans Maven avec le pourquoi d'une séparation entre les sources du livrables et les sources de tests. Ensuite, une rapide présentation de TDD est donnée aux lecteurs. Puis, tout naturellement, l'intégration de Maven pour l'exécution des tests est fournit. Pour finir, une présentation du besoin d'intégration continue, illustré avec Continuum et Hudson est faite. En bonus, le chapitre se termine par une section sur lequel choisir?

Commentaire sur le chapitre
Chapitre très progressif expliquant bien les bases des tests. Les détails sur JUnit permettent aux lecteurs qui ne sont pas très technique de bien comprendre de quoi il s'agit et en quoi cela consiste. J'apprécie tout particulièrement le discours très pragmatique et la section sur l'intégration continue. En résumé, il s'agit encore une fois d'un très bon chapitre du livre.

Chapitre 5: Mettre en place des tests d'intégration

Résumé
À travers un exemple d'une application GWT, le chapitre commence par une sensibilisation du temps des tests qui s'allonge au fil du temps. Maven, à la rescousse nous fournit le mécanisme de profils. Ceux-ci permettant de définir des plugins supplémentaires, de nouvelles dépendances ou des projets supplémentaires. Ce mécanisme étant très pratique dans le cadre de tests qui ne sont pas indépendants de l'environnement ou qui sont pénalisant en raison de leur durée d'exécution. Ensuite, le livre nous présente l'autre pendant des profils : s'adapter à l'environnement.
Les possibilités d'activation et de désactivation des profils (depuis la 2.0.10) en ligne de commande sont également vues.

Ensuite, nous retiendrons que la philosophie de Maven est d'éviter que les développeurs passent de longues heures à mettre leur environnement au carré pour pouvoir coller aux attentes du projet.

Le chapitre se termine par une présentation de l'utilisation de Maven avec des frameworks de tests fonctionnels comme Fitnesse et des frameworks de tests de montée en charge comme JMeter.

Commentaire sur le chapitre
Les profils sont souvent utilisés à tord et à travers, ils nécessitent souvent des bonnes pratiques.
L'approche et les cas d'exemples dans ce chapitre, permettent de bien comprendre ce que sont les profils et comment les utiliser aux mieux.

Commentaire personnel sur Maven
A mon avis, les profils doivent être utilisés avec la plus grande parcimonie. Maven est avant tout un outil pour builder des applications Java/Java EE et nombreux sont les efforts fait sur la norme Java/JEE pour réaliser des applications portables, indépendantes de l'environnement. C'est d'ailleurs toujours encore plus vrai à chaque nouvelle version de Java EE, comme par exemple la dernière version Java EE6.
C'est pourquoi, les profils sont à mon avis très utiles pour les tests et des cas de déploiement, mais leurs utilisations a moins d'intérêt pour les autres cas. Mais dans tous les cas, reconnaissons que ce service de profil fournit par Maven est très puissant. A titre d'informations, la plupart des concurrents de Maven ne propose pas ce service nativement, comme le cas de Gradle où la mise en place de profils est assez complexe (Utilisation manuelle de la classe Groovy ConfigSlurper dans ses scripts).

Partie II : Maven en entreprise

Chapitre 6: Gestion avancée des dépendances

Résumé
Cette seconde patrie commence comme le début du livre, c'est-à-dire par un cas concret tiré du terrain. Plus précisément, le chapitre débute par le cas du driver jdbc de Oracle non présent dans le dépôt (repository) central de Maven pour cause de licences. Le chapitre enchaîne tout naturellement sur le besoin de la création de son propre repository privé et de sa gestion. Ensuite nous avons une explication approfondie des métadonnées, et pour en arriver à la présentation du besoin d'un gestionnaire d'artefacts comme Archiva, Nexus ou Artifatcory. Puis la notion de repository virtuel (dépôt unique du point de vue de l'utilisateur) et son attachement dans la configuration Maven est présentée. Le chapitre conclut sur l'importante d'un gestionnaire de repository pour la gestion automatique des métadonnées.

Commentaire sur le chapitre
La gestion des dépendances et la notion de dépôts Maven est très important au sein de l'outil Maven. Ce chapitre est un excellent chapitre de ce livre.

Chapitre 7: Quand le projet devient trop lourd

Résumé
Le chapitre commence directement par l'assertion : «En Maven :Un projet- Un artefact ».
Malgré la notion de classifier, cette règle doit être bien comprise afin de comprendre l'utilité du découpage d'un projet en modules.
On poursuit par la mutualisation de la configuration avec la présentation détaillée de l'héritage dans Maven; comment mutualiser les dépendances, les plugins et leurs configurations dans un projet parent sont vues. Puis son découpage en module spécialisé est présenté et expliqué.

Commentaire sur le chapitre
Le chapitre explique bien la fourniture par Maven du mécanisme d'héritage, comparé aux mécanismes d'inclusions (import) proposés par les systèmes à base de scripts. On apprécie la mention du très utile plugin maven-enforcer-plugin. On peut apprécier également la note sur l'astuce de l'utilisation d'une version inexistante d'une librairie déclarée dans la section <dependencyManagement> afin que la librairie ne soit pas incluse par transitivité.

Commentaire personnel sur Maven
Il est dommage que le mécanisme d'héritage de Maven soit présenté ici comme une solution qui règle tout. D'autres systèmes de build comme Gradle, propose en plus de l'héritage, un mécanisme d'injection de configuration, permettant d'injecter la configuration des modules enfant depuis le parent. Cela facilite la configuration, la maintenance du projet et permet de rendre le descripteur d'un module enfant complètement optionnel.

Chapitre 8: Maven et JEE

Résumé
C'est le passage à l'échelle JEE de l'application fil conducteur introduite dès le début de ce livre.
Le chapitre commence par nous présenter la construction automatisée d'une webapp (war). On poursuit par la construction automatisée d'un EJB et de la configuration Maven additionnelle dans le cas des EJB 3.0. Après avoir construit un war et un ejb, le livre nous présente tout naturellement comment construire un projet d'entreprise (ear) contenant les deux précédents composants.
Le chapitre enchaine sur la présentation de l'outil de test fonctionnel Selenium et de son intégration dans Maven via son plugin. Ensuite, pour tester l'application, il nous faut donc la déployer; Cargo nous est alors présenté et son intégration dans Maven. Le chapitre se poursuit par les problématiques liés à la productivité du modèle JEE: les approches lignes de commandes Maven et IDE sont étudiés. Nous terminons par un exemple de cas de test pour tester des composants EJB3.0 sans Maven afin de montrer que Maven ne peut pas toujours tout faire. En bonus, une aperçu de la simplicité de JEE6 est présenté brièvement.

Commentaire sur le chapitre
Ce chapitre est très long, voir peut-être trop long. Néanmoins, tous les concepts sont présentés avec une approche très progressive.
En revanche, je regrette que la solution de la mise en place d'un module Maven « it » dédié aux tests d'intégration ne soit pas plus présentée en profondeur.

Chapitre 9: Maven et les IDE

Résumé
Le chapitre commence par la présentation du plugin maven-eclipse-plugin (rappelons qu'il a été développé par Arnaud Héritier). Ce plugin permet de générer la configuration Eclipse de son projet depuis Maven.
Ensuite, nous plongeons dans l'état actuel du support de Maven dans les IDE avec Eclipse, NetBeans et IDEA IntelliJ. Pour chacun d'eux, les avantages et les inconvénients sont donnés.

Commentaire sur le chapitre
Chapitre indispensable et très attendu dans le cas d'un livre sur Maven. J'apprécie bien l'approche nous expliquant les difficultés du plugin maven-eclipse-plugin pour satisfaire toutes les variantes de la plateforme Eclipse. J'apprécie tout particulièrement la conclusion du chapitre sur le fait que rien n'est plus productif qu'un développeur avec ses outils dans son environnement.

Commentaire personnel sur Maven
Avec ce chapitre, on voit bien que le support dans un IDE de son système de build est indispensable. Mais on voit aussi que sur un gros projet (par exemple, avec beaucoup de modules), même le support de Maven n'est pas encore complètement satisfaisant, en particulier sous Eclipse.

Et c'est ce point qui est fou, malgré tout l'énorme buz qui peut être fait, le support de Maven dans les IDE, celui-ci n'est pas encore au point. J'ai alors une pensée à tous ceux qui critique le manque de support dans les IDE de Gant ou Gradle. Je leur dirais, premièrement, c'est moins facile car un descripteur Gant ou Gradle, c'est du Groovy (c'est plus facile d'outiller sur du XML). Et deuxièmement, un début du support dans les IDE est déjà opérationnel (en particulier dans IDEA IntelliJ 9) malgré la jeunesse de ces outils de build.

Chapitre 10: Le jour J: la livraison

Résumé
Le chapitre commence par des scénarios de livraisons, puis les auteurs du livre nous amènent tout doucement à se poser la question: est-ce que Maven ne peut pas être utilisé? Le livre nous présente le plugin de livraison Maven, le plugin release (maven-release-plugin). Celui-ci est détaillé avec ses goals prepare, perform et rollback. Ensuite, différentes techniques de staging sont vues. La notion de branches est abordée afin de gérer plusieurs versions simultanément.

Commentaire sur le chapitre
La livraison d'un projet est crucial dans les projets, et ce chapitre a le mérite de fournir des schémas et des explications limpides. On peut apprécier l'astuce pour exécuter le plugin à blanc. En revanche, je regrette que la lourdeur et les difficultés souvent éprouvés par les jeunes développeurs pour la mise en place de ce plugin, ne soit pas exposés. Le plugin n'aborde pas non plus le fait que le plugin marche très bien avec certains gestionnaire de source comme Subversion (certes, très utilisé) mais ne marche pas du tout avec d'autres car le plugin n'épouse pas la même philosophie, c'est le cas par exemple avec Clearcase (en particulier Clearcase UCM).

Partie III: Encore plus loin avec Maven

Chapitre 11: Utiliser un outil non supporté

Résumé
Le chapitre présente la tache d'intégration d'un nouvel outil maison possédant une tache Ant pour l'exécuter. Le chapitre nous illustre tout naturellement le plugin maven-antrun-plugin. Mais les auteurs insistent bien sur le fait que ce plugin ne doit être utilisé uniquement en cas de migration d'un projet Ant vers Maven: dans le cas d'une transition, c'est du temporaire. Ensuite, nous plongeons dans la création d'un plugin Maven, illustré avec le framework d'injection de dépendances Plexus, choisis par Maven 2.x. Pour finir, des exemples de tests d'un plugin Maven sont donnés.

Commentaire sur le chapitre
Je regrette que le livre ne vas pas plus loin dans la présentation du développement d'un plugin. Le livre passe un peu sous silence que la création d'un plugin utilise des annotations JavaDoc car c'est du java 1.4 et que cela ne sera pas le cas avec Java 1.5 (ouf c'est corrigé en Maven 3). Enfin, on peut apprécier les exemples d'écriture d'un plugin en langages Groovy.

Chapitre 12: L'assurance qualité

Résumé
Le chapitre commence par les outils d'audit de code avec une présentation de chacun des ses outils : Checkstyle, FindBugs, PMD, …
Nous rentrons ensuite dans les rapports générés par Maven.
Le chapitre se termine par l'outil Sonar offrant une synthèse des rapports de métriques.

Commentaire sur le chapitre
On peut apprecier l'approche progessif. Le chapitre est très complet et donne une bonne vision globale de la qualimétrie.

Chapitre 13: Respecter un format de distribution

Résumé
Il est d'abord abordé dans ce chapitre la problématique de traçabilité des binaires produits par Maven. La première étape présente l'utilisation dans le nom du jar par le numéro de build produit par le serveur d'intégration continue. Le chapitre se poursuit par la présentation du plugin buildnumber pouvant récupérer le numéro de révision SVN. Ensuite, nous abordons le fichier MANIFEST.MF et son contenu. La signature est jar est également abordée. La notion de assembly et de son plugin maven-assembly-plugin est également vue. Enfin, une brève présentation de OSGI avec en particulier le projet Tycho est donnée.

Commentaire sur le chapitre
Je trouve que l'aspect gestion de version et traçabilité avec le code n'est pas assez développé. Concernant la partie assenbly, on peut vraiment apprécié les très bon exemples et l'approche toujours progressive. En revanche, concernant la partie OSGI, c'est extrêmement décevant. Devant l'enjeu à venir de cette plateforme, je m'attendais vraiment à plusieurs pages, voir à un chapitre entier sur ce sujet.

Commentaire personnel sur Maven
Maven a été conçu et développé pour être un système de build des applications Java/Java EE. OSGI est un autre monde à part. Et donc pourquoi essayer d'adapter Maven à cette norme? Vouloir souder l'outil Maven avec le monde OSGI, n'est-il pas essayer de faire de Maven un outil universel, mais surtout essayer de l'adapter à OSGI? Cela semble contradictoire avec ce qui est dit tout au long de se livre: « Ne pas chercher à plier Maven à des besoins complexes mais plutôt essayer de comprendre comment traiter nos besoins selon la philosophie de Maven. » Une intégration indispensable de Maven et OSGI doit être la capacité de Maven à exploiter des bundles OSGI et à suivre les mêmes mécanismes de gestion de conflit. Cela semble chose faite désormais avec Maven 3. A suivre ...

Chapitre 14: Un nouveau projet démarre

Résumé
Ce chapitre commence par le besoin de réutilisation de projets d'exemple; c'est alors que la notion de archetype Maven et son catalogue est présenté. Ensuite, nous découvrons comment crée une archetype afin de repartir d'un projet existant pour faire office d'application blanche. Le chapitre se poursuit par les intérêts des archetypes.

Commentaire sur le chapitre
Ce chapitre se devait d'être présent. Les justifications de chaque point sont sans ambiguïté.

Commentaire personnel sur Maven
Les archetypes Maven et son vaste catalogue d'archetyps est une des forces de Maven. Ils apportent une vraie plus value, offrant un excellent modèle de point d'entrée pour démarrer un nouveau projet.
Notons que les autres systèmes de build n'offrent pas ce service (au moins, pas nativement).

Chapitre 15: Avons-vous fait le bon choix?

Résumé
Ce chapitre illustre la réponse à la question : Qu'en sera-t-il dans six mois, dans 1an, dans 5 ans?
On commence directement par les faiblesses de Maven:

• syntaxe XML qui peut en rebuté plus de un (malgré la facilité d'intégration dans les IDE).
• Ordre de construction d'un projet muli-modules
• Mécanisme d'expressions

Puis il y a le problème de duplication des métadonnées entre la JSR 277 et Maven ou OSGI et Maven.
S'en suivent une présentation détaillée du support de Maven et son cout.

Sont exposés les solutions:

• ANT/IVY
• EasyAnt
• Gradle
• BuildR

Le chapitre se poursuit sur la maturité de l'outil et la taille de sa communauté.

Puis, il est expliqué les principales features entre les différentes versions de branches 2.x puis les nouveautés de Maven 3. Le chapitre se termine par les sections A qui appartient Maven Typcho dans le détail sur le plan stratégique: open source vs solution commerciale.

Commentaire sur le chapitre
Ouf, enfin!
Un chapitre qu'on attendait tous! On apprécie la présentation des outils concurrents.
Néanmoins, je regrette vraiment que ces solutions alternatives ne soit pas plus approfondies.
Dans tous les cas, c'est le meilleure chapitre du livre. Vous devez le lire absolument.

Chapitre 16: Nos recommandations

Résumé
Ce chapitre présente un ensemble de commandements/recommandations pour la bonne utilisation de Maven sur projets.

Commentaire sur le chapitre
Les explications sont très claires et très détaillées. C'est un chapitre à lire absolument.
En résumé, c'est encore une fois (je me répète) un très bon chapitre de ce livre.

Chapitre 17: Épilogue

Résumé
Ce chapitre fournit un récapitulatif, le mot de la fin puis une présentation des membres francophones de la communauté Maven, ainsi que ceux de la communauté Java.