new Blog( perso );

Eclipse est omniprésent, et tout le monde s’accorde pour dire que c’est devenu une usine à gaz ingérable. Je dois moi-même faire face aux excès d’humeur de mes petits camarades qui pestent sur un Eclipse “préparé” par mes soins et qui malgré ça plante allègrement ou rame tout ce qu’il peut.

La concurrence, c’est NetBeans – qui a vraiment du mal à décoller même si on m’en a dit beaucoup de bien – et Idea, qui a une excellente réputation, mais malheureusement aussi un prix

Ca, c’était la situation hier. Jetbrains vient en effet de passer son IDE en opensource

Toutes les fonctionnalités de la version payante ne sont bien sur pas au rendez-vous, mais la liste est déjà bien assez large pour contenter les utilisateurs d’Eclipse lassés du “building workspace”

Reste qu’il va falloir franchir le pas de dés-apprendre toute ces (mauvaises ?) habitudes qu’on a si chèrement acquises sous Eclipse, identifier les bons plugins et tout et tout, mais je suis convaincu que ce billet d’entrée sera vite amorti, à commencer par tout ceux qui galèrent avec l’intégration vraiment pourave de Maven dans Eclipse (on attend toujours ce fameux m2e 0.9.9) ...

Pour ma part, je tente l’expérience dès demain :)

Pour plus d’infos, ça se passe ici : http://www.jetbrains.com/idea/nextversion/free_java_ide.html

Mon projet préféré du moment est une énorme usine à gaz avec un bon paquet de modules Maven. Sous Eclipse avec m2eclipse, des builds Maven se lancent en pagaille si on active le "build automatically".

