Interview de Nicolas de Loof et Arnaud Héritier, co-auteurs de Apache Maven

Gildas : Bonjour à vous deux, merci d'avoir accepté cette interview. Tout d'abord, pour ceux qui ne vous connaissent pas, pourriez-vous vous présenter en quelques mots ?

Nicolas De Loof, architecte Java et techno-veilleur dans une grande SSII depuis 12 ans : j'y ai fait mon trou et ma renommée d'électron libre, après avoir introduit de nombreuses technos, pratiques et quelques curiosités. Le monde des SSII n'a pas bonne réputation en terme de R&D et d'innovation, pourtant il existe quelques bonnes places comme la mienne, il faut juste se les construire soi-même.

J'ai découvert le monde open source dans ce cadre et Apache Maven vers 2003. Obligé de butiner de projet en projet, j'ai rapidement été conquis par la structuration et l'homogénéité qu'il apportait, au point de passer de l'autre côté du miroir en contribuant puis en étant invité à rejoindre l'équipe en 2007. J'y ai fait de nombreuses connaissances, dont Arnaud à qui j'ai proposé l'écriture d'un ouvrage sur le sujet.

J'ai créé en 2008 le Java User Group Rennais (BreizhJUG), qui me permet de rencontrer tous ces gens bizarres qui partagent les mêmes centres d'intérêt que moi. L'occasion aussi de prendre contact avec le monde de l'édition et en particulier notre partenaire Pearson, qui a accepté de nous accompagner dans ce projet de livre.

Arnaud Héritier, cela fait 10 ans que je parcours les entreprises de tout type : de la société de services à l'édition de logiciels en passant par le cabinet d'architectes. J'ai pu porter différentes casquettes comme Développeur, Architecte, Consultant, Chef de projet, ou Responsable produit.

Aujourd'hui je suis "Software Factory Manager" chez l'éditeur de logiciels français eXo Platform qui distribue des solutions open-source basées sur les technologies Portail et JCR de JEE. Derrière cet intitulé de poste obscur se cache tout simplement celui qui a pour but d'améliorer en continu la qualité des applications et la productivité des équipes.

Tout comme Nicolas, j'ai découvert Maven en 2003 alors que j'étais dans une société de services à participer à de nombreux projets où l'on ne pouvait pas passer notre temps à former à chaque fois les équipes. Nous avions encore moins de temps pour gérer le "build" des applications. La standardisation apportée par Maven permettait de gagner du temps et de ne pas réinventer la roue. En plus, sa capacité en "reporting" permettait de briller auprès de notre management et des clients :-).

J'ai rejoint l'équipe Maven en 2004 après les avoir inondé de patchs sur le plugin PDF de Maven 1, et un an plus tard j'ai été invité à rejoindre le Project Management Committee (Le groupe des grands sages qui pilotent le projet).

Depuis je participe à de nombreux projets open-source (en avouant cependant que cela correspond souvent à mes besoins professionnels) et j'essaie d'évangéliser la communauté Java à l'utilisation de Maven en parcourant les routes, et en particulier celle des JUGs français.

Gildas : Concernant votre livre, Apache Maven, qu'est-ce qui vous a donné l'envie de vous lancer dans cette aventure ?

Nicolas De Loof : Dans mon travail quotidien je fais pas mal de support auprès des développeurs et je constate que Maven est bien mal compris. Ca fait partie de ces outils un peu magiques qui font des tas de trucs et qu'on va lancer deux ou trois fois avec des paramètres différents pour résoudre un problème au petit bonheur la chance.

Proposer un guide de Maven issu du terrain et focalisé sur des problèmes concrets, c'est tout simplement une synthèse de ce que je dois expliquer régulièrement aux nouveaux développeurs. D'une certaine façon, me lancer dans l'écriture de ce livre c'était donc m'économiser du travail - ça ne s'est pas tout à fait confirmé au final, mais on en a vu le bout !

