Catégories: Java | Maven | Ant | Entretien

Un article de ToutProgrammer.com.

ToutProgrammer.com a rencontré Vincent Massol, un membre actif de la communauté Open Source, créateur du projet Jakarta Cactus (framework de tests unitaires pour J2EE) et contributeur au projet Apache Maven (gestionnaire de projets). Il nous parle de ses expériences dans le développement offshore, l'Open Source et nous présente le futur de Cactus et Maven.

Introduction

Le texte ci-dessous est une transcription directe de l'enregistrement de l'entretien. Cet entretien a été réalisé le 12 août 2004 dans les locaux de la société Pivolis où Vincent Massol est Directeur Technique. Entretien réalisé par Olivier MALE et Stéphane VANPOPERYNGHE. Cette conversation est publiée sous licence Paternité-Pas de Modification 3.0 Unported.

Pivolis

Pouvez-vous nous présenter la société Pivolis ?

J'ai passé 2 ans en Angleterre en tant que directeur de la filiale de la société OCTO Technology (cabinet d'architectes en Systèmes de l'information). Un client nous a demandé de développer une application de micro-paiements par téléphone mobile. Nous avions la contrainte de réaliser le projet avec un partenaire offshore de cette société. Il faut savoir que j'étais la personne la plus réfractaire à l'offshore. J'aurai préféré voir le projet réalisé par 5 développeurs en Angleterre mais ce n'était pas possible.

J'ai donc fait l'audit d'une société Indienne de Pune, une ville située juste à coté de Bombay. J'ai été bluffé par ce que j'ai vu: j'ai trouvé des gens qui étaient très très bons, ils connaissaient vraiment bien le sujet et ils étaient au moins aussi en avance que nous. Du coup, je me suis dit "il faut faire ça" mais en réduisant les risques dûs à l'offshore. Le mieux était d'utiliser les méthodes que je connaissais: celles de l'Open Source et Agile. En faisant ainsi, nous aurions une communication, un feedback permanent, nous pourrions faire de l'intégration et du mapping de code; qu'importe son lieu de développement puisque nous allions appliquer les mêmes pratiques. C'est ce que nous avons fait et cela a très bien fonctionné, au delà de toutes nos espérances: c'était parfait.

Suite à cela, la société Indienne s'est rapprochée de moi pour OCTO Technology UK afin de savoir s'il était possible de créer une société ensemble et offrir ainsi ses services aux entreprises. J'en ai parlé à OCTO Technology France pour savoir s'ils étaient intéressés. Ce fut le cas: c'était la création de Pivolis.

Pivolis est une société de services en développements informatiques qui utilise des ressources offshores. Nous faisons le pilotage de ces projets. Nous comptons 6 personnes dans la société. Nous avons aujourd'hui un gros projet de la société BNP Paribas Securites Services qui compte une centaine de développeurs dont la moitié travaille en Inde et l'autre moitié en France.

L'Open Source

Comment choisit-on un projet Open Source ?

Pour être relativement tranquille, il est possible de prendre des projets Open Source de sphères bien connues comme Apache car un projet Apache qui s'arrête c'est très très rare. Codehaus, c'est pas mal aussi. Par contre avec Sourceforge, c'est un peu plus délicat car il n'y a pas vraiment de processus d'acceptation ou de refus des projets: ils sont globalement tous acceptés. C'est donc plus difficile de savoir qui est derrière mais aussi de savoir si quelqu'un le reprendra si jamais il devait s'arrêter. Même s'il y a des projets très bien sur SourceForge, il vaut mieux en apprendre d'avantage en regardant l'activité ou le nombre de participants au développement.

Y a-t-il d'autres critères pour choisir un projet Open Source ?

Il faut voir comment bouge ce projet. Quand je vois que la dernière release date de 6 mois ou un an, je ne le sélectionne pas. Cela ne me semble pas important que cela soit des releases de beta ou alpha mais il faut regarder s'il y a des releases fréquentes. Après il faut regarder la mailing list: est-ce qu'il y a de l'activité ? Il suffit de poser une question, et regarder si on répond. Il faut regarder également la rapidité du support, la documentation : est-ce qu'il y a une bonne documentation, ça c'est très important. Même si le projet n'est pas encore stable, ce sont des critères importants. Autre critère, il faut cherche le nombre de livres qu'il y a là-dessus: les projets stables suffisamment gros devraient avoir un certain nombre de bouquins qui prouvent qu'ils ont été assimilés.