<profiles>
 <profile>
    <id>m2eclipse</id>
    <activation>
      <property>
        <name>osgi.bundles.defaultStartLevel</name>
      </property>
    </activation>

    <build>
      <plugins>
        <plugin>
          <groupId>org.codehaus.mojo</groupId>
          <artifactId>aspectj-maven-plugin</artifactId>
          <configuration>
            <excludes>
              <exclude>**/*.java</exclude>
            </excludes>
          </configuration>
       </plugin>
      </plugins>
    </build>
</profile>

Avec cette conf magique, AJDT est correctement configuré par m2eclipse et fait parfaitement son boulot (le hotswap permet ainsi d'éditer le code et de constater le résultat à chaud dans Tomcat), ET les build maven sous eclipse sont raisonablement rapides, le plugin aspectj ne faisant plus rien.

Avec la sortie du Plugin Google Eclipse, il me restait à intégrer proprement le couple Maven + GWT avec l'IDE le plus connu des développeurs java - je n'ai pas dit le meilleur ;p

Après avoir publiquement rennoncé à Archiva pour Nexus on pourrait me croire vendu à Sonatype ... et bien non. Utilisateur de m2eclipse je teste actuellement la dernière mouture de eclipse-iam (aka "q4e") et je le trouve bluffant !

Mon extension pour m2eclipse commence à fonctionner. Elle permet de lire la configuration Checkstyle à partir du plugin maven et de l'appliquer au plugin eclipse.

L'intégration de maven sous Eclipse est un sujet qui a pris .. un certain retard si on compare à NetBeans ou Idea. La faute (sans doute) à la gueguerre entre Sonatype et Exists, les deux sociétés qui emploient des core-développeurs de maven, et qui supportent chacune un projet concurrent (m2eclipse vs q4e).

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.

m2eclipse 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 :

1. 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
2. le seul moyen d'améliorer les choses est de "communiquer" pour que chacun apporte sa petite pierre à l'édifice.
   

Voici donc ma petite pierre :

• 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.
  

m2eclipse et q4e ont tous deux vu leur proposition auprès de la fondation Eclipse acceptée. Voila qui ne nous avance pas beaucoup dans le choix d'une solution !

mon point de vue :

• m2eclipse utilise des icônes plus sympa. C'est con mais c'est INDISPENSABLE pour une adoption par les utilisateur !
• m2eclipse 0.9.4 apporte quelque changements qui le rend plus conforme à l'utilisation de maven en ligne de commande. On a donc moins de "surprises" lors de son utilisation
• m2eclipse 0.9.4 supporte le plugin sysdeo-tomcat ! la réactivité de l'équipe de dev à mes demande sur ce sujet a été très bonne.
• q4e inclut un outil d'analyse des dépendance, particulièrement attendu par les utilisateurs de maven : une version graphique et dynamique du "mvn dependency:tree", super pratique
• q4e utilise par défaut les noms de répertoire physiques comme nom de project eclipse, et pas l'artifactId. m2eclipse propose un "pattern" qui permet par exemple d'avoir plusieurs versions du même module sous eclipse, très pratique pour reporter des corrections entre versions
• le menu "import > existing project" de m2eclipse est au premier niveau, ce qui le met plus en valeur (il est visible par défaut) que celui de q4e (maven > maven project). C'est du détail mais ça participe à l'image de bonne intégration sous eclipse.

Espérons (on peut rêver) que l'intégration dans la fondation Eclipse fera peu a peu apparaître des points communs entre ces plugins, et pourquoi pas le début du premier pas vers un développement commun. C'est dommage toute cette déperdition d'énergie...

Il semblerait (à confirmer) que la fondation eclipse ait pour principe de ne laisser sortir qu'un seul plugin du processus d'incubation. On aura donc soit une fusion des plugins, soit l'élimination de l'un des deux. Reste a savoir dans quel délai...

Update :

J'ai raté ce message, double-posté sur les forums q4e et m2eclipse :

http://www.eclipse.org/newsportal/article.php?id=88&group=eclipse.technology.iam#88

On y vois le début d'une collaboration entre ces deux projets, quelques petites traces de règlement de compte - "nous aussi on l'a fait" - et des explications sur les incompatibilités techniques.

C'est donc un grand pas entre ces deux communautés, qui me laissent espérer un plugin de qualité pour dans pas si longtemps que ça ;-)

Update (07/2008) :

La version 0.9.5 de m2eclipse comporte désormais un éditeur de POM très propre et un analyseur de dépendance (arbre et graphe) très pratique. La dynamique semble être plus du côté de m2eclipse, mais de là à deviner ce qui va sortir de l'incubateur d'Eclipse ...

Maven est fondamentalement un outil en ligne de commande. Ceci n'empêche pas que de nombreux utilisateurs réclament une intégration sous Eclipse.

La communauté des développeurs Maven subit alors un schisme :
d'un côté, m2Eclipse (développé par Sonatype), de l'autre q4e (développé par Devzug)

Dans les deux cas, le code a été passé sous license EPL et proposé comme contribution à la fondation Eclipse. On est donc pas très avancé pour savoir lequel sera officiellement soutenu.

La co...erie dans l'histoire c'est que ces deux plugins sont très comparables :

• import de projets maven (gestion multi-modules, téléchargement des jar et sources.jar, lancement des générateurs de code ...)
• édition plus ou moins avancée des POM.xml (assistance à l'identification des dépendances)
• lancement de maven "à la souris" - ça n'apporte pas grand chose
  
• des jolis wizards, par exemple pour utiliser les archetypes
  

+ m2eclispe utilise des icônes plus sympas
- m2eclipse n'utilise pas les répertoires standard de maven : il compile dans "target-eclipse" et ne mappe pas les répertoires de ressources vers "classes".
+ q4e propose une vue d'analyse des dépendance très sympa

La principale fonction qui m'intéresse est l'import direct de projets maven. Et c'est la fonction la plus obscure et la moins configurable. Dans les deux cas, aucune idée de ce que le "embedded maven" exécute durant cet import, et en particulier, difficile de venir y ajouter sa conf ou ses plugins maison.

J'utilise par exemple le plugin sysdeo-tomcat-maven-plugin pour configurer tomcat :

• pour m2eclipse il a fallu modifier le plugin et le recompiler.

• pour q4e ... aucune idée (je n'ai pas trop cherché) mais ça doit être équivalent.

Je pense donc que je ne vais pas tout de suite renoncer au bon vieux mvn eclipse:eclipse

En passant de maven 1 à maven 2, on corrige (entre autre) un défaut de maven 1 : on peut faire un "clean" sur un projet qui n'a encore jamais été compilé. Quel intérêt ? sur un serveur d'intégration continue, le tout premier build ne pouvait pas être du type "maven clean jar:install" !


Un autre bug gênant : pour configurer son IDE préféré (Eclipse dans mon cas, tout simplement parce que je n'ai pas pris le temps de tester Idea ni Netbeans !), on lance "mvn eclipse:eclipse". Et la, crac, la simple présence d'un projet EAR fait planter le build. La faute aux plugin eclipse qui exécute la phase generate-sources, seul moyen d'identifier tous les répertoires de code généré. On doit donc faire un "mvn install" avant de pouvoir bosser sous Eclipse. Mais alors, si le code sous SVN est buggé et ne compile pas ?... reste le bloc note pour corriger !

Je cherche un moyen de fixer ce problème. Deux options :

• trouver une astuce pour que la résolution des dépendances n'échoue pas. Par exemple, enregistrer chaque module comme "artifact virtuel" pour qu'il ne soit pas recherché sur le repository. Seulement les composants interne de Maven sont un peu obscurs et pas trop ouverts à ce genre de "hack".
• faire évouler l'API des plugins maven ("mojo") pour que le plugin eclipse puisse identifier les plugins générateur et le répertoire qu'ils créent. Pourquoi pas profiter du passage à maven 2.1, mais encore faut-il convaincre la communauté :-/

J'aurais peut-être du commencer par quelque chose de plus simple...