Critique de Livre : Apache Maven de A. Heritier et N. De Loof


Durant mes vacances d’été en Crête, j’ai eu l’occasion de me dorer la pilule en lisant le livre Apache Maven chez Pearson, écrit par Arnaud Heritier et Nicolas De Loof.
Suivant ces deux zigotos sur twitter depuis début 2010,  et ayant déjà pu lire de bons echos dans la blogosphère java sur le livre,  cela m’a donné envie de le lire.

En terme d’expérience maven, je l’utilise tous les jours depuis maintenant 2 ans et demi en mode « utilisation avancée » (archetypes, poms parent, plugins maison, assurance qualité, industrialisation, intégration continue …) ; j’ai également eu l’occasion, à 4 reprises, de dispenser une formation Maven pour différents clients extérieurs : j’étais donc loin d’être débutant en commençant la lecture du livre et attendais beaucoup de ce dernier : qu’il soit à la fois didactique pour que je puisse le faire lire à des développeurs débutants (de mon équipe) sur le sujet, mais aussi qu’il m’apprenne des choses !

D’autre part, j’avoue avoir peu d’expérience dans la lecture de livres techniques puisque c’est le second livre technique que j’achète (et lit) avec le fameux Design Pattern du Gang of Four. A fortiori, il s’agit là de ma première critique de livre,  j’espère donc ne pas trop faillir dans cet exercice.

La forme (le style)

Je rejoins complètement la plupart des critiques que j’ai pu lire sur ce livre : les deux compères ont su utiliser un mode de rédaction très fluide en relatant l’aventure d’un vieux projet Java ressorti d’un carton jusqu’à son expansion interplanétaire. L’histoire est systématiquement basée sur des cas concrets qui donnent une dimension très pragmatique aux choix entrepris.
En l’occurrence, le livre regorge d’arguments tangibles (et simples !) pour légitimer vos choix auprès des décideurs : je sais que j’irai sûrement piocher dedans pour étoffer mes argumentaires afin de ne pas seulement me baser sur mes convictions personnelles.

L’autre très bonne idée du livre est qu’il fait intervenir différents protagonistes tirés de la réalité de la communauté maven francophone. On peut ainsi avoir rapidement accès à un carnet d’adresses (twitter ?) et connaître ces personnes avec qui on a peut-être déjà eu l’occasion de discuter sur la mailing list maven. Cela renforce énormément l’aspect réaliste du bouquin (et donne un peu, parfois, l’impression de lire un exemplaire de « Public » numéro spécial maven ;-)).

Les choses que j’ai bien aimées