Quels sont les avantages et faiblesses d'un projet s'appuyant sur un mode de fonctionnement Open Source ?

Un des avantages, c'est de bénéficier gratuitement de corrections de bogues, de nouvelles versions. On profite également de la documentation qui se met à jour gratuitement. Une ligne de code en moins à développer c'est précieux. Une ligne de code çà coûte très très cher parce qu'il faut l'écrire, la tester, la documenter, faire le transfère de connaissances à tous les gens qui arrivent. Il faudrait évaluer le coût d'une ligne de code mais cela doit être énorme. Donc si on peut externaliser ce bout de code ailleurs, c'est fabuleux.

L'avantage par rapport à du commercial, c'est d'avoir les sources. L'avantage des sources est de pouvoir rapidement soumettre une correction quand cela ne fonctionne pas. Pour avoir vécu les Weblogic, Websphere et autres, remonter un bogue que tu as trouvé et obtenir un correctif cela n'arrive pratiquement jamais et lorsque cela arrive, cela prend au moins 6 mois. En Open Source faire une demande pour corriger un bogue peut prendre du temps. Mais si celui qui fait cette demande soumet un correctif là, cela devient quasiment immédiat. L'autre intérêt c'est d'avoir du support, contrairement à ce qui est souvent invoqué pour ne pas prendre de l'Open Source. Il y a souvent beaucoup plus de support en Open Source que pour les projets pour lesquels on paye du support. Dans l'Open Source, la question est posée directement aux personnes qui ont développé le projet et souvent, ils mettent un point d'honneur à répondre rapidement. Pour un projet commercial il faudra passer par différents interlocuteurs du support technique qui seront rarement capable de répondre immédiatement.

Pour les inconvénients et les faiblesses, le seul point noir que je vois est, quand on ne fait pas de développement et qu'on choisit un framework qui ne répond pas à son besoin ou qui a des bogues importants qu'on ne peut pas corriger: là c'est difficile. Je pense que l'Open Source c'est très très bien quand on a des équipes de développement. Si on ne dispose pas d'une équipe de développement, il faut quelqu'un qui puisse faire le support. Pour les projets Open Source les plus connus, il y a des sociétés qui proposent un support. Pour une société qui fait du développement, là c'est génial, car elle va utiliser le projet comme son usine de développement. Il suffit qu'il y ait une personne dans ton projet qui suive la mailing-list, qui dise ce dont il a besoin. Elle va pouvoir orienter le projet pour aller dans sa direction. Si en plus elle est commiteur elle a encore plus de pouvoir pour s'assurer que le projet va dans la direction voulue.

Est-ce que l'intérêt pour l'Opensource a changé de la part des entreprises ?

J'ai été chez Octo Technology pendant 5 ans. Depuis le début on proposait des projets Open Source que l'on avait sélectionné. En 1999 on avait déjà des frameworks, comme JUnit ou Ant. Aujourd'hui des projets qui n'utilisent pas l'Open Source cela doit être extrêmement rare. En revanche côté runtime cela a changé, JBoss, JOnAS, Apache sont des solutions Open Source utilisées en production. Dans le domaine de la banque cela reste plus mesuré, on trouve plus de Websphere ou de Weblogic.

Appliquez-vous dans le développement Offshore les principes du développement Opensource ?

Oui, je l'utilise sauf certains principes. Dans le projet Open Source il y a quelques pratiques qui ne sont pas "business". Par exemple les projets Open Source n'ont pas de date de livraison car ce sont des gens qui le font sur leur temps libre. Donc en plus des principes il faut compléter ces pratiques. Par exemple la gestion du change management, c'est assez mal géré dans l'Open Source parce qu'il n'y a pas de plan. Le change management, c'est quand on doit livrer pour une certaine date et le responsable du projet vient changer les objectifs "tiens non ça je préfèrerais que ce soit fait comme ça". Il faut aussi gérer les livraisons. Les builds, très souvent utilisés, sont un concept lié à l'Open Source. Grâce aux builds on peut envoyer sur une mailing list les diffs de commit.