Etant en contact avec Pearson via le BreizhJUG, j'ai été mis à contribution pour identifier des sujets dignes d'intérêt, comme par exemple la traduction de "java concurrency in practice", un livre qui fait mal au crâne mais qui fera la différence lorsque les processeurs 8-cœurs seront devenus l'entrée de gamme.

A force de discuter avec eux de sujets de ce type, nous avons inévitablement abordé Maven. La traduction des 400 pages du "definitive guide" n'étant pas financièrement envisageable pour Pearson (elle a d'ailleurs commencé depuis, sur la base du bénévolat), j'ai proposé à Arnaud de tenter l'aventure, ne me sentant pas les épaules assez solides pour faire ça tout seul.

Au final, nous nous sommes mutuellement aiguillonnés et motivés lorsque les délais commençaient à filer. Nous avions la même vision de ce livre : quelque chose de pragmatique, couvrant Maven sans chercher le détail mais aussi l'écosystème qui l'entoure.
La rédaction a donc été facile une fois le ton initial trouvé. La collaboration avec Arnaud a été un vrai régal car il savait m'encourager et me suggérer de nouvelles idées, tout en s'auto-flagellant comme quoi il avait un chapitre de retard et qu'il fallait vite vite qu'il s'y attaque. Nous nous sommes ainsi soutenus tout au long de la rédaction.

Arnaud est quelqu'un d'exigeant et de perfectionniste, je suis souvent trop brouillon, à laisser partir des choses tout juste dégrossies. Nous nous sommes donc très bien complétés, derrière un objectif commun : apporter à la communauté francophone, novices ou non, un support pragmatique pour mettre en œuvre Maven dans de bonnes conditions.

Arnaud Héritier : Cela fait des années maintenant que je vois des équipes à la dérive en utilisant Maven sur leur projet. Souvent j'arrive sur mon beau cheval blanc pour les sauver (lorsque c'est encore possible, sinon je dois les achever, je n'aime pas laisser souffrir les gens).
Lorsque j'analyse pourquoi l'équipe en est arrivée là, on en vient souvent à la même conclusion : On ne nous laisse pas le temps de maîtriser ce nouvel outil et le coût d'entrée est haut car sa documentation n'est que difficilement accessible. Pourquoi ? L'une des raisons à cela est la barrière de la langue car il faut bien avouer que nous, les Frenchies, ne sommes pas toujours très à l'aise avec la langue de Shakespeare.

Nombreux sont ceux qui se découragent lorsqu'ils voient qu'il faut avaler plusieurs centaines de pages d'un contenu qui en toute connaissance de cause ne sera pas vraiment ludique. Enfin, le grand défaut de la plupart de ces ouvrages est de vouloir être exhaustif sur toute la puissance qu'apporte Maven, en oubliant l'essentiel : A quoi ça sert ? Pourquoi en est-on arrivé là ? (Et oui tout le monde n'a pas connu Java 1.0 avec des projets construits avec des Makefiles, ou encore pire : Maven 1 :-) )

Lorsque Nicolas m'a proposé en fin d'année dernière de l'accompagner sur la rédaction de ce livre je me suis lancé. Autant cela me paraissait insurmontable seul, autant à deux je pensais bien qu'il y aurait moyen de s'amuser. Et c'est ce que nous avons fait ! Nous avons essayé de vous livrer un concentré de nos expériences tirées du terrain et ce dans un mode romancé pour ne pas vous laisser vous ennuyer.
Cet ouvrage n'a pas du tout pour but de couvrir tous les cas d'usages de Maven mais au contraire de mettre le focus sur les bases (pour qu'elles soient bien comprises) et sur tous les usages réels, bons ou mauvais, que nous avons vu se répéter.

Gildas : Etiez-vous au courant du projet de traduction de Maven : The Definitive Guide, lorsque vous avez commencé ? Comment se positionne votre livre face à celui-ci ? Est-il semblable ou au contraire plutôt complémentaire ?

Nicolas De Loof : C'est la première proposition que j'ai faite à Pearson pour proposer un livre sur Maven en français. Seulement, pour un éditeur ce travail se paye au nombre de pages, et le pavé que représente The Definitive Guide était hors budget, du moins sur la base de leurs estimations de marché (pas simple à chiffrer).

Peu de temps après le démarrage de la rédaction, des bénévoles se sont présentés sur la liste Maven pour traduire ce livre de référence. Le sujet étant abordé de manière très différente nous n'avons jamais considéré cela comme de la concurrence. Nous avons donc fait le relais avec l'équipe, ne pouvant pas travailler sur les deux sujets en même temps (il faut bien dormir un peu aussi).

Arnaud Héritier : Oui nous étions au courant et nous avons même aidé à mettre les personnes en contact. Je crois même avoir dit que lorsque notre ouvrage serait publié, je rejoindrai le groupe de traduction (flute, j'espère qu'ils ont terminé - ou - oublié :-) ).