Globalement, le livre m’a appris un certain nombre de choses, entre autres (liste non exhaustive) :

  • Tout le « passif » Maven : ayant commencé à travailler avec Maven 2.0.8, tout ce qui était antérieur à cette version (et notamment Maven 1) m’était inconnu. La présentation de « l’historique » Maven ainsi que les différents composants gravitant autours (Turbine, Tycho, Doxia, Mercury -aujourd’hui remplacé par Aether-) m’a beaucoup intéressé.
  • La présentation M2Eclipse m’a paru instructive. Ceux qui me connaissent savent combien je n’aime pas ce plugin (et notamment son utilisation sur un projet JEE avec le WTP sous eclipse), mais ce que j’ai lu me réconcilierait presque avec ce plugin (cela me donne, en tous cas, envie de tester M2Eclipse lorsque la release officielle de Maven 3 aura vu le jour).
    Dans la même veine, j’ai appris l’existance du sysdeo-tomcat-maven-plugin ainsi que du plugin eclipse développé par Nicolas pour faire en sorte d’utiliser le classpath m2eclipse lors de l’utilisation du plugin sysdeo tomcat (pour ceux qui trouvent que le WTP, c’est quand même vachement compliqué :))
  • La partie Maven dans le monde JEE m’a ouvert les yeux sur un certain nombre de pratiques que je pouvais rendre à priori beaucoup plus simples dans mes builds. Il faudra que je tente un refactoring à mon retour de vacances, pour voir si les plugins war/ejb/ear sont bien utilisés sur mes projets.
  • J’ai complètement découvert la partie injection de dépendances avec Plexus dans les plugins (manque de bol, la dernière release de Maven 3 beta 3 laisse tomber Plexus au profit de Guice, mais qu’importe : les principes resteront les mêmes je pense).
  • J’ai bien aimé la partie « comment bien tester vos plugins maven » : tester un plugin maven est assez compliqué puisqu’il s’agit de tests très proches de tests d’intégration. Cette section donne quelques billes pour bien tester ses plugins maisons. Je pense que je tenterai une mise en application lors de mes prochains travaux sur un plugin maven.
  • Je ne connaissais pas la subtilité entre <pluginManagement> et <reporting> (les infos de <pluginManagement> ne sont utilisées que dans le tag /project/build/plugins/ … et pas du tout dans /project/reporting/plugins)
  • J’ai découvert le build-number-maven-plugin qui permet, entre autres, de persister les informations de révision SVN et de numéro de build (de votre IC) au niveau de votre MANIFEST.MF notamment (très bon outil pour de la traçabilité de livrables).
  • Le chapitre 15 (« Avons-nous fait le bon choix ? ») dresse une photo assez objective de l’ensemble des points négatifs de maven. Une bonne source d’information pour pouvoir discuter avec les décideurs et comparer avec d’autres outils de build du marché.
  • Une subtilité que je ne connaissais pas du tout : la possibilité d’utiliser le « ! » au niveau du pom pour dire « mon profil est activé si la propriété ‘toto’ n’est PAS définie ». Très intéressant typiquement pour désactiver/activer des éléments du pom lors de l’utilisation de m2eclipse.
  • J’ai apprécié les exemples de code permettant l’utilisation de cargo pour déployer sur un serveur d’application. Je ne connaissais que très peu cargo avant de lire le livre, l’exemple paraît complet (mais fonctionne pour tous les serveurs d’application sauf… Websphere :'()

Et l’aspect didactique dans tout ça ?

C’est bien beau de lister toutes les choses que j’ai pu apprendre, mais est-ce qu’un néophyte Maven s’y retrouverait ?
Je ne peux malheureusement pas répondre à cette question (il faudrait la poser directement à un néophyte..), en revanche, la première partie du livre me paraît très exhaustive (à quelques points prêt, cf le chapitre « axes d’amélioration ») et permet, à mon avis, de plonger dans le bain de maven assez facilement/rapidement.

J’ai également bien aimé le chapitre sur l’assurance qualité -qui sort un peu des sentiers battus du sujet du livre-  qui offre la vision d’une « killing software factory » avec le quadruplet Maven/Nexus/Hudson/Sonar. C’est le quadruplet très en vogue aujourd’hui, et le bouquin explique pourquoi.

Axes d’amélioration

Pas de critique sans points à améliorer (peut-être, dans une seconde édition ? ;-)) :

  • J’ai trouvé dommage que l’aspect « settings.xml : qu’y met-on ? » ne soit pas abordé au niveau du livre. Globalement, je trouve qu’on ne parle que très peu du settings.xml (j’aurais eu une version électronique entre les mains, je me serais amusé à chercher le nombre d’occurrences au settings.xml … je pense qu’en 260 pages, le mot doit arriver une dizaine de fois dans la discussion).
    Il est dommage que le sujet ne soit pas abordé puisqu’il pourrait toucher un certain nombre de problématiques : la notion des id de serveur (personnellement, j’ai mis un certain temps à comprendre qu’un id de repo utilisait le même id de server pour l’authentification !), l’encryptage des mots de passe, la déclaration des repositories, quoi ne pas mettre dans un settings.xml…
  • La notion de SUPER-POM n’est jamais abordée dans le livre, ce que je trouve dommage car il s’agit là d’une notion à connaître pour être en mesure d’évaluer les impacts de migration d’une version de maven à une autre (c’est notamment ce super pom qui a changé dans la version 2.0.9 lorsque les versions de plugin ont été figées pour rendre le build reproductible si ces dernières n’étaient pas définies à la main dans vos pom persos).
  • La chose qui m’a le plus déçue personnellement (car je m’attendais à avoir des réponses à mes questions en lisant le livre) : le fait que la partie « création d’un lifecycle maison » ne soit pas abordée. Peut-être est-ce dû au fait que Nicolas et Arnaud voulaient rester dans la philosophie de maven à savoir « on essaie de donner le moins de billes possibles aux utilisateurs sur ce sujet, car il s’agit d’un sujet contre nature dans maven », mais je reste tout de même sur ma faim sur ce sujet là, et je vais devoir continuer à aller inspecter les rouages des maven-release-plugin et packaging swf pour pouvoir comprendre comment définir un lifecycle perso / un packaging perso dans maven.
  • Il est dommage que des plugins comme le build-helper-maven-plugin (permettant, notamment, d’avoir plusieurs répertoires de sources, ressources, tests etc…), le maven-help-plugin (dont le goal effective-pom est absolument indispensable pour débugger), le maven-versions-plugin (très utile pour changer à grande échelle un numéro de version dans un projet multimodules) ne soient pas présentés.
  • A la fin de la lecture du livre, je ne sais toujours pas si l’ordre de plugging des plugins sur une phase est censé être prédictif ou non
  • Dans la partie plugin, il aurait été intéressant de souligner qu’un plugin pouvait être pluggé sur une « phase par défaut » (qui permet d’éviter la déclaration de la balise /project/build/plugins/plugin/executions/execution/phase), car l’ensemble des exemples omet le tag <phase> (et utilise donc la « phase par défaut » du plugin) => souligner la subtilité aurait été intéressant.
  • J’ai trouvé dommage la contradiction entre « utilisez le moins possible le tag <optional> dans vos dépendances » (au niveau du chapitre « nos recommandations ») et le hack proposé dans le chapitre « Maven et JEE » où, pour pouvoir mutualiser des librairies dans le projet EAR, on utilise justement des dépendances optional.
    Personnellement, j’utilise plutôt un autre workaround qui consiste à définir un artefact « common-dependencies » de type pom dans lequel je positionne toutes mes dépendances communes en scope compile.
    Je dépends ensuite de cet artefact :

    • En scope provided au niveau de mon projet Web
    • En scope compile au niveau de mes projets EJB et EAR

    Seul inconvénient de cette approche : les « vraies » dépendances provided (type j2ee.jar) ne doivent pas être positionnées au niveau de l’artefact « common-dependencies » mais directement au niveau de chaque artefact qui en a besoin (EJB et Web typiquement). Ceci à cause du fait que si on a : A –[provided]–> B –[provided]–> C, C n’est PAS tirée en tant que dépendance (provided) transitive de A.

  • Concernant le plugin M2Eclipse, j’ai été un peu déçu de voir l’aspect « monde des bisounours » de ce plugin compte tenu du nombre de problèmes que j’ai rencontrés avec. Suis-je le seul à avoir du mal à faire du WTP avec M2Eclipse ? (peut-être est-ce dû au WTP Websphere de RSA ?).
    Le récent tweet de Jason a ce sujet ne me rassure pas spécialement en terme de « force de frappe » : l’intégration WTP me paraît être un must-have de m2eclipse (je serais curieux de connaître la proportion de projets maven JEE par rapport aux projets maven Java…) et Sonatype, depuis le début, sous-estime l’importance de cette fonctionnalité.
  • J’ai détecté une erreur subtile dans l’astuce de la page 224 où il est question d’héritage du numéro de version du <dependencyManagement> dans les dépendances du projet : lorsqu’une version est positionnée au niveau du <dependencyManagement>, cette version est utilisée uniquement si elle n’est pas positionnée dans la section <dependencies>. S’il s’avère qu’une version différente est positionnée au niveau de la section <dependencies>, c’est cette dernière qui prévaut par rapport à celle du <dependencyManagement>.
  • J’aurais bien aimé savoir comment Nicolas et Arnaud font pour faire cohabiter plusieurs versions de maven sur une même machine et, rapidement, dans l’invite de commande, pouvoir switcher de l’une à l’autre (sans devoir aller systématiquement trifouiller le PATH, ce qui prend quand même un peu de temps).