Ce qui est amusant c'est de voir que la qualité des projets ne cesse d'augmenter. Aujourd'hui l'Open Source devient une référence de qualité. Les projets Open Source se sont professionalisés. On retrouve maintenant les pratiques de l'industrie dans l'Open Source, la rigueur par exemple mais cela va encore plus loin.

La gestion des releases dans les projets Open Source sont elles standardisées où est ce que cela tient aux personnes ?

Cela tient beaucoup aux personnes. Mais il y a des façons de faire qui sont de plus en plus répandues. Aujourd'hui un projet Open Source doit se gérer comme un projet business, ils font de la pub pour avoir de la lisibilité. Il faut écrire un bouquin, il faut donner des interviews par exemple. Les bons projets Open Source, ce sont également ceux qui se vendent bien.

Quels sont les projets Open Source auxquels vous contribuez en ce moment ?

Pour les projets actifs, il y a Cactus pour la correction de bogues ou les réponses aux questions, mais je ne travaille pas activement à la version supérieure de Cactus. Je travaille pour que la qualité reste. Après il y a Maven, je suis toujours actif pour le développement de plugins. Il y a le projet Pattern Testing où j'ai trouvé quelqu'un qui a pris le lead, je l'aide mais c'est lui qui code. J'ai démarré un nouveau projet qui se nomme Cargo. Il a démarré hier. Il permet d'offrir une API Java pour lancer, arrêter les containers. Là c'est du code que j'avais par Cactus que je sors. C'est un projet qui pourrait être utilisé par tous les IDE. J'espère que cela deviendra une référence.

Jakarta Cactus

Pouvez-vous présenter Jakarta Cactus? Combien de contributeurs compte le projet?

Cactus est un framework de tests unitaires pour les applications serveur et plus précisément pour les composants J2EE (servlets, JSP, taglibs, EJB). Pour l'instant Cactus est limité à ces composants mais il a pour vocation d'adresser encore plus de composants dans le futur. C'est un projet qui a presque 4 ans maintenant. Je suis "malheureusement" le contributeur principal du projet. Je dis "malheureusement" car j'aurai aimé qu'il y ait d'avantage de personnes qui y participent, mais ce n'est pas simple. Le nombre de contributeurs évolue: à un moment il y en avait 4, mais aujourd'hui je suis de nouveau seul commiteur actif, celui qui fait avancer le projet au jour le jour.

Mais il y aussi beaucoup de gens qui contribuent tous les jours en répondants aux questions sur la mailing list, ils contribuent en soumettant des patchs ou en donnant des idées. Nous avons 5 à 10 emails de trafic en moyenne par jour... en download nous étions à 2000 downloads il y a 2 ans, j'imagine que cela a augmenté mais je n'ai pas regardé depuis longtemps.

Le gros challenge des projets Open Source est de réussir à ce que des gens participent et à ce que le projet dépasse celui qui l'a créé: s'il s'en va, le projet continue à survivre, il y a un écosystème stable et viable. C'est vraiment la condition de succès d'un projet Open Source et à ce titre, je ne considère pas que Cactus soit un succès complet.

Qu'est-ce qui a provoqué le lancement de ce projet ?

J'ai toujours été très intéressé par la qualité en m'assurant que ce que je développe fonctionne bien. En 1998, je travaillais chez OCTO Technology, dans l'architecture de projets et plus précisément dans le développement J2EE. Je développais des servlets et des EJB, c'était le tout début. Je me suis demandé comment les tester, mais ce n'était pas facile car il y avait des liens avec le conteneur. J'ai alors créé dans le cadre d'un projet un mini Cactus. Je suis passé ensuite sur un autre projet d'entreprise ou j'ai pu encore améliorer ce mini Cactus. D'autres personnes d'OCTO Technology intéressées par cet outil ont commencées à faire des modifications de leurs projets pour brancher ce framework de tests.