Les deux ouvrages sont très complémentaires. Le Definitive Guide c'est un peu le cours théorique alors que le notre c'est le TP. Dans le premier on retrouve des tonnes de d'informations sur le produit et ses paramétrages les plus cachés tandis que dans le second nous sommes beaucoup plus prêts des scénarios que l'on vit tous les jours dans nos entreprises.

Nous avons fait en sorte de contextualiser chaque explication pour que le lecteur trouve facilement ces repères et se dise : Ah oui ! C'est ça que l'on a voulu faire.

Gildas : De part sa nature modulaire et sa popularité, Maven couvre un maximum de sujets. Quels sont ceux couverts par votre livre ? Compilation, génération de rapport, utilisation avec des outils d'intégration continue ?

Nicolas De Loof : Le livre couvre la vie d'un projet qui passe du statut de bricolage à celui de projet stratégique pour l'entreprise. On démarre donc sur la simple compilation et la gestion des dépendances, ce qui permet d'introduire les concepts de base. On introduit ensuite les plugins pour faire tout un tas de choses, et on décrit les bonnes pratiques de test.

Le passage dans le monde de l'entreprise permet de présenter la gestion d'un dépôt d'artefacts avec les outils associés, la documentation, les rapports, et l'assurance qualité. Avec la professionnalisation du projet on découvre la gestion du processus de livraison et d'intégration continue, la réutilisation du projet pour démarrer un nouveau développement (archetypes), l'intégration dans les IDE, le respect de normes de packaging, et l'intégration d'outils spécifiques à l'entreprise sous forme de plugin Maven. Enfin, nous donnons quelques règles et bonnes pratiques que nous recommandons de suivre.

Nous avons essayé de couvrir un cadre aussi large que possible en ne rentrant pas plus que nécessaire dans les détails de Maven (ceux que ça intéresse iront lire le definitive guide ou la doc du plugin considéré). Certains sujets débordent d'ailleurs largement du cadre strict de Maven, mais nous semblaient suivre logiquement notre démonstration.

Avec cette approche, nous avons pu partager un maximum d'expériences, à peine enjolivées, pour trouver leur place dans le récit. Maven peut facilement être mal utilisé (c'est ce qui lui fait parfois une mauvaise réputation), nous avons donc insisté sur son utilisation au cas par cas et exclusivement pour répondre à des besoins précis.

Il est étonnant de voir le nombre de projets qui génèrent des rapports sans avoir la moindre idée de la signification des indicateurs remontés, et qui se plaignent après de la complexité du POM et de la durée de leur build ...

Gildas : N'avez vous pas été tenter d'attendre Maven 3 pour écrire votre livre ?

Nicolas De Loof : Non. Beaucoup d'utilisateurs utilisent encore des versions assez anciennes de Maven 2.0, alors que la 2.2 est disponible. Maven 3 ne sera probablement prêt que mi-2010 et la migration va être lente. Beaucoup de projets se contentent de Maven 2, Maven 3 est intéressant surtout pour ses capacités d'intégration et d'évolution dans l'avenir.

