Dans le monde opensource on a coutume de dire que la concurrence est bénéfique. Seulement dans ce cas, chacun développe grosso-modo les mêmes fonctionnalités, et sur la base de la même plateforme à quelques détails techniques près.
m2eclip
se remporte pour ma part un court avantage (mais ce n'est qu'un avis parmi tant d'autres) : les échanges que j'ai pu avoir avec les développeurs montrent une grande réactivité et une réelle volonté d'ouverture.Dans mon cas, j'ai voulu ajouter le support de CheckStyle à m2eclipse; autrement dit, une extension m2eclipse qui va lire la conf de maven-checkstyle-plugin et la "traduire" pour configurer eclipse-cs, le plugin Checkstyle pour Eclipse.
Le bon point de départ, c'est que la plateforme Eclipse est conçue pour ce type de greffe de fonctionnalités (les fameux plugins) et m2eclipse ne déroge pas à la règle. Il y a donc une API très simple pour venir participer à la phase de configuration d'un projet Maven sous Eclipse.
La mauvaise surprise, c'est que cete API est un peu trop simple même dès qu'on a besoin de manipuler des concepts maven (classpath, résolution de dependances, ...). Comme il faut en plus découvrir comment se programme le plugin eclipse qu'on désire supporter, ça fait beaucoup de choses. A moins d'être un pro d'Eclipse + un guru de Maven, on en bave !
De rapides échanges avec Eugene Kuleshov m'ont convaincu que :
- je ne suis pas tout seul dans cette galère, et toute l'équipe de dev de maven est prête à apporter aide et conseils
- le seul moyen d'améliorer les choses est de "communiquer" pour que chacun apporte sa petite pierre à l'édifice.
- une page du Wiki qui décrit le principe et les pratiques à connaître.
- un ticket Jira pour permettre à chaque contributeur qui est contraint de réinventer l'eau chaude de "mutualiser" ses efforts.