Je me suis dit que c'était le moment, il fallait un endroit central afin que l'on puisse tous participer au projet et faire participer d'autres personnes: j'ai alors créé un projet nommé J2EEUnit sur SourceForge. J'étais quasiment le seul à participer mais des personnes l'utilisaient.

J'ai commencé à parler avec des personnes sur Jakarta et j'ai proposé J2EEUnit (NDLR: renommé en Cactus pour des raisons de marque déposée). On en a discuté et il a été accepté. Cela été un boom pour le projet de passer de SourceForge à la fondation Apache, cela donne une visibilité énorme: plus de gens qui l'utilisent, plus de commentaires, plus d'intérêt, ... Tout ça était fabuleux pour moi car j'étais tout seul avant et je rencontrais maintenant une communauté de gens qui avaient les mêmes intérêts et de l'expérience. Cela changeait car nous dialoguions entre projets alors que sur SourceForge cela se fait très peu. Cactus a trouvé non seulement une nouvelle maison mais aussi une famille.

OCTO Technology acceptait que vous travailliez sur ce projet ?

Tout à fait car OCTO Technology est une société qui vend du service et non du soft. En plus, la société a toujours été très ouverte à ce genre d'idées car il faut toujours être en avance de phase par rapport aux autres en gardant les connaissances, connaissances qui périment vite en plus. Il faut donc toujours progresser. Il n'y avait aucun soucis pour mettre le projet en Open Source.

Cactus est actuellement en version stable 1.6.1. Quelles seront les grosses évolutions de Cactus version 2 ?

Cactus version 2 est un projet à part: il pourrait porter un autre nom. J'ai essayé récemment à faire du refactoring sur Cactus 1.x avec l'idée de faire 2 parties: une API pour les utilisateurs et une API pour ceux qui veulent fournir des implémentations pour de nouveaux types de composants. Imaginons qu'une personne veuille tester unitairement des message-Driven beans ou des portlets. Ce sera compliqué, il faudra qu'elle re-code beaucoup de choses car il n'existe pas de SPI (Service Provider Interface) permettant de rajouter facilement cela. Je me suis dit, je vais faire ce refactoring en extrayant tout ce qui est commun à la création de ces nouveaux modules, ces nouveaux redirecteurs. Et en faisant cet exercice, je me suis aperçu qu'il n'y avait rien de commun. J'ai constaté alors que l'architecture n'était pas assez souple et flexible.

Je travaillais également depuis 1 an environ sur le Pattern Testing qui permet l'écriture de tests automatisés pour vérifier le design d'une application. C'est implémenté en utilisant les concepts d'Aspect avec AspectJ. On est capable en Pattern Testing d'écrire des tests sous la forme d'Aspects pour injecter des sondes dans le code afin de vérifier par exemple qu'il n'y a pas d'accès direct à la base de données mais que l'on passe bien par un service spécifique.

Je me suis dit alors que pour Cactus 2, il serait bien de pouvoir écrire les tests Cactus sous la forme d'Aspects car il y a déjà un langage d'interception et, sans rentrer dans les détails, cela permettra de supporter tous les types de conteneurs et composants: c'est vraiment générique.

Recherchez vous des volontaires pour participer à Cactus ? Si oui, quels sont les profils recherchés ?

Oui, nous recherchons toujours des volontaires. Mais, ce qui est "amusant" avec les volontaires Open Source c'est que c'est à double tranchant: c'est à la fois bien et pas bien. C'est bien car cela va aider à corriger des bogues, développer de nouvelles features, etc... mais c'est bien seulement si le volontaire reste à long terme dans le projet. A partir du moment ou le volontaire travaille sur une nouveau sujet, une nouvelle partie du projet, qu'il n'y a que lui qui maîtrise cette partie et qu'il s'en va, et bien c'est perdu car il n'y aura plus de support pour les évolutions ou les corrections de bogues. C'est déjà arrivé dans Cactus avec un très bon plugin pour Eclipse, sauf que le cœur de Cactus a évolué et la personne qui a fait cela est restée très peu longtemps: nous avons dû enlever ce plugin même s'il est très prêt de fonctionner. Il n'y a pas beaucoup de travail sur ce plugin pour quelqu'un qui connait bien le sujet mais il faut s'y plonger et avoir du temps à y consacrer.