Par ailleurs, Maven 3 est conçu pour pouvoir remplacer Maven 2 sans modification du projet. Cette fois-ci tout est fait pour qu'il s'agisse d'une évolution et non pas d'une révolution comme Maven 2 avait pu l'être par rapport à Maven 1. Tout ce que nous indiquons reste donc valable. Nous avons un chapitre qui présente de manière assez spéculative (difficile d'être certain de ce qui sera finalement fait) les nouveautés de Maven 3. Nous ferons probablement une seconde édition quand tout sera stabilisé, mais cela ne remettra pas fondamentalement en question le contenu du livre.

Gildas : Parlons un peu de Maven 3, il semblerait que cette version a été complètement refondue. Pourriez-vous nous parler des changements et nouveautés ?

Arnaud et Nicolas : J'aimerais faire des sessions JUG avec Arnaud sur ce sujet en 2010, donc voici ce que j'en sais (je ne suis pas à plein temps sur le commit log, alors je peux avoir raté des points importants) :

• Maven 3 est avant tout un grand ménage du code de Maven 2, qui comportait de nombreuses faiblesses. Il a subit un très gros régime pour rationaliser le code (possible à partir des nombreux retours d'expériences que nous avons eu sur la version 2), et simplifier son accès (moins de lignes de code, moins de modules, ...). Du coté architecture il a aussi été totalement repensé. Par exemple, Maven 2 était peu extensible et on s'en est vite rendu compte dans le développement de m2eclipse. Impossible d'embarquer Maven 2 dans un système OSGi. Par ailleurs, le code devenait assez obscur car les API "publiques" n'étaient pas définies, et de nombreux plugin - à commencer par le plugin GWT que Nicolas a développé - utilisaient des classes considérées comme internes.
• Maven 3 voit aussi sa qualité et ses performances accroître de jour en jour. Pour cela un harnais de tests unitaires et d'intégration, ainsi qu'une ferme d'exécution de nombreux builds open-source permet de veiller à la non régression de Maven 3 au fur et à mesure de son développement, ainsi que sa compatibilité par rapport à Maven 2. Un framework dédié a aussi été mis au point (surveillant l'utilisation des disques, du réseau, de la mémoire, du processeur) pour suivre les performances des builds par Maven 3.
• Maven 3 se désolidarise du modèle XML associé au POM. La façon dont celui-ci est construit est clairement définie et encapsulée dans une API totalement abstraite. Il est ainsi possible d'écrire des POM en Groovy ou en Yaml. Par contre, la manière dont seront gérés les POM publiés sur le repository central reste à définir. Il y a de fortes chances qu'ils resteront en XML pour être lisible par tout le monde. Ce chantier est loin d'être terminé car aujourd'hui la question la plus importante reste : Comment gérer différentes versions du modèle de POM avec les différentes versions de Maven ? Cette fonctionnalité semble intéresser à peine 3% des utilisateurs (sondage Devoxx), surtout si on considère que des outils comme m2eclipse ne peuvent manipuler que le format XML du POM. Cependant cela montre comment la structure de Maven a été repensée pour être moins monolithique.
• Maven 3 devrait aussi proposer un mécanisme de composition des POMs (une sorte d'héritage multiple) nommé Mixin. Ceci permettra de fusionner plusieurs POMs dans celui du projet afin d'avoir une meilleure factorisation du paramétrage : Ici je prends le dependencyManagement, là la configuration des plugins, ...
• Maven 3 modernise sa base technique. Java 5 comme syntaxe de langage, Google Guice comme conteneur, en se basant sur la JSR @Inject. Plexus était avant-gardiste, mais tellement sous-documenté qu'il est resté largement inconnu du grand public. Tout cela contribuera à abaisser le ticket d'entrée dans le projet en utilisant des standards connus par les développeurs.
• Maven 3 propose une bibliothèque de compatibilité qui assure le fonctionnement 'comme avant' des plugins Maven 2, en traduisant les appels aux classes dépréciées vers les nouvelles API. Les plugins pourront donc migrer progressivement.
• Maven 3 améliore aussi la vie des développeurs de plugins. La nouvelle architecture sera extensible et permettra enfin de réutiliser ou étendre des plugins existants. Terminées les copies de code ou les librairies utilitaires dans tous les coins pour partager quelques lignes entre deux plugins similaires. Le cycle de vie (lifecyle = ensemble des phases exécutées pour un type de packaging donné) sera lui aussi extensible. Cette refonte touche aussi certains plugins pour qu'ils puissent fonctionner dans un build incrémental, comme celui utilisé dans m2eclipse. Le plugin ressources par exemple ne traitera plus que les fichiers pour lesquels Eclipse signale une modification, plutôt que de retraiter systématiquement chaque fichier de ressource.
• Maven 3 construit un plan du build avant de commencer à builder, alors que Maven 2 fait les choses au fur et à mesure qu'il découvre des tâches à exécuter. Ce changement permet de modifier le plan si besoin avant qu'il s'exécute et tout plugin peut, avant l'exécution, savoir ce qu'il va se passer avant et après lui afin d'adapter son comportement. m2eclipse utilise ce principe pour désactiver des tâches qu'Eclipse réalise mieux que lui (compilation incrémentale Java par exemple). Tycho se base également dessus pour remplacer la résolution des dépendances par un mécanisme pur OSGi.
• Maven 3 se base sur un module d'accès aux repositories et de gestion des artefacts totalement repensé et indépendant. Ce module "mercury" peut être utilisé dans des outils indépendants de Maven (gestionnaire de dépôt, outil d'analyse, ...). Il a bénéficié des bons soins de l'équipe de développement de Jetty, qui en connait un bout sur HTTP et nous a donc pondu un sacré beau morceau de logiciel. L'accès aux dépôts HTTPS ou WebDav devient ainsi triviale.
• Maven 3 simplifie l'intégration des rapports et la génération du site, qui pour l'instant mixait une API spécialisée avec l'exécution du plugin site. Ce plugin sera désormais un maillon comme un autre et pourra récolter les rapports, plutôt que de fusionner avec plus ou moins de chance ce que chaque plugin rapport aura bien voulu générer. Ceci permettra aussi d'avoir exactement le même comportement, que l'on fasse le reporting pour l'afficher dans le site web Maven ou pour le publier dans un outil de suivi de la qualité comme Sonar.
• Enfin, et surtout, Maven 3 marquera une nouvelle base pour le développement de nouvelles fonctionnalités. Avec une base plus compréhensible et extensible, de nouveaux développeurs peuvent enfin mettre les mains dans le cambouis sans s'y noyer. On a vu par exemple une proposition de paralléliser le build d'un projet multi-module, proposition totalement externe à l'équipe de développement Sonatype. Ce genre de chose était totalement impensable avec Maven 2, même pour quelqu'un connaissant bien ses rouages.

