m2eclipse prend comme parti de laisser Maven gérer les "ressources" (fichiers de conf, XML...) à la place d'Eclipse. Vu que l'utilisation du filtering Maven reste marginale ça ne concerne que peu de personnes. Cependant, cela signifie pour les autres un cycle mvn process-resource à chaque build incrémental d'Eclipse.
... et il y en a un paquet des builds incrémentaux, sans parler des multi-modules ou chaque projet déclenche un build des autres. On termine donc avec des builds maven en pagaille, à reconstruire 10 fois le même module :'(
Alors, oui, m2eclipse permet à notre générateur de code de prendre en compte la moindre modification de WSDL. Mais qui modifie son WSDL chaque minute ? Le prix à payer est délirant, à moins d'avoir un PC octo-processeur à quatre coeurs (et encore ?).
Moralité : le bon vieux mvn eclispe:eclipse, bien qu'il soit parfois un peu compliqué à configurer au petits oignons (je pense à AJDT) a de beaux jours devant lui !
4 commentaires:
Bonjour,
C'est étrange, cela fait plus d'un an que j'utilise Maven Integration for eclipse en build incrémental chez plusieurs clients et cela fonctionne extrêmement bien.
Nous utilisons par ailleurs le filtering des ressources avec bcp de succès.
Le projet est multimodule et il y a un model jaxbean auto-généré (c'est pas du wsdl mais on pourrait faire un parallèle)
Le build incrémental permet de coupler maven2 avec WTP... c'est une feature à laquelle je suis tellement habitué que je préfèrerai abandonner maven plutôt que le déploiement à chaud de WTP...
Par contre, nous avons placé le modèle auto-généré dans un module à part afin d'éviter de le régénérer systématiquement à chaque build incrémental.
La seule difficulté rencontrée viens des <exclude> qui ne sont pas ajoutés dans le buildpath d'eclipse. (C'est pourtant indispensable d'avoir un <exclude>**/.svn/</exclude> sur du multimodule. Eclipse génère des conflits en mergeant les modules sinon)
Le fait que tu apprécie WTP montre que tu es déjà rodé sur les environnements "lourds". Désolé de le dire mais je trouve que la logique de WTP (redéployer à chaque build) est incroyablement couteuse. J'apprécie le hot-replace mais pas à ce prix (voir plutôt du côté de JavaRebel). Nous n'avons peut être pas non plus le même volume à traiter : mon projet actuel est éléphantesque, avec 900 classes générées à partir du WSDL...
J'ai utilisé la même stratégie d'isoler le code généré dans un module dédié. m2eclipse fonctionne, mais ça rame dur tout de même.
Pourtant les dernier build de dev de m2e me semble bien rapide (pas mal de cache ajouté dans trunk maven).
Sinon pour les builds incrémentaux c'est possible via le trunk du resources plugin :-).
Mais il faut activer celà via un profile m2e (exemple de pom http://svn.sonatype.org/nexus/trunk/nexus-parent/pom.xml) et oui le resources plugin fonctionne bien plus vite.
J'ai en effet testé la 0.9.9 dans son mode "custom" qui est très attirant sur le papier.
1. j'utilise deux projectCOnfigurators que je doit mettre a jour suite au changement d'API. Pas de bol il ne se déploient pas, et les logs d'Eclipse sont muets.
2. plusieurs plugins sont incompatibles, par exemple j'ai un NoSuchMethod avec JAXB. Embettant pour traiter mes 66 WSDL ;)
Enregistrer un commentaire