Donc les volontaires c'est bien mais nous sommes intéressés par des gens qui veulent participer à long terme. Si une personne veut proposer un patch qui sera une correction de bogues, c'est très bien. Mais si c'est une nouvelle feature, c'est très dangereux car il faut que la personne s'investisse pour corriger les bogues et les demandes d'évolutions. Beaucoup de projets Open Source font donc très attention à la soumission de nouvelles features.

Il faut que les personnes soient intéressées intrinsèquement et souvent, ce qui est dur, c'est qu'elles sont intéressées ponctuellement. Elles travaillent sur un projet, ont un besoin de nouvelle feature mais 3 ou 6 mois après, lorsqu'elles changent de projet, la feature n'évolue plus car elles n'en ont plus besoin. Donc, oui nous cherchons des volontaires mais des personnes qui vont participer dans la durée.

Comment justifier la réalisation de tests unitaires ?

Ce n'est pas évident: les gens ne sont pas convaincus de l'utilité des tests. En fait, c'est quoi "développer" ? "Développer" ce n'est pas taper des lignes de code, mais produire des choses qui fonctionnent. Et le problème, c'est que dans beaucoup de projets on oublie ça. Du coup dans les plannings, les charges évaluées sont juste celles correspondantes à ce qu'il faut pour taper les lignes de code: l'estimation de charge n'inclue pas les tests. On dit souvent, pour développer il faut ça, et pour tester il faut ça, alors que le développement lui même devrait inclure les tests.

C'est encore difficile de faire un projet informatique, il y a encore beaucoup de projets qui dérapent, il faut un peu plus de temps que prévu. Les choses en plus, dont les tests unitaires, sont donc supprimés.

Toutes les méthodologies de type Agile aident car elles permettent de livrer en continu des fonctionnalités utiles au lieu de dire "je développe tout en parallèle et je livre à la fin". On livre à l'utilisateur une première feature qui fonctionne. Une fois que c'est bon, on livre la deuxième feature et ainsi de suite. Les utilisateurs peuvent commencer à utiliser l'application très vite. Avec cela, on s'aperçoit que le test ne peut pas être repoussé à la fin, il faut que l'on s'assure un minimum que cela fonctionne.

Il n'y a pas de solution miracle, ce qu'il faut c'est avoir des chefs de projets qui savent ce que sont les tests unitaires, qui comprennent ce que cela implique et qui fassent passer ce message. J'ai déjà vu des projets ou le gourou du projet avait envie de faire des tests unitaires mais le chef de projet ne relayait pas le message lors de la définition des budgets. S'il n'y a pas de temps alloué pour faire cela... le développeur c'est un être humain il ne va pas faire ça la nuit ou le week-end.

Maven

Pouvez-vous nous parler de Maven et de vos contributions pour ce projet ?

Ah, Maven! C'est un superbe projet. J'étais encore en Angleterre. Nous utilisions Ant pour nos projets avec des équipes réparties à Londres, en Irlande et en Inde. Il est important avec des équipes réparties d'avoir un bon système de build: nous avions avec Ant un build très puissant. Mais qui dit très puissant, dit aussi un peu compliqué car nous avions une cinquantaine de sous-projets avec chacun leur build Ant de 1000 lignes de script environ. Il est très difficile avec Ant de partager des bouts de script d'un build à l'autre ce qui rendait la maintenance fastidieuse. Dès que l'on voulait rajouter une fonction dans le build, il fallait faire le changement partout.

J'ai commencé à participer à Maven en 2002 alors que c'était encore le tout du début du projet. Cela correspondait exactement à ce que je voulais faire. Je l'ai essayé sur un projet d'entreprise sur lequel cela fonctionna bien. Grâce à cela, en journée je travaillais sur le projet d'entreprise avec Maven et le soir je participais au projet Maven pour le rendre utilisable sur de vrais projets avec de réelles contraintes. Progressivement, tous nos projets basés sur Ant ont été migrés sur Maven. Notre projet actuel de 100 développeurs, comme les autres, utilise Maven de bout en bout avec un build automatisé qui va très loin.