Gildas : Pensez-vous que Maven soit adapté à tous les projets ? Que dire des sociétés qui ont leur propre système de génération de build en ANT (ex. : génération d'ear spécifiques par injection de module technique caché pour le développeur, ajout de configuration dans le web.xml par le build ) par exemple ? Est-ce que n'importe quel mécanisme pourrait être migré en Maven ?

Nicolas De Loof : Il y a clairement quelques cas pour lesquels Maven n'est pas adapté. Il s'agit souvent de middleware nécessitant des phases très particulières de compilations multiples, comme par exemple Spring 2 qui combinait une compilation Java 1.3 et Java 5 dans le même Jar - on pourrait d'ailleurs argumenter que cela traduit un choix structurel discutable. Il y a aussi certains projets "legacy" pour lesquels les plugins Maven 2 n'existent pas (projets morts). De tels projets nécessiteraient un important effort de migration.

Dans la plupart des cas, il s'agit surtout de projets qui n'ont pas été pensés avec la structure de Maven en tête, et qui ont donc fait des choix diamétralement opposés. Cela ne veut pas dire qu'ils ne pourraient pas être revus pour être construits par Maven, mais que l'effort de migration n'est pas nécessairement justifié. Une équipe très à l'aise avec son build Ant ne va pas migrer sous Maven juste pour répondre à un effet de mode - je pense aux développeurs de GWT.

Un projet "tout neuf" par contre aura plus de mal à argumenter de ne pas se tourner vers Maven, ou en tout cas de ne pas suivre autant que possible ses structures et conventions. Cela laisse la porte ouverte pour une future migration, même pour ceux qui ne supportent pas les kilomètres de XML que nécessite Maven.

Gildas : De manière générale, Maven est assez bien intégré dans les projets Open Source, pensez vous que cela soit le cas en entreprise ?

Nicolas De Loof : De plus en plus. L'open-source est un exceptionnel laboratoire pour l'entreprise. Les développeurs open source sont massivement distribués, multilingues, multiculturels et en plus n'aiment pas perdre du temps sur de la documentation ou de la correction de bugs. Ils ont donc inventé les meilleurs outils de contrôle qualité, d'outillage des tests et d'extraction de documentation. Les entreprises adoptent l'intégration continue ou la couverture de test d'intégration alors que c'est une pratique courante en open source - certains projets refusent une contribution si elle n'est pas accompagnée d'un test !

Maven propose quelque chose d'assez novateur : une convention universelle. N'importe qui peut construire un projet Maven par la commande universelle "mvn install". Si le build est bien configuré, aucune configuration supplémentaire ne sera nécessaire.

Ca semble peu de chose, mais c'est l'arbre qui cache la forêt : toutes les commandes de base de Maven sont applicables sur tous les projets utilisant Maven. Bien sûr il a ses défauts, mais passer d'un projet à un autre, d'une entreprise à une autre, et se retrouver immédiatement en terrain connu c'est un gain de productivité énorme.

Maven démocratise aussi le suivi qualité en permettant d'intégrer au projet de nombreux outils d'analyse et de reporting. Je déconseille d'activer pour autant tous les rapports possibles et imaginables juste parce que c'est possible. Par contre, on peut en un clin d'œil passer un findBugs ou une mesure de couverture de tests, et évaluer son intérêt.

Arnaud Héritier : Les enjeux en entreprise et en open-source sont différents. Comme l'a dit Nicolas, cela devient presque une nécessité du fait du modèle déstructuré des projets open-source. Les projets qui veulent survivre doivent savoir gérer facilement le travail collaboratif distant et à ce niveau Maven offre de nombreux services. Maven est donc le choix des équipes projets qui ont besoin de lui pour facilement partager les livrables, standardiser les développements et suivre la qualité.

Dans les entreprises, nous sommes dans un modèle bien différent. Le travail distant est rare et fonctionne souvent mal. Les équipes ne sont pas souvent poussées pour faire réussir le projet mais pour que la société prestataire de la réalisation (le pourcentage de réalisations externalisées est énorme en informatique) empoche ses factures (si avec un peu de chance le projet peut réussir pourquoi pas). Maven n'est alors plus le choix des projets, mais celui de l'entreprise qui souhaite mieux contrôler les développements des équipes projets. Elle veut rationaliser les coûts et piloter avec des indicateurs qualité la réalisation des applications. L'adoption est donc moins facile car au sein des projets on oublie souvent de leur expliquer ce que cela leur apporte comme valeur ajoutée.

Aujourd'hui lorsque je me promène dans les JUGs Français et que je demande qui utilise Maven, le nombre est très bas comparé à ANT (en dehors de la capitale et quelques rares autres villes où l'on retrouve une égalité, voire une majorité pour Maven). Pourtant après avoir expliqué au public ce que leurs projets ont à y gagner demain, les équipes sont tout de suite bien plus enthousiastes et sont prêtes à lui donner une chance à très court terme.

