new Blog( perso );

Affichage des articles dont le libellé est m2eclipse. Afficher tous les articles

19 février 2010

Actu Maven … suite

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.

23 juillet 2009

m2eclipse - avec modération

La dernière version "dev" de m2eclipse (0.9.9) introduit les prémisses de ce que pourrait être un support correct de Maven dans Eclipse.

L'idée est de marier les plugins Maven avec le build incrémental d'Eclipse, plutôt que de lancer en série des builds Maven (potentiellement bien assez longs) à chaque modification d'un fichier du workspace. Dans la version 0.9.8, avec un bon gros projet multi-module et quelques plugins de génération de code ou d'instrumentation AOP le build automatically est absolument inexploitable.

On peut donc espérer voir enfin le bout du tunnel ... et effectivement sur un projet de test la différence est significative. On se croirait presque sous InteliJ Idea :)

Tout irait bien si cette 0.9.9 ne devait pas ce fonctionnement avancé à un build récent de maven 3, ce qui inclut les nouvelles API de gestion des artefacts maven (Mercury). Autrement dit, tout plugin qui dépendrait un peu trop des API de résolution d'artefacts gaufre lamentablement avec cette version. Exemple, la génération de code JAXB (org.jvnet:jaxb2-maven-plugin) :

java.lang.NullPointerException

at org.apache.maven.project.artifact.MavenMetadataSource.createArtifacts(

Ca peut aussi prendre des formes plus amusantes :

java.lang.NoSuchMethodError: org.apache.maven.artifact.resolver.ArtifactResolutionResult.getArtifactResolutionNodes()Ljava/util/Set;

Précisons aussi que l'API des ProjectConfigurator a changé. Elle donnait un avantage à m2eclipse en permettant de configurer automagiquement les plugins Eclipse équivalent de plugins Maven (SVN, Checkstyle, Sysdeo-Tomcat...). Il va falloir attendre la mise à jour des quelques plugins Eclipse qui ont fait l'effort de développer un support Maven2, et/ou la totale compatibilité des plugins Maven2 avec Maven3.

Moralité : à moins d'avoir un projet vraiment pas bien méchant, ne tentez surtout pas la mise à jour ! Ce numéro de version symbolique "0.9.9" ne signifie pas selon moi qu'on est si proche que ça d'un m2eclipse 1.0-final capable de prendre en charge des projets Maven issus de la vraie vie.

26 mai 2009

Maven, Eclipse et GWT main dans la main

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

C'est désormais chose faite avec le dernier SNAPSHOT du plugin GWT, qui devrait clore une longue liste avant une release que j'espère proche, le temps de fixer les derniers bugs et erreurs de documentations.

Comme je l'explique sur cette page, la principale difficulté est que le plugin Google Eclipse n'est pas très "maven compliant" et oblige à faire quelques concessions. Cependant, avec l'aide de m2eclipse (ça doit aussi marcher avec IAM, je n'ai pas encore testé) on obtient le résultat suivant, que vous pouvez expérimenter à la maison en utilisant le projet de test it/reactor du plugin, ou sur votre propre projet (dites moi ce que ça donne) :

import du projet Maven sous Eclipse par m2eclipse. Les dépendances, répertoires de sources et de génération de code sont identifiées et configurés sous Eclipse, et surtout lesmodules d'un multi-projet et dépendances présentes dans le workspace sont "résolues" en tant que références inter-projet et non via les jars du repository local.
ajout du support GWT (étape encore manuelle, j'y travaille) via Google Eclipse Plugin. Soucis ici, le plugin ajoute lui même les dépendances GWT qui font donc doublon avec celles gérées par m2eclipse. Ca n'a pas l'air gênant à condition bien sûr que les versions soient cohérentes. Si quelqu'un à une astuce je prend ;)
génération des lanceurs pour les modules de l'application en lançant mvn gwt:eclipse. Cette tâche gère désormais aussi bien les lanceurs "classiques" et ceux exploitant le plugin Google Eclipse (cas par défaut). Au passage, le plugin prépare le répertoire /war du mode hosté.
un simple run as > web application sur le lanceur généré et le mode hosté démarre. L'URL de la page web hôte n'étant pas déclarée dans le fichier module, j'ai pris comme convention qu'elle porte le même nom que le module et est présente dans son répertoire public. C'est un peu limitatif mais ça doit être assez courant. Sinon il suffit d'éditer la configuration d'exécution.

Le gros progrès (en terme de confort et de productivité) c'est que si votre application est découpée en modules maven, une modification dans le code source d'un de ces modules sera directement exploitable dans le navigateur hosté par un simple refresh. Pas besoin de repackager un Jar ou tout autre manipulation - perte de temps.

Pour aller au delà du serveur hosté et passer sur un "vrai" serveur d'appli (-noserver) il faut jongler un peu entre le plugin maven-war et les chemins "en dur" choisis par Google, mais on s'en sort.

On a donc enfin une solution productive pour faire du GWT sous Eclipse sans s'empêtrer dans des builds Maven sans fin. Reste à vérifier que tout ça reste bien compatible avec le fonctionnement "hors eclipse" du plugin : La tâche gwt:run a encore ses fans (à moins que ce soit juste du anti-Eclipse ?)

Je n'ai pas testé le support de GWT sous IDea ou NetBeans, mais si un fonctionnement équivalent est possible je serais ravi de l'intégrer au plugin - les patchs sont bienvenus :)

18 mai 2009

m2eclipse vs IAM ? Non m2eclipse + IAM

Lorsque la fondation Eclipse a annoncé accepter deux plugins concurrents et assez semblables dans son incubateur on pouvait se poser la question : qui va survivre à la course à l'investiture ?

On aurait pu penser que Eclispe serve de "sélection" pour un unique plugin et encourage le perdant à coopérer, mais il n'en est rien. La fondation a d'ailleurs joué le même tour à Sublcipse / Subversive.

Nous avons donc d'un côté IAM qui fait un gros boulot (peu visible) pour bien rentrer dans les règles de l'incubateur et m2eclipse qui continue son développement et enchaine les pré-versions. Les discutions qu'on a pu suivre entre les deux groupes ne laissaient pas vraiment présumer d'une fusion. Après une gueguerre "c'est pas moi m'sieur, c'est lui qu'a commencé", on nous a expliqué en quoi les deux plugins sont fondamentallement différents et donc ne peuvent céder un pouce de terrain.

Et voila que l'impensable se produit : Michael Poindexter (q4e) travaille actuellement sur la fusion des éditeurs de fichier POM proposé par chaque plugins. Il vient même d'obtenir le sésame utlime : le droit en écriture sur le code de m2eclipse - ce qui doit être nettement plus simple pour faire la fusion :).

On assiste donc à un assainissement de la concurrence entre les plugins, qui sont encore loin de n'en faire qu'un (il reste de lourdes incompatibilités) mais commencent à réfléchir ensemble.

Un peu d'optimisme fait du bien :D