Il y a des gens qui sont en admiration devant Maven et d'autres qui le trouvent trop compliqué. Pour moi, cela n'a jamais été un problème car j'ai participé au développement du projet donc je connaissais toutes les astuces. Mais c'est vrai qu'au début c'était compliqué car il n'était pas encore stable et qu'il fallait avoir pas mal de connaissances. Aujourd'hui Maven a atteint un niveau beaucoup plus stable mais il y a encore une marge de progression gigantesque.

Maven s'adresse, avant tout, à des projets de quelle taille ?

C'est évidemment avec les gros projets qui ont le plus besoin d'avoir un build automatisé que l'on voit les avantages de Maven car, il est nécessaire de synchroniser les développements de tout le monde et de s'assurer que tout marche bien en intégration.

Mais la force de Maven, ce sont les plugins. En effet, comme il n'y a pas à coder une seule ligne pour démarrer, on peut l'utiliser sur un projet d'une personne très facilement. Si je travaille seul sur un projet, cela me prend 5 minutes à le mettre en place: j'ai mon project.xml puis mon POM à créer pour décrire mon projet et j'ai accès à 400 plugins qui me permettent de tout faire.

Il y a malgré tout un secteur où Maven est plus difficile: les projets relativement gros qui veulent migrer sur Maven alors qu'ils utilisent des builds très compliqués. Lorsque l'on a déjà développé son build d'une certaine façon, il faut accepter de casser beaucoup de choses car Maven prend en charge un grand nombre de traitements et que l'organisation Maven n'est pas forcément celle qui avait été choisie pour les anciens builds. C'est pour cette raison par exemple que Cactus n'utilise pas encore totalement Maven, car son build est très automatisé et complexe. Je sais que c'est possible, car je connais bien Maven, mais c'est très difficile.

Quels sont les plugins les plus populaires ou les plus utilisés ?

Il y a les plugins qui sont très utiles et les plugins qui font des choses qui sont hors du commun si on n'utilise pas Maven. Les plugins classiques c'est la compilation, la javadoc, la création d'un JAR, génération d'un WAR, d'un EAR, ... On peut les considérer commes des plugins de base.

Après, il y a des plugins qui sont plus originaux comme celui permettant de générer un site Web. Il suffit de faire maven site et tout d'un coup, cela gènère magiquement un site Web avec toutes les informations sur ton projet, avec des rapports sur l'exécution des tests ou sur la qualité métrique du code. Sans avoir rien fait, ce sont les mêmes 5 minutes du démarrage qui t'auront permises d'avoir un site Web, donc ça c'est chouette.

Il y a également beaucoup de plugins qui aident à la gestion du site de développement comme savoir quels sont les changelog pour chaque itération et ainsi plus tard générer les release notes. Il y a également le plugin Dashboard, je fais de la pub pour mes plugins, qui permet de réunir les mètriques de tous les autres plugins et les mettre dans un tableau afin d'avoir une vue synthétique de la qualité de ton code d'une manière générale. Ce sont des plugins qui sont un cran au dessus qui servent à faire du project management actif et qui permettent d'avoir une vraie visibilité du code développé, savoir ou cela en est, ... Il y a les plugins de build et ceux qui donnent une visibilité additionnelle sur le développement.

Quels sont les objectifs de la version 2.0 de Maven ?

Avant d'aborder le 2.0, la 1.0 aurait du sortir depuis longtemps, on est tous d'accord. Comme beaucoup de projets Open Source, on est pendant une phase indéterminée en 0.x, c'est le syndrome du "je sais que ça va changer mon API, et donc je ne veux pas mettre en 1 car cela veut dire que l'API est stable et que les gens vont l'utiliser etc..". En pratique cela ne veut rien dire. Même si un projet reste en 0.x pendant un certain temps les gens l'utiliseront à partir du moment où cela correspond à leurs besoins. Si l'API est modifiée, cela embêtera de toute façon beaucoup de gens. Donc, il aurait fallu passer depuis bien longtemps à la 1.0 de Maven, et faire progressivement des releases 1.1, 1.2, etc... Mais d'une autre coté, en faisant cela on risquait de livrer une version avec beaucoup de problèmes et décevoir ainsi beaucoup de gens. Donc on était vraiment bloqué. Cela a mis 2 ans pour passer à la 1.0 mais elle est plutôt stable et çà c'est bien.