Gildas : Que pensez-vous des «concurrents» comme ANT/Ivy ou Gradle ? Gradle avec son coté hype Groovy pourrait-il faire de l'ombre à Maven ?

Arnaud Héritier : ANT/Ivy (voiree Gant) gardera une place de choix pour tout ce qui nécessite d'écrire des scripts. Par exemple sur des tests d'intégration cela peut être très utile. Pour des projets qui n'ont pas les moyens ou le besoin de migrer vers Maven, ils resteront aussi très présents pendant longtemps.

Gradle lie la souplesse du scripting ANT avec la puissance de Groovy et la standardisation de Maven. On se dit alors que c'est l'avenir ... ou pas. En fait, je trouve l'outil mal positionné comme Maven 1 (ce qui, en plus des mauvais choix technologiques, l'a conduit à sa perte). Comment faire pour préconiser des services à valeur ajoutée au dessus de standards (à la Maven) tout en permettant à l'utilisateur de faire tout et n'importe quoi ? Leur principal problème sera de maintenir le logiciel dans le temps. Cela n'est déjà pas évident aujourd'hui mais ils ne sont pas encore en version 1.0.

A l'avenir comment vont-ils assurer la non-régression tant les cas d'utilisation pourront être tordus ? Je leur souhaite bonne chance, mais c'est le modèle de Maven 1 (ANT + Scripting avancé + Standards) que nous avons abandonné, faute de pouvoir le maintenir.

