Voilà une question que se pose beaucoup de monde depuis quelques temps : est ce que les plugins sont assez matures pour les mettre en place sur de vrais projets en entreprise ?
Et surtout si c’est le cas, est ce que je ne choisis pas le mauvais cheval ?

Sans entrer dans les détails du fonctionnement des plugins (je le pourrais si ça intéresse assez de monde), voici quelques éléments de réponses…

Ok, la DSI a décidé d’industrialiser les builds des projets avec Maven depuis longtemps, mais la fondation Eclipse n’a jamais rien fait pour faciliter son intégration dans l’IDE. Les développeurs doivent passer par la ligne de commande, mais ils perdent du temps à switcher hors de l’IDE, se trompent parfois dans les instructions, voire ne savent pas comment utiliser le fameux pom.xml. De toute façon la structure des projets ne se prête pas au bon fonctionnement de tous les plugins Maven.

En clair on rationnalise un processus, mais en contrepartie on ajoute une distraction inutile au développeur lambda sans pour autant exploiter à fond l’outil. Quel gain de productivité au final ?

Heureusement les gens de Maven se sont aussi posés la question, et cela a donné naissance non pas à un mais deux plugins pour Eclipse. Alors qui sont-ils ?

D’un côté nous avons M2Eclipse soutenu par Sonatype et qui compte comme contributeur prestigieux… Jason Van Zyl, le leader du projet Maven.
De l’autre nous avons IAM/Q4E soutenu par une solide équipe d’Exist Global.

Les deux projets sont passés sous licence EPL 1.0 et ont lancés leur procédure d’intégration à la fondation Eclipse (et les deux ont été acceptées). De même, beaucoup de fonctionnalités se recoupent entre les deux plugins (avec un léger avantage à M2Eclipse pour le moment). Super, mais alors comment choisir ?

Déjà il faut savoir qu’à terme la question ne se posera plus car la fondation Eclipse ne fera sortir de son incubateur qu’un seul plugin (”il ne peut en rester qu’un..”). Du coup on commence à parler d’une fusion, ou au moins de faciliter la collaboration entre les deux projets…
En fait, peu importe son choix, au final il sortira un plugin pérènne qui couvrira toutes les fonctionnalités actuelles et d’avantage… Et il est probable qu’il remette en cause les préconisations pouvant êtres établies avec les versions actuelles des plugins…

Pour l’instant le choix, car il faut en faire un, dépend beaucoup des besoins réels du projet. Il semble difficile de préconniser une solution unique pour une organisation entière car ce qui différencie ces deux plugins (qui ne cohabitent pas très bien entre eux) est en fait très complémentaire.
Il existe aussi encore de nombreux bugs dans chacun mais ils représentent déjà malgré tout une avancée notable par rapport au plugin eclipse de Maven et peuvent prétendre à son remplacement sur de vrais projets (c’est d’ailleurs l’objet de ma mission actuelle).

Enfin, un des gros point noir reste Eclipse lui même qui ne sait véritablement gérer qu’une structure de type “flat”, alors que la convention pour Maven est une structure hiérarchique (le projet enfant sous sont projet parent)… Et là… le correctif n’est pas prévu avant Eclipse 4 !

En fait, et si vous passiez à NetBeans ? Personnellement, je vais voir ce que donne Maven avec cet IDE, si ça fonctionne bien la décision risque de ne pas être longue à prendre…