La 2.0 c'est pour corriger des problèmes de la version 1.0. Le problème principal de la 1.0 c'est qu'il n'y a pas beaucoup de tests unitiaires des plugins. La raison principale à cela est qu'ils sont écris en Jelly, un langage de script avec lequel il n'est pas facile d'écrire des tests: nous sommes plus outillés dans le monde Java que dans le monde Jelly. C'est le premier constat. Le second constat est qu'il est compliqué de ré-utiliser du code Jelly directement. Si j'utilise un IDE et que je veux lui écrire un plugin qui ré-utilise un plugin Maven il faudra que je fasse une passerelle pour appeler le moteur Jelly, ce n'est donc pas très simple. Avec le problème de classloader c'est compliqué.

Ces deux constats font que pour Maven 2 tout sera écrit en Java. L'idée c'est de pouvoir tout ré-écrire les plugins en Java. En fait on va un peu plus loin que ça, on ne peut pas non plus priver les personnes qui ont déjà écrit en Jelly, on veut qu'il soit possible de ré-utiliser les plugins actuels mais également offrir d'autres langages éventuellement. Donc l'idée c'est d'ouvrir le c�ur de Maven afin qu'il accepte des plugins écrits dans à peu prêt n'importe quel langage, mais en préconisant Java. Donc tous les plugins fournis par Maven même seront écris en Java. C'est notre principal objectif. Ensuite, il y a plein de choses qu'on corrige, de petits détails, des choses qui manquaient. C'est le cas par exemple d'un paramètre, le type, qui manquait dans le POM qui décrit un projet.

La version 2.0 pourra être appelée depuis n'importe quel environnement: depuis un plugin Eclipse, un IDE quelconque, ... Quelqu'un qui écrit un IDE from scratch pourrait bénéficier directement de tous les plugins Maven pour son IDE. Par exemple pour la compilation, il pourrait appeler le plugin Maven de compilation. Ce serait comme construire un IDE comme on assemble des Meccano. Il irait beaucoup plus loin que les IDE traditionnels qui font la compilation, le jar ou le Javadoc. Sur ce principe, il y a l'idée de créer un IDE Maven avec les plugins Maven 2.

L'échéance de Maven 2, ça je ne le sais encore. J'ai participé pour les idées mais pas aux développements. Je suis un "gros" utilisateur de Maven et pour l'instant je travaille plus à corriger les plugins de Maven 1.0 que j'utilise tous les jours sur des projets.

Concernant Maven ne vaut-il mieux pas, pour une entreprise, développer en interne sa propre solution de gestion de projets ?

Il y a 2 alternatives possibles. La première consiste en effet à développer une solution maison, mais ce n'est pas plus simple: il faut expliquer au nouvel arrivant comment cela fonctionne, en général c'est plus ou moins bogué et çà coûte plus cher à maintenir. Donc au final cela revient largement plus cher.

L'autre alternative c'est qu'il y a rien, mais s'il n'y a rien, il faut que toute la procédure soit documentée et il faut que cela soit mis à jour régulièrement lorsque cela évolue. Je peux t'assurer que cela prendra beaucoup plus de temps. Mais avec Maven, ou un autre d'ailleurs, il y a une documentation standard. Tu peux donner la documentation à quelqu'un qui vient d'arriver afin qu'il la lise ou trouver des personnes qui ont déjà des expériences avec ce logiciel. C'est le contraire qui est dangereux.

Il y a 6 mois il ne fallait pas prendre Maven. Il fallait prendre Ant. Personne ne pouvait lutter contre Ant: il y a un grand nombre d'ouvrages, tu es tranquille sur plusieurs années. Maven il y a 6 mois ou 1 an ce n'était pas encore mûr. Aujourd'hui il y a Maven 1.0 cela rassure les gens. Il y a de plus en plus de projets autour de Maven et cela rassure également.

Nous remerçions Vincent Massol pour nous avoir accordé cet entretien.