Nicolas De Loof : J'ai regardé Gradle sans rentrer dans les détails, et j'ai tout de suite reconnu les rouages de Maven 1 sur un socle moderne. Certes c'est du Groovy bien sympa, mais les concepts sont ceux qui ont fait de Maven 1 une usine à gaz - Arnaud a été le dernier des mohicans en supportant seul ou presque la finalisation de Maven 1.1 et ça doit lui dresser les cheveux sur la tête (enfin, ceux qui lui restent).

Les outils qui tournent autour d'ANT et en particulier Ivy ont toute leur place. Ils ne visent pas la même cible que Maven, plutôt la facilité pour faire des choses spécifiques et pas l'universalité d'un build. La comparaison se fait ainsi souvent sur le nombre de lignes du fichier de build, métrique qui vaut ce qu'elle vaut, selon les critères qu'on se donne pour évaluer un outil. Enfin, quand on voit les reproches fait à l'intégration de Maven dans Eclipse, que faudrait-il dire de ses concurrents !

Gildas : Quels sont les outils (IDE, Intégration, plugin intéressants) que vous utilisez avec Maven et lesquels recommandez vous ?

Arnaud Héritier : La question qui fâche ! :-)

L'intégration aux IDEs reste le principal point faible de Maven de nos jours. Cela est dû à de nombreuses raisons : mauvaise architecture de Maven, mauvaise architecture de certains IDE (beurk Eclipse), variété d'IDE (je vous laisse compter le nombre de versions/variantes d'Eclipse), conflits de communautés (Eclipse a snobé, voirz mis des bâtons dans les roues à Maven pendant des années), etc.

L'équipe Maven, et en particulier la société Sonatype, travaillent dur pour améliorer cela. C'est ainsi qu'ils poussent Maven 3 afin d'avoir une intégration avec Eclipse de bonne qualité. Cela s'améliore de jour en jour mais le chemin est encore long. Les autres IDEs (Netbeans, IntelliJ) proposent une intégration généralement native, mais un niveau de services moins important que m2eclipse. Leur force par contre est de le faire correctement (import de projets Maven dans l'IDE, gestion des dépendances etc.) là où m2eclipse reste trop souvent "lourd".

Pour l'intégration aux IDEs il reste une solution aux plugins des IDEs ce sont les plugins Maven qui vont générer la configuration pour l'IDE. Le problème c'est qu'ils sont difficilement maintenables et sont de moins en moins mis à jour (le plugin eclipse:eclipse est numéro 1 dans le nombre d'issues des plugins Maven). Ils continuent d'être fortement utilisés mais ne sont qu'une roue de secours (bien utile certes) en attendant un support de qualité dans les IDEs.

Nicolas De Loof : J'utilise à la fois m2eclipse et le bon vieux mvn eclipse:eclipse. La version de m2eclipse avant la 0.9.9 est inutilisable sur un gros projet multi-module, les builds récents par contre sont très prometteurs. Je passe donc souvent de l'un à l'autre selon le contexte. Malgré ma licence Apache pour IntelliJ, je reste fidèle à Eclipse non pas par conviction mais par habitude : difficile de changer !

L'intégration dans Eclipse a par contre un excellent éditeur pour le POM, qui est un outil appréciable pour gérer et filtrer ses dépendances. Jason a même parlé de supporter le refactoring du POM, par exemple remonter dans le POM parent les dépendances communes à plusieurs modules. Le genre de choses qui ferait oublier le format XML de Maven qui fait tant rugir ses détracteurs...

Gildas : Le livre maintenant publié, avez vous d'autres projets concernant Maven ou autres ? Un nouveau livre ? Une tournée des JUGs pour présenter votre livre ou Maven 3 par exemple ?

Nicolas De Loof : Tu as mis dans le mille : j'aimerais effectivement faire une tournée des JUGs avec Arnaud au sujet de Maven 3 - ce qui va supposer aussi que je me mette à niveau ! Je lance d'ailleurs une grande souscription nationale auprès des juggers pour me faire offrir un MacBook, ça me changera de mon Thinkpad auquel j'ai collé un autocollant "Apple" pour faire bien, mais le stratagème est vite démasqué.

Je vais aussi continuer à supporter autant que possible le plugin GWT, en particulier avec la sortie de GWT 2.0. D'ailleurs, si les petits gars de Google pouvaient arrêter de changer tout le temps les options ou le packaging ça m'aiderait bien... ils ne sont pas très conscient du mode de fonctionnement de Maven - je crois qu'ils s'en foutent royalement. Le JIRA du plugin a donc des chances de se remplir encore pendant quelques temps ;)

Pas d'ambition pour un nouveau livre dans l'immédiat, même si les idées ne manquent pas. Ce premier livre a été un sacré boulot et j'aimerais bien lever un peu le pied. Je vais plutôt me recentrer sur mon activité de JUG-leader qui occupe déjà pas mal de mon temps.

Arnaud Héritier : Du coté des JUGs je n'ai jamais arrêté. J'étais en novembre à Marseille et en octobre à Rouen. Les propositions ne cessent d'affluer (merci !) et j'espère énormément pouvoir en faire en duo avec Nicolas (parce que à nous deux on rigole bien et nous n'avons pas notre langue dans la poche - le livre en est l'exemple).

Côté livre, je pense aussi que je vais lever le pied. Je pense que l'on nous demandera bien assez rapidement une deuxième édition pour la mise à jour avec les nouveautés de Maven 3. Et les nouvelles idées à y rajouter ne manquent pas.

Coté open-source, c'est désormais mon travail de tous les jours chez eXo Platform/JBoss. Je ne vais cependant pas arrêter mes contributions à Maven. Je continuerai à travailler sur divers plugins en fonction de mes besoins et j'ai aussi pas mal d'idées pour enrichir Sonar ou d'autres produits pour améliorer les pratiques de développement et la gestion des forges.

Gildas : Un mot de la fin ? :-)

Nicolas De Loof: Tout d'abord, merci à tout ceux qui nous ont supportés pendant cette rédaction, et ils ont été nombreux. Les encouragements aident bien dans la dernière ligne droite, alors que la motivation commence à dangereusement s'émousser. La communauté francophone est très active dans l'open-source, même si elle est difficile à identifier dans ce monde majoritairement anglophone.

Pour le mot de la fin, je dirais juste rendez-vous à la prochaine soirée JUG - et ne me dites pas qu'il n'y a pas de JUG près de chez vous, il en fleurit de partout - il n'est pas impossible qu'on s'y croise !

Arnaud Héritier : Un grand merci aussi à tous ceux qui nous ont aidé sur ce chantier (les relecteurs, la communauté Maven, l'éditeur) car c'était un pari loin d'être gagné à l'avance pour des geeks comme nous. Un grand merci à nos (futurs) lecteurs qui sauront nous aider à prouver que la communauté Maven Francophone est plus que jamais active. J'espère que ce livre vous aidera et vous apprendra suffisamment de choses sur Maven pour l'utiliser à bon escient et sans douleur dans vos projets.