new Blog( perso );

Après avoir pesté toute la journée d’hier sur Eclipse, je viens de penser à une piste pour résoudre mon problème :

J’ai utilisé dans mon POM le pseudo-plugin org.maven.ide.eclipse::lifecycle-mapping que proposait m2eclipse 0.9.9 pour activer la compilation incrémentale. En conservant ce plugin activé, m2eclipse 0.10 ne prend plus en charge la configuration d’Eclipse et je me retrouve donc avec mes soucis de WTP pas configuré et de target/generated-sources absents.

En virant ce plugin, m2eclipse 0.10 retrouve son mode nominal et la configuration se passe donc “comme dans le manuel”.

mea culpa donc, je suis un bête gars qui a essayé les pré-version et a cru que la compatibilité serait au rendez-vous, mais quel boulet celui-là.

J’ai tout de même posté sur le sujet sur user@m2eclipse.codehaus.org,  en espérant que ça puisse servir à d’autres.

L’actu Maven du mois de février est chargé :

Le plugin Maven-Release passe (enfin) en 2.0, vous pouvez donc profiter d’un mécanisme très complet et bien ficelé de gestion des releases sans reposer sur un statut “beta”, ce qui pouvait en effrayer quelques-un.

fini les m2eclipse-0.9.9-dev, avec la sortie officielle de m2e 0.10.0

Non ce n’est pas un erreur, il ne s’agit pas d’une 1.0.0 de m2eclipse, celle qui aurait annoncé enfin l’intégration efficace de Maven dans Eclipse. C’est plutôt une milestone de ce que sera cette intégration .. un jour.

Sans compter que Sonatype a choisi de mettre de côté l’intégration SVN, WTP ou AJDT faute de ressources pour les supporter efficacement, et préfère ce concentrer sur le noyau. Si le principe semble assez logique (on ne peut pas courir plusieurs lièvres à la fois) les utilisateurs vont vite être déçus de voir qu’il ont attendu 8 mois (la précédente version stable 0.9.8) pour ne toujours pas avoir un résultat complètement fonctionnel.

Pour ma part, la configuration de WTP ne marche tout simplement pas, alors qu’elle fonctionnait avec une 0.9.9 récente (?). Aux questions sur ce sujet la réponse est systématiquement, “nos efforts se concentrent sur le code, on verra le reste après”.

Je ne leur jetterais pas la pierre, car en tant que mainteneur de l’intégration m2eclipse / eclipse-checkstyle je me rend compte que le développement de plugin Eclispe est un art délicat et que j’y suis bien malhabile. Reste qu’on a pas fini de se plaindre de la piètre intégration du couple Eclipse + Maven comme environnement de développement. Wait & See, encore et toujours…

Julien Dubois a lancé le débat sur son blog en présentant ses astuces pour un build plus réactif. Entre autres idées, il utilise un disque SSD pour espace de travail.

Je ne suis pas du tout convaincu par cette option, vu que ce type de disque n’est pas très tolérant aux écritures multiples. Je pense que, si les perfs peuvent être meilleures sur le coup, la durée de vie de la bête risque d’en prendre un coup.

Une autre option que je suis en train d’expérimenter, suite à la même analyse venant de Julien -- l’autre Julien, celui du BreizhJug ;)

Comme mon PC est sous Windows XP 32bits je ne peux pas profiter à 100% de mes deux barettes de RAM de 2Go. Windows ne voit que 3Go adressables. Même le mode “PAE” n’y a rien changé. Cependant, il existe des RamDisk comme Gavotte RAMdisk qui savent contourner ce problème et récupérer cet espace perdu. Un RamDisk de 1Go, bien assez pour mettre mon workspace.

mvn clean install -Dmaven.test.skip=true

sur le HD “classique” :

[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 48 seconds

sur le RamDisk :

[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 30 seconds

Reste à voir ce que ça donne sous Eclipse …

Autres pistes à creuser :

• Tuer cette saloperie de process MacAffee
• Utiliser JRebel (des licences offertes au BreizhJUG !)
• Utiliser un disque SSD pour le repository maven (moins sujet aux écritures)
• Se payer un PC (voir un Mac ?) plus adapté aux devs !

Update (pour ceux qui ont la flemme de lire les commentaires)

Placer le workspace en ramdisk booste un peu les perfs, mais pas autant que de placer le repository Maven ! Il faut dire que nos outils passent leur temps à charger des libs en tout genre. En plus, c’est un moyen simple pour faire du ménage dans le repo – à condition d’avoir un repo manager qui fournit les artefacts via le réseau local :)

Ca pourrait être pas mal non plus de mettre l’OS en ramdisk :p