Pour conclure …

Que la partie « Axes d’amélioration » de mon post ne vous fasse pas peur : le livre Apache Maven d’Arnaud et Nicolas est un must-have que vous soyez expert ou non dans l’utilisation de Maven.

Ils ont su traiter un nombre conséquent de sujets liés à Maven, et ce, dans une prose très agréable à lire.

Je ne saurais que trop vous encourager à vous procurer le bouquin : les 32 euros ne seront pas jetés par la fenêtre !

Publicités

2 Réponses to “Critique de Livre : Apache Maven de A. Heritier et N. De Loof”

  1. Laurent Forêt Says:

    Je ne comprends pas les raisons pour laquelle tu fais un distingo de scop entre tes ejb et tes war ? Si tes dependances sont fournirs par ton serveur por ta webapp elles sont fournies pour ton ejb , non ?

    • Frédéric Camblor Says:

      Je suis d’accord avec toi, j’ai même failli mettre « pour le projet EJB, c’est comme vous voulez : provided ou compile, comme bon vous chante ! »
      Le laisser en scope compile donne l’avantage que le MANIFEST peut alors être généré … mais induit du coup une incohérence de comportement entre Web et EJB (tantôt le MANIFEST est généré automatiquement, tantôt il doit être édité à la main via l’IDE par exemple).


Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :