Chapitre 18
Le dernier numéro de Fortune vient de paraître. Dans son grand dossier central, il présente le projet Geegol Shopping List dont la réussite est inversement proportionnelle à l’effort de développement qui lui a été consacré. L’article met en avant les qualités hors du commun de l’équipe de développement, de quoi faire baver tous les directeurs informatique de la planète. Nous ne comptons plus les offres d’emploi, que nous recevons par centaines chaque jour, toutes plus appétissantes les unes que les autres.
Image the end.jpg alignée au milieu
Dans la vraie vie, les choses sont souvent moins roses. Les contes de fées et les histoires fantastiques sont malheureusement réservés à nos enfants. Pourtant, Maven peut tout de même nous aider à conduire nos projets dans de bonnes conditions, même ceux qui ne sont pas de merveilleuses prouesses technologiques ou le sujet d’enjeux stratégiques.
Bien que quelque peu embellie, l’histoire que nous venons de raconter est tirée de situations réelles, que nous avons tous vécues à un moment ou à un autre de nos carrières sur divers projets. Dans chaque cas, la plupart de nos problèmes étaient liés à un manque de rigueur dans notre outillage ou alors à un défaut de maîtrise de ce dernier. Reposant sur les qualités individuelles ou sur les connaissances de quelques personnes, un projet peut vite tomber dans la tragédie à l’occasion d’un congé (volontaire ou non). Maven est un catalyseur pour structurer les développements autour d’un outil unique et d’une conception simple et homogène du projet.
Maven ne serait pas ce qu’il est sans les efforts de toute son équipe. La communauté francophone y est largement représentée avec Arnaud, Carlos, Emmanuel, Fabrice, Hervé, Lukas, Nicolas, Olivier, Raphaël, Stéphane et les deux Vincent. Tous, à leur niveau et à des moments différents de leur parcours professionnel, ont mis un doigt dans le monde open-source et en sont maintenant imprégnés. Maven ne serait pas ce qu’il est non plus sans Antonio, François, Guillaume, Sébastien, Jérôme et les millions d’autres personnes qui chaque jour l’utilisent, participent à son support, débattent de son avenir, rapportent des anomalies et proposent des correctifs.
Maven est avant tout une très large communauté de développeurs, son cœur ne servant que de centre gravitationnel pour une galaxie entière de plugins. Certains sont structurés autour de la communauté via le projet Mojo, d’autres vivent leur vie indépendamment. Tous contribuent à faire de Maven un outil toujours plus riche.
Maven devient peu à peu un outil stratégique en entreprise en apportant enfin une homogénéité aux développements. Un développeur peut passer d’un projet à l’autre, voire d’une entreprise à l’autre, sans remettre fondamentalement en question ses habitudes de travail. L’expérience aidant, les équipes de développement apprendront à mieux utiliser les outils que Maven permet de greffer en quelques lignes de configuration sur n’importe quel projet.
Certains parlent d’industrialisation du développement, d’autres simplement de renoncer à des pratiques qui tiennent du pur bricolage. Anecdote :
Nicolas, en tant qu’expert Maven, est consulté pour un projet en tierce maintenance. La procédure de compilation est la suivante :
"Lancer la commande ant jar. La construction échoue, c’est normal. Démarrer Eclipse, attendre un certain temps puis quitter Eclipse. Lancer alors à nouveau ant jar."
Cela semble complètement délirant, mais c’est écrit noir sur blanc dans un document officiel – document qui est parfaitement conforme à toutes les normes qualité ISO 9001, AFAQ et compagnie ;).
Pour la petite histoire, le projet comprend une classe qui ne compile pas (elle fait référence à des classes inconnues). Le compilateur exécuté par ant échoue, alors qu’Eclipse produit tout de même un fichier .class (incomplet). Le compilateur ne cherchant pas à recompiler une classe déjà compilée, le deuxième passage de ant produit le résultat désiré. Heureusement, cette classe est du code mort non utilisé, mais tout de même !
Que retenir de ce cas extrême, mais qui vous rappelle peut-être des situations qui ne vous font pas honneur ? Simplement que le processus de construction du projet est un élément majeur de l’organisation de votre travail. Utiliser un mécanisme instable, dépendant de l’environnement ou de manipulations manuelles, c’est forcément s’exposer à des problèmes à un moment ou à un autre, en général le vendredi soir juste avant votre départ en vacances. Maven ne résoudra pas tous vos problèmes, mais il vous fournit un socle pour bâtir des solutions.
Pour conclure, sachez que le Definitive Guide, ouvrage communautaire traduit dans de nombreuses langues (la version française est en cours de réalisation à l’heure où nous rédigeons ces lignes), est lui-même rédigé puis assemblé via Maven. Pour produire les 500 pages du PDF que vous pouvez consulter en ligne[71], il suffit de lancer la commande universelle mvn install !
Vous vous demandez qui sont ces personnages qui peuplent les pages de ce livre ?
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).
Carlos Sanchez, espagnol, 31 ans.
Je travaille pour MaestroDev après avoir travaillé chez Mergere / DevZuz, en donnant des services professionnels au-dessus de Maven/Continuum/Archiva. J’ai encore pour nos clients beaucoup de travail avec ces produits. J’ai commencé avec le projet Maven en 2004, en participant au développement des plugins, du noyau et en gérant le repository central. Après, j’ai contribué aux autres projets open-source, Apache Archiva, Continuum et Felix, Spring Security, Eclipse IAM… Maintenant, je travaille sur des projets liés au cloud computing et DevOps, et en tirant le plus grand avantage de celui-ci pour le développement logiciel, les tests et les bonnes pratiques.
J’habite à La Corogne, Espagne où j’ai étudié le français, et je suis allé en France de nombreuses fois : Pyrénées, Alpes, Bretagne, Paris. Mais j’ai beaucoup oublié mon français en parlant toujours en anglais :(.
Salut,
Emmanuel Venisse, 37 ans.
Je suis free lance depuis 2005, tout d’abord pour Mergere/DevZuz avec nos autres amis de la communauté Maven, mais depuis fin 2007, pour divers clients avec notamment la mise en place d’environnement de build (Maven/Continuum/Archiva) et de l’architecture logicielle.
Je suis committer sur Maven depuis les premières bêta en 2002 (merci à Vincent Massol de m’avoir présenté Maven à cette époque), mais également Continuum et Archiva. Malheureusement avec de moins en moins de temps disponible maintenant :-(.
Dans le passé, j’ai travaillé dans la même SSII que Nicolas, mais à Paris où j’avais introduit également Maven ;-).
Hey !
Fabrice Bellingard, la trentaine, Hyérois depuis peu… Je suis tombé dans l’open-source quand j’ai bossé chez OTI (maintenant IBM Ottawa Lab) en 2001, dans l’équipe Eclipse Core où j’ai fait la première version du plugin Ant. J’ai ensuite fait beaucoup "mumuse" en développant tout plein de plugins (notamment créateur du plugin C# et committer du plugin Checkstyle), mais pas forcément tous utiles ;-).
Utilisateur Maven depuis 2003, j’ai choisi Maven en 2004 pour créer la plateforme d’intégration d’un grand groupe français, et je suis finalement devenu committer en 2005. Puis vint Archiva en 2008 (committer et PMC). Tech lead du projet open-source Squale à partir de 2008, j’ai décidé fin 2010 de continuer toujours plus dans le domaine OSS et qualité logicielle en intégrant la société Sonar Source en tant que VP Project Manager. Aventure qui m’emmène bien plus loin que prévu : je bosse sur le coeur de Sonar, mais aussi sur les plugins C#, voire… Cobol ! Si on m’avait dit un jour que l’OSS m’amènerait à Cobol… ;-)
Côté personnel : passionné avant tout par la nature, j’ai passé les vingt premières années de ma vie à Limoges, c’est pour dire ;-). Bénévole WWF et ambassadeur de l’ONG Planète Urgence : ma vraie passion, c’est la protection de l’environnement et la solidarité internationale.
Hervé Boutemy, j’ai 39 ans, une femme et une fille, et je vis du côté de La Défense en région parisienne.
Je travaille depuis onze ans dans un grand groupe bancaire français. J’ai débuté par un stage de R&D sur Java (avant la 1.0, des applets sur Netscape, optimisées pour un modem 14.4K…) pour aujourd’hui outiller de grands projets stratégiques, avec des équipes réparties à l’international, des accès mainframe, du couplage téléphonie informatique, des progiciels et autres subtilités de la réalité d’un SI bancaire.
Si Maven 1 est resté au stade de test sur un projet open-source perso, j’ai eu suffisamment confiance en Maven 2 pour vouloir l’intégrer en entreprise. Disposant d’un build Ant existant standardisé et très diffusé, mon choix s’est porté sur les Maven Ant Tasks. Elles étaient plutôt boguées, et cela a donc été l’occasion de proposer des patchs et de découvrir l’envers du décor : beaucoup de code, beaucoup de gens intéressants et pointus. Mais finalement beaucoup d’endroits aussi où il reste des choses à faire. Je suis donc devenu committer en 2007 puis j’ai été intégré dans le PMC en 2008.
Après les Maven Ant Tasks, je me suis concentré sur la gestion de l’encoding (pour ne plus avoir mon prénom mutilé par Maven), puis Modello. Un petit passage par Doxia pour aider Vincent S. et Lukas : l’expérience technique s’accompagne de rencontres humaines des plus variées.
Ce livre original est un exemple de plus de toute la richesse de la communauté francophone autour de Maven.
Salut à tous,
Je m’appelle Lukas Theussl, 38 ans, autrichien et depuis pas très longtemps résidant en Autriche à Vienne. J’ai aussi une petite famille, une femme et deux enfants.
Côté boulot, je crois que je suis le seul membre non informaticien parmi tous les committers de Maven et je me suis toujours considéré comme un outsider. Après une thèse en physique théorique (spécialité physique nucléaire et particules élémentaires), j’ai passé plusieurs années dans des équipes de recherche, en France, en Espagne, au Danmark et au Canada. Actuellement, je ne fais plus la recherche moi-même, je suis dans l’administration de l’Academie des Sciences Slovaque à Bratislava et je m’occupe de la gestion des divers projets de recherche (européens et internationaux).
Comment un physicien est arrivé à s’implanter parmi les développeurs de Maven ? À l’époque, on écrivait un programme d’application en physique des particules, et on a décidé d’utiliser Maven qui était assez nouveau à ce moment-là. J’ai été surtout attiré par la possibilité de gérer le programme et la documentation (site web, pdf) en même temps, mais très vite les divers bogues m’ont amené à corriger Maven lui-même et à soumettre ces patchs, qu’Arnaud avait la volonté d’appliquer. Le reste, c’est l’histoire… J’ai ensuite aidé Arnaud à enterrer Maven 1.1, et maintenant je participe surtout au sous-projet Doxia et particulièrement à la version du plugin pdf pour Maven 2.
Bonjour,
Olivier Lamy, bientôt 38 ans (une femme et trois enfants).
Amateur de bons plats et de bons vins :-). Je suis employé par Talend (depuis le 1er Août) dans l’Apache Team. J’ai introduit Maven (en version 0.7 bêta pour ce que je me souviens) fin 2002 dans mon ancien emploi (groupe hôtelier Accor).
Au début, dans les projets dont j’avais la charge mais après je fus en quelque sorte "support" Maven dans le groupe. J’ai commencé par Continuum (à l’époque où c’était un sous-projet de Maven) et un jour Emmanuel en a eu marre de committer mes patchs et m’a donc proposé de rejoindre l’équipe.
Maintenant, je me consacre :
-
aux plugins Maven (un peu au core pour la 3.x notamment la réécriture du site plugin)
-
intégration de Maven dans le serveur d’intégration continue Jenkins.
-
et puis d’autres trucs :-) (Maven scm, divers mojo chez codehaus)
J’ai 37 ans. J’ai commencé à utiliser Maven 1 en 2002 ou 2003 (je ne me souviens plus), et pour Maven 2 depuis sa bêta 1.
Voilà. Je suis très pénible pour la typographie bien que je fasse un bon tas de fautes d’orthographe.
Je dispose à la maison du Lexique des règles typographiques en usage à l’Imprimerie nationale – 3e édition. Nicolas, je peux te le prêter en cas de besoin ;).
J’ai 33 ans depuis peu, je vis dans une région magnifique à l’est de la Belgique.
Je travaille comme expert technique chez un grand éditeur de progiciels financiers, où je suis responsable de l’évolution des frameworks et de l’infrastructure logicielle. Je m’intéresse aussi fortement aux techniques et outils de développement, ainsi qu’à la qualité logicielle
Mon premier contact avec Maven date de 2003, j’ai commencé à contribuer au développement de Maven 1 en travaillant sur les plugins liés aux délivrables J2EE. Je fais partie du Project Management Commitee de Maven depuis 2006, je m’occupe toujours des plugins de packaging, mais également des aspects de flexibilité et de configurabilité d’un projet.
Bon puisqu’on dit notre âge je me lance… 40 ans :) [le premier qui dit papy se prend une baffe], amateur de tondeuse robot (choupette va fêter ses 5 ans), boit maintenant de d’alcool (et oui tout chose arrive !), vit à la campagne et travaille depuis la maison, du côté de Chantilly avec femme et trois enfants…
Onze ans d’open-source déjà : Maven, Cactus, Cargo, MockObjects, XWiki et autres.
Côté Maven, j’ai rejoint le projet vers 2001-2002 alors qu’il n’existait que sous la forme d’un sous-projet de build du projet Jakarta Turbine. D’abord en tant qu’utilisateur (j’en avais marre de maintenir des dizaines de fichiers Ant de mille lignes de long chacun !), puis en tant que committer plus tard afin de rendre l’utilisation de Maven plus solide et d’ajouter des fonctionnalités manquantes, notamment au travers du développement de plugins (plus de détails sur http://massol.net). Plus tard, j’ai participé aux longues discussions de design sur Maven2…
J’ai (co-)écrit trois livres dont deux sur Maven : JUnit in Action, aux éditions Manning, Better Builds with Maven publié par l’ex-Mergere (maintenant Exist) et Maven : A Developer’s Notebook, publié par O’Reilly.
Depuis 2007, j’ai décroché du projet Maven (plus le temps) car je me suis donné corps et âme à un nouveau projet open-source: XWiki[72], un wiki d’entreprise de deuxième génération (voire troisième ;)). J’y bosse la nuit (classique), mais aussi le jour (moins classique) puisque je suis directeur technique de la société XWiki SAS qui offre des services, du support et du développement spécifique au-dessus du projet open-source XWiki.
J’avais passé le cap de l’âge du Christ au début de l’aventure de la première édition de ce livre, soit 21 en hexadécimal ; d’accord, c’est très geek, mais avouez que ça rajeunit :). Pour la deuxième édition j’ai arrété de compter.
Français d’origine, je vis actuellement à Montréal au Canada avec une fabuleuse femme. Sans enfant au début de la rédaction du premier opus, je me suis retrouvé père d’un petit garçon (le plus beau, bien sûr !) à sa sortie. Aujourd’hui il a 20 mois… et c’est toujours le plus beau !
Avec presque dix ans d’expérience en entreprise, je travaille actuellement dans un centre de recherche et ma mission se résume à aider les entreprises dans les méthodologies agiles, la gestion de projet, l’assurance qualité, les nouvelles technologies et, bien sûr, l’open-source.
Concernant Maven, j’ai commencé à utiliser la version 1 vers le milieu 2003, lors d’un mandat dans une entreprise de bioinformatique, après une implémentation fastidieuse de la fourmi. Ensuite, parcours classique chez ASF : patchs acceptés (merci Arnaud !), committer, PMC (merci Brett !), utilisation de Maven dans d’autres projets d’ASF (PMC Shindig), etc. Mon intérêt pour Maven se situe principalement dans la génération de documentation (Doxia avec Lukas !) et les plugins de reporting et de QA.
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.
J’ai le même âge que Vincent M. mais tout le monde me donne l’âge de Fabrice. Le secret de cette fontaine de jouvence ? Maven ! Eh oui, chaque mvn install vous fait gagner du temps, donc, plus je compile avec Maven, plus je rajeunis. Vous avez lu le Portrait de Dorian Gray ? Eh bien, lisez un de mes livres, voire les deux (Java EE 5, aux éditions Eyrolles, et Java EE 6 chez Apress) et vous paraîtrez plus jeune. Il y a aussi ma fille de six ans qui adore Maven… en effet, puisque je gagne du temps avec Maven, eh bien j’en passe plus à jouer avec elle. Vous voyez, Maven, on l’aime de 7 (6 pour ma fille) à 77 ans (si vous connaissez quelqu’un qui a 77 ans, proposez-lui de découvrir Maven, il en sera réjoui).
Consultant indépendant et Java Champion, je suis tantôt architecte ou développeur, chez mes clients (de la startup à la grande entreprise). Non, non, je ne suis pas chef de projet. J’ai découvert Java en 1998, puis J2EE en 1999 lorsque je travaillais pour BEA Systems, et j’ai continué dans la lancée de l’Enterprise Edition (ou Java EE) jusqu’à intégrer le JCP en travaillant sur la spécification Java EE 6 et aujourd’hui Java EE 7. Après avoir travaillé partout dans le monde (enfin, trois ou quatre pays), je suis revenu à Paris (intra-muros,__bien sûr), où j’ai commencé à enseigner au Cnam puis créé le Paris Java User Group. J’ai écrit plusieurs articles, deux livres (je l’ai déjà dit, mais c’est pour que vous vous souveniez de les acheter), je parle pas mal aux conférences (je parle beaucoup de manière générale) et j’adore Maven (ça, c’est pour Nicolas et Arnaud). Je fais aussi partie de la bande des Cast Codeurs. Quoi ? Vous ne connaissez pas les Cast Codeurs ? Eh bien, retrouvez tout cela sur mon site personnel pour de plus amples informations : http://www.antoniogoncalves.org.
Brestois d’origine, parisien d’adoption, j’ai connu le Minitel mais je suis plus jeune que Vincent M., j’ai commencé à jouer/coder sur le HP 85 de Papa dans les années 80. Depuis 2007, je suis ingénieur logiciel chez Adobe, après neuf ans d’expérience dans le développement d’application Java/JavaEE chez Schlumberger puis AtosOrigin Open Source Competence Center.
Si, depuis plusieurs années, j’utilise Maven sur la plupart de mes projets (y compris mes projets hybrides, Flex et Java), c’est à cause de Vincent M., d’Arnaud et des autres contributeurs que j’ai eu la chance de rencontrer (à JavaPolis, à l’OSSGTP, au ParisJUG, ou à un comptoir) : leur enthousiasme et leur passion sont en effet contagieux…
PS : je suis également l’auteur d’un blog technique autour des technologies Java et Flex (http://www.droff.com).
J’ai 30 ans et je travaille depuis 3 ans chez Zenika en tant que consultant et formateur sur les technologies Java/JEE. Spécialiste du build, je suis aussi en charge du pôle Intégration continue et j’interviens chez de nombreux clients pour la mise en place en place de l’intégration continue. De plus, j’occupe une grande partie de mon temps professionnel et personnel à contribuer au serveur d’intégration continue Jenkins.
Concernant les outils de build, j’ai débuté avec Ant dans les années 2000 et mon aventure Maven en 2005 comme utilisateur de Maven 1. En 2006, j’ai mis en place Maven 2 pour l’ensemble des projets au sein d’une grande banque Française. Couplé à Continuum, cela convenait à l’époque parfaitement aux différents besoins.
Mais c’est en 2008 avec mon nouveau client industriel qu’il a été mis en lumière toutes les limitations de Maven et l’impossibilité de mettre en place avec Maven une solution simple pour des besoins très spécifiques et complexes. J’ai alors très vite investi sur le nouveau né des outils de build, le système Gradle. Il procure puissance, souplesse de mise en place, performance et conserve des scripts faciles à maintenir.
Au fil du temps, de plus en plus convaincu par les concepts, je suis devenu évangéliste de Gradle en France, à travers l’écriture d’articles et l’animation de conférences. Cependant, je reste très actif dans la communauté Maven en réalisant de nombreuses missions de conseil et des formations sur cet outil et son écosystème.
Au dernier compte, j’en arrivais à 34 ans, déjà.
Je fais de l’open-source depuis 2003, en travaillant puis en dirigeant le projet Groovy, le langage dynamique pour la JVM le plus populaire actuellement auprès des développeurs Java, et également en lançant le framework web Grails.
Après quelques années chez des éditeurs logiciels et des sociétés de services, je me suis lancé, j’ai créé ma boîte, G2One, autour des technologies Groovy et Grails, qui a ensuite été rachetée par SpringSource, et ce dernier par VMWare – un bel exemple de chaîne alimentaire ou des poupées russes !
J’ai beaucoup souffert avec Maven 1, mais je n’ai pas eu beaucoup l’occasion de jouer avec Maven 2, seulement avec le plugin GMaven qui rend Maven un peu plus agréable à utiliser à mon goût ! Mais j’espère que ce livre rabibochera les développeurs allergiques à Maven avec ce puissant outil de build !
29 ans, architecte JavaEE chez Octo Technology depuis cinq ans, où j’ai rencontré Arnaud et découvert Maven (la version 1.0.2 à l’époque).
Ni commiter, ni PMC, je suis un simple utilisateur mais fervent défenseur de l’outil. J’ai mis en place plusieurs "usines de développement" (intégration continue, tests et bonnes pratiques autour de tout ça), dispensé des formations chez divers clients, écrit quelques articles sur le sujet et surtout j’utilise Maven au quotidien ! La version 1 m’avait paru intéressante comparée à Ant mais c’est surtout la version 2 et toutes ses conventions qui me semblent apporter énormément au développement !
Pascal peut être défini avant tout comme un scientifique passionné d’Histoire. En tant que professionnel, il est freelance et fondateur de opensagres (en mémoire de la « Fort de Sagres », l’un des premiers centres de recherche de l’humanité).
Ses principaux centre d’intérêts et compétences sont Maven, Eclipse RCP, Spring et OSGi. Il essaie de OSGi-fier tous les modules java utiles présents dans notre galaxie
Une de ses principales qualités est son insatiable curiosité.
Breton d’origine, je vis actuellement à Casablanca avec ma petite tribu familiale.
Après douze ans d’expérience en entreprise dans des domaines fonctionnels et techniques variés, je travaille actuellement sur un projet Java/J2E où Maven est largement mis en œuvre (merci Nico ;-)).
Quand j’ai installé mon environnement, la consternation :
<mode panique : on>
– "Hou là là ! Mais j’ai plein de téléchargements étranges quand je lance une commande Maven !"
– "Mais c’est quoi ces fichiers pom.xml partout dans mon workspace ? En plus, j’y comprends rien, moi, à ces fichiers."
– "Argh ! Mais ils sont passés où les fichiers build ?"
– "Comment ça, on a abandonné Ant ? Mais pourquoi on a abandonné Ant ? J’aimais bien moi Ant et en plus je comprenais !"
– "Au secours Nico !!!!"
<mode panique : off>
Par conséquent, pour moi (et donc pour Nico), ce livre est une bénédiction :-).
Je ne remercierai jamais assez Arnaud d’avoir accepté de m’accompagner dans cette aventure. Écrire un livre sur Maven sans en faire un pavé inintéressant n’était pas une mince affaire. Il a su protéger ce récit des appels si tentants du côté obscur de la force.
Merci à Pearson et en particulier à Patricia de nous avoir donné notre chance pour ajouter un titre à la trop courte liste des ouvrages écrits dans la langue de Molière.
Merci aussi à tous les membres de la communauté Maven qui ont participé de près ou de loin à la relecture de cet ouvrage et nous ont suggéré de nombreuses améliorations. Leur aide et leur ténacité ont été un excellent moteur.
Merci enfin à mes p’tits loups qui supportent que leur papa passe tant d’heures devant son écran, ainsi qu’à l’ange qui m’accompagne et ensoleille chaque jour ma vie.
Je remercie grandement Nicolas de m’avoir proposé ce challenge. Le manque d’une bonne documentation en français sur Maven me titillait depuis des années. Il faut avouer que nous ne sommes pas vraiment reconnus pour notre bon niveau en anglais, et cela se voit sur le terrain. Cependant, je n’aurais jamais eu le courage de me lancer tout seul. Je le remercie encore plus pour la quantité de travail qu’il a abattu (l’essentiel en fait). Je suis très fier de cet ouvrage qui est bien différent de ce que l’on peut voir d’ordinaire dans la lecture spécialisée. J’espère que vous prendrez autant de plaisir à le lire que nous en avons eu à l’écrire.
Merci à notre éditeur Pearson, et à son équipe, Patricia, Amandine, Laurence, Jennifer et tous ceux qui nous ont accompagnés dans cette première expérience en tant qu’auteurs. Il faut avouer que, pour des geeks comme nous, sortir la plume $ "la plume" en texte barré, SVP$ le traitement de texte (en plus celui de Bilou !) et en faire l’ouvrage que vous tenez dans les mains est un véritable exploit.
Merci à nos relecteurs et à toute la communauté Maven. Particulièrement à ses membres francophones qui ont pu trouver le temps de nous épauler pour faire de cet ouvrage une œuvre de qualité.
Enfin, je dirai un grand grand grand merci à mon exceptionnelle femme et à mes trois enfants qui supportent autant que possible le temps que je peux passer sur l’open-source et ces derniers temps sur cet ouvrage.
Chapitre 19
Ami lecteur, tu es arrivé jusqu’ici et notre récit te laisse un goût amer de "mais enfin, de quoi parlent-ils ?". Il est vrai que l’informatique possède un jargon riche, souvent impénétrable et anglophone… Voici donc notre petit dictionnaire Maven – Français.
Apache[73]
La fondation Apache (ASF, Apache Software Foundation) est un organisme américain à but non lucratif qui héberge les infrastructures pour le développement de nombreux logiciels libres, dont le très célèbre serveur HTTP Apache. La fondation encourage la constitution d’une communauté pour soutenir un projet donné plutôt que les pures qualités techniques de celui-ci, même si elles font rarement défaut - des centaines d’yeux braqués sur le code sont une bonne garantie de qualité ! Les responsabilités dans un projet Apache sont basées sur le concept de méritocratie : un membre actif, talentueux et respectueux de la diversité de la communauté se verra attribuer plus de responsabilités et de titres (Committer PMC), jusqu’au titre suprême de membre de la fondation Apache.
Committer[74]
Le monde open-source identifie les personnes qui ont un accès libre en modification sur un projet comme committer, c’est-à-dire autorisé à effectuer un commit sur le gestionnaire de code source du projet. Ce statut est accordé aux membres actifs du projet qui ont démontré en tant qu’utilisateurs avertis leur bonne connaissance technique ainsi que leur capacité à collaborer dans le respect de leurs pairs.
JIRA[75]
La société Atlassian propose aux fondations qui hébergent des logiciels
libres une licence gratuite de son outil de gestion de tâches et
d’anomalies, JIRA. Cet outil est une application web très conviviale qui
permet de suivre les actions en cours sur le projet et d’interagir avec
l’équipe de développement. Si vous rencontrez des comportements
anormaux, faites une recherche préalable sur le projet JIRA de
Maven[76] ainsi que sur ceux des
plugins[77]. Vous pouvez d’ailleurs contribuer aux
corrections par ce biais, en attachant un mini-projet démontrant le
problème, et potentiellement un patch qui le corrige. Atlassian offre
d’autres produits comme Confluence[78], un Wiki très
réputé.
Mailing-list
Le support de Maven (comme beaucoup d’autres projets open-source) passe principalement par une liste de diffusion (Mailing-list) des utilisateurs (users@maven.apache.org dans son cas). Une seconde liste dev@maven.apache.org permet de discuter des évolutions de l’outil et de ses plugins. La liste announce@maven.apache.org permet de connaitre l’ensemble des livraisons. Il existe beaucoup d’autres liste de diffusions en fonction des sous projets de Maven[79]. Enfin, en cas de besoin urgent, vous pouvez essayer de contacter une partie de l’équipe de développement sur irc[80].
Open-source (logiciel libre)
Logiciel dont le code source est accessible. Vous pouvez, si besoin est, y jeter un œil pour comprendre comment il marche. Les logiciels open-source sont aussi qualifiés de logiciels libres. Mais cela ne signifie pas pour autant que vous pouvez faire absolument tout ce que vous voulez avec : il existe de nombreuses licences avec des contraintes très variées. La licence Apache (ASL v2) utilisée par Maven est l’une des plus souples puisqu’elle vous donne le droit d’utiliser, de modifier, de diffuser, voire même de vendre le logiciel comme bon vous semble – tant que vous gardez un petit encart rappelant l’origine initiale du code. Un des meilleurs exemples de ce cas est le IBM HTTP Server[81], qui est une adaptation du serveur HTTP d’Apache.
PMC[82]
La fondation Apache, pour la gestion des projets open-source qu’elle héberge, définit un Project Management Commitee, constitué de committers plus expérimentés ou plus actifs que les autres et qui peuvent ainsi définir de manière efficace les orientations du projet. Le PMC a ainsi la responsabilité de voter la livraison d’une nouvelle version, ou d’inviter de nouveaux membres comme committers.
API
Acronyme de Application Programming Interface, il s’agit de l’ensemble des classes qui définit comment manipuler un programme ; elles sont donc documentées et stables dans le temps (les classes internes pouvant évoluer sans prévenir). Maven propose ses propres API, en particulier pour l’écriture de plugins, les fameux Mojos, mais aussi pour la manipulation des Artefacts et des Repository.
Aether
Développé par sonatype, en opensource mais en dehors de la fondation Apache, Aether encapsule la gestion de dépendance et la gestion des dépôts d’artefact, indépendemment de leur implémentation. Maven propose ainsi une implémentation de dépôt conforme à l’API Aether, qui pourrait aussi bien être utilisée sur des dépôts Eclipse P2 ou autre.
Archetype
Patron de création de projet Maven, un archétype est un excellent moyen d’obtenir un squelette fonctionnel de projet, plus ou moins avancé selon l’archétype considéré. Le plugin archetype permet à la fois de créer un archétype à partir d’un projet existant et de créer un nouveau projet à partir d’un archétype.
Artefact
Traduction un peu trop littérale de l’anglais artifact – Vincent nous signale qu’au Québec il s’agit bien d’un mot – il définit un élément tangible produit lors de la phase de réalisation d’un logiciel. Il peut s’agir tout aussi bien d’un programme exécutable que d’un document ou un modèle UML. Dans la grande majorité des cas, il s’agit de bibliothèques Java.
Assembly
Les assembly permettent de construire un livrable selon un format particulier, typiquement une archive contenant divers artefacts ou fichiers issus de la construction du projet. Le plugin associé propose plusieurs descripteurs d’assembly standards, permettant par exemple de fournir les sources du projet ou d’assembler un JAR contenant toutes les dépendances.
Build
Terme très générique pour englober tout ce qui tourne autour de la construction du projet, de son outillage et de l’assurance qualité qu’on se donne le mal de lui associer.
Dépendances
Peu de bibliothèques ou d’applications Java se contentent de la seule JRE. Les applications modernes reposent sur des dizaines d’utilitaires ou de frameworks. On parle globalement de dépendances, chaque dépendance ayant elle-même éventuellement des dépendances.
Cycle de vie
Le packaging d’un projet Maven définit un cycle de vie, soit un ensemble de phases qui seront enchaînées. Les plugins Maven viennent se greffer à une phase donnée et sont donc exécutés selon cet ordre.
MAVEN_OPTS
La JVM qui exécute Maven peut être ajustée en définissant des options dans cette variable système. Sur un projet un peu trop généreux, vous pouvez par exemple rencontrer des OutOfMemoryError : vous pouvez alors définir quelque chose comme "-Xmx512M -XX:PermSize=128M -XX:MaxPermSize=256M" dans la variable d’environnement MAVEN_OPTS.
M2_HOME
Variable d’environnement pointant vers le répertoire d’installation de Maven. Elle permet de configurer son environnement sans se baser sur des chemins en dur et donc de changer plus facilement de version de Maven.
Mojo
Un plugin Maven est composé de classes Java, et chaque tâche du plugin est réalisé par une classe Mojo, acronyme pour Maven Old Java Object (par allusion au terme POJO, Plain Old Java Object). Un Mojo est donc le pendant côté code d’une tâche Maven invoquée par mvn plugin:tâche. Les Mojos se basent sur une API propre à Maven. Voir sur ce sujet http://maven.apache.org/guides/introduction/introduction-to-plugins.html.
Mojo est aussi le nom d’un projet[83] offrant une collection de plugins surveillés par l’équipe du projet Maven mais en dehors de la communauté Apache, ce qui permet plus de flexibilité (sur le processus d’entrée des membres, ou sur les licences par exemple).
Plexus
Conteneur historique de Maven2, implémentant l’injection de dépendance comme son concurrent Spring, mais n’ayant pas connu le succès de ce dernier, sans doute en raison d’une documentation innexistante et d’un manque de communication. Techniquement dépassé, il est remplacé dans Maven3 par Google Guice.
Plugin
De manière générale, un plugin est un composant logiciel qui vient s’ajouter à une souche existante pour en enrichir les fonctionnalités. Dans le cas de Maven, comme pour de nombreux systèmes fondés sur ce mécanisme, le cœur ne rend que les services principaux du logiciel (construction du POM, téléchargement des dépendances, lancement des plugins) pour laisser les traitements aux plugins. Ces derniers participent à la construction du projet en prenant en charge une tâche particulière (produire des rapports lors de la génération documentaire, ou encore s’exécuter de manière isolée).
POM[84]
Acronyme pour Project Object Model, en bon français "modèle du projet". Il s’agit du descripteur d’un projet tel que Maven le construit en mémoire via un modèle objet interne. Ce modèle est construit à partir de fichiers XML, qui peuvent s’enrichir mutuellement _via_un mécanisme d’héritage et de profils. Autrement dit, le POM n’est pas juste l’équivalent mémoire du fichier pom.xml. Les versions à venir de Maven supporteront d’ailleurs des formats alternatifs -– moins verbeux par exemple.
Profile
Un profil permet de regrouper une partie de la configuration Maven, de l’activer / désactiver à la demande ou en fonction de conditions locales (version de JDK, système d’exploitation, propriété système, etc.). L’utilisation la plus courante est de désactiver certaines fonctions annexes du build qui seraient pénalisantes (trop lentes, ou basées sur des pré-requis).
Release
Le processus qui permet de passer d’un projet en cours de développement à un livrable qualifié, tracé et mis à disposition des utilisateurs est qualifié de release, ce que nous avons traduit par livraison. De nombreux écueils se dressent sur votre parcours pour que toutes les tâches impliquées soient réalisées sans oubli, maladresse ou autre loupé. Le Chapitre 10 vous explique en quoi Maven peut vous aider sur cette tâche à haute valeur ajoutée lorsqu’elle est correctement automatisée.
Repository
Dépôt (ou référentiel) d’artefacts. Cela peut être un simple partage réseau (URL en file://) ou un serveur HTTP, mais pour une plus grande souplesse il est préférable d’installer une véritable application dédiée à cette tâche (Repository Manager) qui apporte de nombreuses fonctionnalités d’administration. Il existe plusieurs serveurs de référentiels comme Archiva[85], Nexus[86], Artifactory[87]…
Sisu
Développé par Sonatype pour les besoins du gestionnaire de dépôt Nexus, Sisu permet d’utiliser des composants conçus pour Plexus (le conteneur historique de Maven2) dans un conteneut conforme à la norme JSR330, en l’occurrence Google Guice.
SCM[88]
Acronyme de Source Code Management (gestion du code source). Terme générique qui recouvre tous les outils permettant de conserver l’historique des modifications dans le code source et de travailler de manière coopérative sur un même projet, en se synchronisant à intervalles réguliers. Les outils les plus courants sont CVS, Subversion, ou Visual SourceSafe, mais il en existe bien d’autres (Perforce, Git, Mercurial, Clearcase, etc.). Sous projet de Maven, SCM est une API standardisée offrant toutes les fonctions communes aux SCM.
Scope
Le scope permet de préciser dans quel contexte une dépendance est nécessaire au projet. Par défaut, compile correspond à une dépendance utilisée explicitement dans le code source ; runtime réduit ce besoin à l’exécution, mais pas à la compilation (par exemple : pilote JDBC) ; test permet d’isoler les outils de test et de ne pas risquer de les référencer dans le code source ; provided permet de référencer une dépendance qui fait partie de l’environnement cible (API JavaEE par exemple) ; enfin, import permet de réutiliser le <dependencyManagement> d’un autre POM sans passer par l’héritage.
Settings
La configuration locale de Maven est basée sur un fichier XML placé dans le répertoire $HOME/.m2 de l’utilisateur (soit C:\Documents and settings\votre_nom\.m2 pour les utilisateurs de Windows). Ce fichier permet d’ajuster le fonctionnement de Maven aux spécificités de votre poste, de votre connexion réseau, ainsi qu’à votre infrastructure. On y déclare par exemple des sites miroirs pour les dépôts d’artefacts et les identifiants/mot de passe (ce dernier peut être crypté) pour accéder aux serveurs. Un schéma XML est disponible[89] pour vous aider à saisir ce fichier sans erreur.
Snapshot
Dernière version d’un artefact en cours de développement. Une version Snapshot peut donc être mise à jour à tout moment. Maven vérifie une fois par jour (par défaut) que ses Snapshots sont à jour, afin d’éviter un accès systématique aux dépôts. L’option -U permet de forcer cette vérification, par exemple sur le serveur d’intégration continue. Maven propose deux modes de gestion des Snapshots : soit la nouvelle version écrase simplement la précédente, soit Maven déploie une version dédiée pour chaque Snapshot en ajoutant une indication de date (à la milliseconde) plus un numéro de diffusion, incrémenté à chaque nouveau Snapshot. Cette option consomme évidement plus d’espace disque sur le dépôt, mais elle permet de figer l’utilisation d’un Snapshot particulier. Il faut prendre de grandes précautions lors que l’on utilise des artefacts en version Snapshot car ces derniers ont tout loisir d’être modifiés, ce qui peut donc entrainer des régressions ou des incompatibilités.
Staging
Afin d’assurer la qualité du livrable d’un projet, une option généralement retenue dans le processus de livraison est de construire ce dernier dans son état final et de le soumettre à des tests de validation. En cas d’anomalie, un retour arrière (rollback) est réalisé et un nouveau livrable pourra être produit après correction. Pour différencier ce livrable candidat du livrable public, on place le résultat de la construction du projet dans un espace dédié, appelé stage dans le vocabulaire anglo-saxon. Cet espace est utilisé par l’équipe de test qui maîtrise son environnement. Une fois le livrable validé, il suffit de le transférer de cet espace vers l’espace public, sans aucune modification interne – le livrable public est donc bien celui qui a été testé.
SureFire[90]
Maven supporte plusieurs outils de test unitaire : jUnit[91] 3 ou 4 et testNG[92]. Ce support est orchestré par un outil dédié, SureFire ("infaillible"), sous-projet de Maven, qui fournit une vision homogène de ces trois outils, et permettra si besoin d’en intégrer un nouveau dans le support de Maven. Le plugin Maven qui exécute nos tests n’est donc pas un maven-junit-plugin, mais maven-surefire-plugin.
ClassWorlds[93]
Maven permet à chaque plugin de disposer d’un espace privé d’exécution, depuis lequel il peut s’exécuter avec ses dépendances sans être influencé par les autres plugins. Ce cloisonnement est réalisé par un jeu de ClassLoaders, basés sur l’outil open-source ClassWorlds. D’une certaine façon, ClassWorlds peut être comparé à OSGi, même si son cadre est moins large et qu’il ne fait l’objet d’aucune normalisation.
Doxia[94]
Sous-projet de Maven, Doxia est le moteur de rendu documentaire de Maven. Il sert de point d’articulation entre diverses sources (rapports d’analyse, format de documents) et le rendu final (site web HTML, document PDF). Doxia offre une API permettant de manipuler les différents formats d’entrée pour produire différents formats de sortie.
Mercury[95]
Le développement de Maven 3 introduit une refonte de la gestion des artefacts, des dépendances, de la résolution des versions, ainsi que de l’accès aux dépôts (voir Wagon). Mercury, sous-projet de Maven, est le nom de code de cette nouvelle API, conçue pour plus de clarté et de flexibilité – le code actuel de Maven 2 souffrant un peu du poids des nombreuses années de corrections diverses.
Modello[96]
Les divers fichiers XML manipulés par Maven sont définis à partir d’un
modèle (décrit dans des fichiers *.mdo), que l’outil open-source Modello
convertit en classes JavaBean, en schéma XML et en analyseurs XML pour
passer de l’un à l’autre. Modello peut potentiellement être utilisé dans
un autre cadre mais reste très lié à Maven. Modello peut être comparé à
JAXB, l’API actuelle qui normalise la passerelle entre les mondes Java
et XML.
Plexus[97]
Plexus est un conteneur IOC (Inversion Of Control) qui gère les composants de Maven. C’est un projet indépendant de Maven et qui peut être utilisé dans un cadre très différent. Cependant, son développement a toujours été fortement lié à Maven (les développeurs sont d’ailleurs en partie les mêmes).
Wagon[98]
Lorsque Maven doit accéder à une ressource réseau, il passe par une couche dédiée qui gère divers protocoles (HTTP, HTTPS, SCP, WebDAV, etc.). Cette abstraction au dessus des protocoles de communication est définie par l’API Wagon, sous-projet de Maven. Diverses implémentations permettent de supporter ces protocoles, voire d’en ajouter de nouveaux. Vous pouvez par exemple utiliser le protocole de partage Windows Samba via un module dédié[99], qui n’est pas intégré par défaut à Maven pour des questions d’incompatibilité de licence.
Apt[100]
Format de documentation utilisé couramment sur les projets Maven. Acronyme de Almost Plain Text, il s’agit d’un format en texte brut, comparable à une syntaxe Wiki.
FML[101]
Acronyme de _FAQ Markup Language, il s’agit d’un format documentaire
basé sur XML pour produire des Foires Aux Questions sur un site web
produit par Maven.
OSGi
La norme OSGi définit une plateforme de service permettant le
chargement et le remplacement à chaud de services, tout en gérant leurs
dépendances et les éventuels conflits associés.
Eclipse[102] est l’un des utilisateurs d’OSGi le plus
connu (basé sur l’implémentation OSGi Equinox*[103*_]).
Maven entre en concurrence directe avec OSGi pour la déclaration des
dépendances et la gestion de leurs conflits. Nexus[104]
est un des premiers serveurs à gérer à la fois les référentiels au
format Maven et au format OSGi.
Wiki
Système de gestion de contenu web permettant de rendre chaque page éditable par des personnes autorisées. Maven utilise Confluence[105] comme Wiki.
Xdoc[106]
Format de documentation basé sur XML permettant de définir la structure du document, un peu comme le ferait HTML si son usage n’avait pas été déformé à des fins de mise en page par des années de mauvaises pratiques.
Et pour finir, quelques liens indispensables à ajouter dans vos favoris :
· http://maven.apache.org/. Le site officiel de Maven, avec une documentation imparfaite mais tout de même bien utile.
· http://www.maestrodev.com/better-build-maven. Premier livre sur Maven disponible en ligne gratuitement.
· http://www.sonatype.com/products/maven/documentation/book-defguide. Le fameux definitive guide, en enrichissement permanent par les équipes de Sonatype.
· http://www.packtpub.com/apache-maven-2-effective-implementations/book. Encore un livre, écrit lui aussi par des membres de l’équipe Maven.
· http://www.sonatype.com/people/. Le blog de Sonatype, sur lequel on peut piocher de nombreuses bonnes idées autour de Maven.
· http://mojo.codehaus.org/. Site communautaire qui héberge de nombreux plugins Maven. Si vous avez développé un plugin intéressant, n’hésitez pas à le proposer comme contribution.
Sans oublier bien-sûr deux sites absolument indispensables dans la vie d’un développeur Java :
· http://blog.aheritier.net/. Le blog d’Arnaud.
· http://blog.loof.fr/. Le blog de Nicolas.
+
[3] MaestroDev (http://www.maestrodev.com).
[4] Sonatype, Inc. (http://www.sonatype.com).
[5] Source : http://fr.wikipedia.org/wiki/Apache_Ant.
[7] Ne riez pas, il s’agit d’un cas bien réel, identifié lors de la migration du projet sous Maven !
[8] Je vous laisse chercher la signification de cet acronyme, couramment employé pour désigner tout ce qui ne marche pas comme prévu, comme en témoigne le site thedailywtf.com - notre éditrice nous encourage à traduire ce dernier par « Saperlipopette », « Diantre » ou « Morbleu »
[17] Si l’utilisation de Flex depuis Maven vous intéresse, retrouvez toutes les informations utiles sur le blog de François ( http://jroller.com/francoisledroff/ ) et aussi dans le projet Cairngorm ( http://sourceforge.net/adobe/cairngorm/wiki/Cairngorm/ ) auquel il participe et où vous trouverez de bons exemples de mise en œuvre de maven en projet Flex et hybride, Java et Flex.
[20] Il existe deux variantes majeures de jUnit, jUnit3 et jUnit4, la seconde utilisant la syntaxe java5 que nous avons retenu pour notre exemple
[21] On appelle "méthodes agiles" un ensemble de méthodes de travail qui cassent le mythe du projet bien planifié pour préférer une approche réactive. Voir http://fr.wikipedia.org/wiki/Méthode_agile.
[26] Le coût d’une licence Oracle est fonction du nombre de cœur. Je vous laisse imaginer ce que cela peut donner…
[38] _Plain Old Java Object, soit "bon vieil objet Java". Les outils modernes ne demandent plus à notre code d’hériter de telle classe ou d’implémenter telle interface, ce qui lui permet d’être neutre et plus souple. Cette appellation cherche avant tout à se différencier des frameworks contraignants qui imposent la hiérarchie des classes, comme Struts par exemple.
[40] Aussi connu sous le nom d’Inversion de Contrôle (http://fr.wikipedia.org/wiki/Inversion_de_contrôle).
[41] http://classworlds.codehaus.org/ (voir, en particulier, http://maven.apache.org/guides/mini/guide-maven-classloading.html).
[43] Petit rappel de vos lointains cours de physique : S est le symbole utilisé en physique pour l’entropie :).
[48] Vous ne connaissez pas la méthode agile Scrum (http://fr.wikipedia.org/wiki/Scrum) ? Renseignez-vous vite auprès de votre JUG local pour qu’il organise une soirée dédiée :).
[50] Accessible sans client IRC par l’interface web http://irc.codehaus.org/.
[59] Si vous ne connaissez pas, regardez au moins une fois : Les Maçons du cœur (Extreme Makeover Home Edition en VO), ça vous donnera une idée des travaux en cours.
[60] Entre la rédaction de ce chapitre et sa relecture, SpringSource a été racheté par VMWare. Les choses vont tellement vite en informatique…
[64] Outil créé par Peter Kriens, http://www.aqute.biz/Bnd/Bnd
[66] Mark Reinhold, qui nous a inspiré ce personnage, est « principal engineer » chez Oracle et responsable du projet OpenJDK. Précisons qu’il n’a pas été consulté pour relire ce chapitre, aussi les propos que nous lui prêtons sont totalement fictifs.
[68] Tiger est le nom du projet de développement de Java 5, comme Dolphin est le nom de Java 6 et Mustang celui de Java 7. De nombreuses librairies utilisent ce nom pour désigner une version adaptée à Java 5, ce qui sonne mieux que -j5.
[69] Si vous voulez voir à quoi cela peut ressembler, un vrai projet ingérable et interminable à construire est Sakaï (http://sakaiproject.org/portal)
[A1]Maven.repositories Je ne vois pas d’ou vient ce fichier ? C’est fictif ? C’est pas clair …
[A2]Il y a désormais la version communautaire !!!
[A3]C qui m’ennuie avec cette approche c’st la traçabilité des artifacts aujourd’hui. Par exemple comment faire la signature GPG ?
[A4]Sauf erreur de ma part les svn :externals ne fonctionnent que sur des répertoires. Ca ne marche as sur des fichiers J Quand je fais cela je place dans trunks un pom uniquement pour faire reacteur des autres sous modules. Mais bon ça reste bof …
NDL : Ca marche avec svn 1.6, je l’utilise couremment