La meilleure façon de rater son projet grâce à Maven2

Posté le par Benoit Lafontaine

A chaque fois que je vois un développeur Java passer son temps à regarder Maven tourner, j’y vois une perte de productivité.
D’autant plus que je vois très régulièrement cette tendance dans les projets, au sein d’OCTO et même dans ma propre utilisation.
Attention, je pense que Maven est très efficace pour améliorer la productivité des développements, mais le plus gros piège reste de « passer son temps dans la console ».

Pourquoi c’est mal ?
Quand on s’occupe de faire marcher Maven en bidouillant le POM et en regardant le build tourner dans la console : on ne développe pas.
Lorsqu’on développe, on doit passer son temps dans son IDE (eclipse, InteliJ, netbean, notepad ou vi selon les gouts) et coder du code, des tests.

maven is building

Cette image est un détournement, voici l’image originale : http://xkcd.com/303/

Alors pourquoi on passe son temps dans la console ?
En cherchant bien, j’en viens à la conclusion que la principale raison pour laquelle je passe mon temps dans la console est que mon IDE n’est pas bien configuré : un build dans mon IDE produit un résultat différent d’un build Maven, je ne fais plus confiance à mon IDE et la seule façon d’être sûr que mon code marche c’est de lancer la commande « mvn install » et d’attendre le message « Build Successfull ». Un cas typique est l’utilisation du filtering des ressources par Maven qui n’est pas géré nativement par Eclipse (le plugin m2eclipse résout ce problème).

Oui, mais ça ne marche pas : les tests dans mon IDE ont un comportement différents que dans Maven
Dans ce cas, je n’ai qu’un seul conseil : faites le marcher !
Votre configuration doit être assez bonne pour que quand vos tests passent dans l’IDE, vous devez être assez confiants pour pousser votre code dans votre gestionnaire de source.
Si vraiment il y a un problème, l’intégration continue va vous prévenir.

Lancer un build Maven sur votre poste et bidouiller vos configurations (Maven ou IDE) doit être rare :

  • quand l’UDD a retourné une erreur et que vous avez diagnostiqué que le problème vient d’une configuration
  • quand justement vous avez modifié votre POM (pour rajouter un plugin, ajouter un module, etc.)

Ces 2 cas doivent rester marginaux :

  • si votre UDD vous retourne constamment des erreurs de configuration, prenez le temps de les corriger durablement
  • si vous modifiez trop souvent vos POM, il est surement temps de prendre un peu de recul et de stabiliser la configuration des projets.

En résumé : Ne passez pas votre temps dans la console Maven, passez-le à coder dans votre IDE

11 commentaires sur “La meilleure façon de rater son projet grâce à Maven2”

  • Arnaud Héritier
    C'est très bon Benoît !!! J'espère que le message va finir par passer ;-) N'hésitez pas à demander de l'aide à OCTO si vous ne savez pas comment faire !
  • Stefane Fermigier
    Deux commandes magiques: > mvn eclipse:eclipse et > mvn idea:idea S.
  • Damien Gouyette
    Arnaud pourra te dire que le plugin eclipse n'est pas exempt de bug non plus. De plus, j'irais jusqu'à dire que certains aiment leur console. ;)
  • Gregory Boissinot
    Pour information, nous avons exactement les mêmes problématiques avec les autres systèmes de build. La mise en place d'un environnement de développement est indépendante du builder. L'étape de construction d'un environnement de développement (avec la configuration de son IDE) est effectivement crucial, mais doit être faite au maximum en amont du projet par une personne ayant une casquette d'intégrateur. Par la suite, les développeurs n'ont pas à toucher à Maven qui doit être un outil d'intégration et non un outil de développement.
  • Arnaud Héritier
    Le gros problème est effectivement que eclipse:eclipse a de nombreux bugs, peu de committeurs et des contributions très inégales. Le support de WTP marchote mais les plus gros soucis sont au niveau du classpath qui n'est pas à l'image de celui dans maven. m2eclipse c'est l'avenir. Il a de plus en plus de fonctionnalités et d'intégration avec les autres briques d'eclipse (WTP, AJDT, ...) mais sont gros point faible reste toujours les performances (surtout si le projet possède de nombreux sous-modules). Après il y a ceux qui aiment leur console (comme moi) mais cela ne m'empêche pas de me battre pour que le build basique (compile, TU, assemblage) soit le plus rapide possible. Enfin je suis d'accord avec Gregory, ce problème concerne tous les softs de build qui sont très souvent mal intégrés dans les IDEs. C'est pour cela qu'il faut traiter ce problème le plus tôt possible.
  • Benoit Lafontaine
    @Stephane : pendant longtemps, j'ai préféré eclipse:eclipse à m2eclipse, mais depuis quelques mois, je dois dire que m2eclipse a vraiment bien évolué. Comme Arnaud, aujourd'hui je recommande plutôt m2eclipse. Mais, au fond, peu importe l'IDE ou le plugin utilisé, l'important est que le developpeur ne soit pas impacté par le mécanisme de build : "je code, ca passe les tests, je commit".
  • B. BERRABAH
    Bonjour; L'idéal est de créer des ".launch" qui font exécuter les taches maven souhaitées.
  • Darko Stankovski
    Bonjour, Je ne suis pas sûr de comprendre une partie du message... Maven est verbeux, c'est vrai, et ça a un effet hypnotique. Cependant, et pour faire écho à l'intervention de Gregory Boissinot, peu importe la configuration, une fois le build lancé (et passée la phase précoce de la mise au point), le développeur ne devrait être intéressé que par la conclusion, et ne regarder les détails qu'en cas de build fail. De ce fait, exécuter maven dans une console et la laisser défiler ou par une série de clicks dans un IDE et laisser défiler la fenêtre console, c'est la même chose. Si la problématique est d'être averti rapidement du résultat, il convient de se rappeler qu'un système d'exploitation offre de nombreux outils et que la configuration du poste de travail ne se limite pas à la configuration de l'IDE. Ainsi, lancer cette commande légèrement ;) enrichie : mvn install | notify-send --icon=info "Fin de build" "`if [ \$? = 0 ]; then echo Build ok \:\); else echo Build Fail \:\(; fi`" permet d'être notifié du build que l'on retourne sous l'IDE, que l'on soit en train de remplir son compte-rendu d'activité, que l'on vérifie des specs, ou même qu'on soit en train d'essayer de voir la fin de ce $#@!! de 72eme épisode de 24...
  • Benoit Lafontaine
    Bonjour, Merci Darko pour votre commentaire. Dans cet article je veux souligner : - le "builder" doit etre assez stable pour ne plus s'en occuper : avec Maven, je ne doit pas avoir a modifier mon POM tous les jours - quand je developpe, mon builder (ici Maven) doit etre transparent, je pourrai effectivement lancer maven depuis mon IDE pour verifier mes tests unitaires, mais je ne beneficierai pas de toute la puissance de mon IDE (points d'arrets, lancement d'un test unique, etc.) Votre remarque entraine un autre sujet : le temps d'un build. Je suis justement en train de preparer un autre article sur ce sujet.
  • François-Xavier Bonnet
    Bonjour, Personnellement, j'ai l'impression que l'intégration Maven/Eclipse est partie dans la mauvaise direction : on essaie de faire une correspondance entre les plugins Maven et les plugins Eclipse et m2eclipse ne fait pas grand chose de plus que de générer des fichiers de conf pour Eclipse (.classpath, .projets, .settings... et je suppose qu'on est pas prêts de voir les .pmd, .checkstyle et autres). Ce ne serait pas plus logique que m2eclipse se serve de Maven et soit capable de traduire ce que Maven renvoit dans l'interface graphique d'Eclipse ? Un simple exemple : pour l'instant m2eclipse n'est même pas capable d'afficher correctement dans l'interface Eclipse qu'il manque une des librairies du pom.xml, le jar en question n'apparait tout simplement pas dans les dépendances du projet alors qu'il ne devrait pas être trop compliqué de le faire apparaitre avec une petite croix rouge dessus.
  • Arnaud Héritier
    eclipse:eclipse est effectivement devenu inexploitable en générant des fichiers de configuration que même les équipes eclipse ne maitrise pas au fur et à mesure des versions. Le plugin m2eclipse lui utilise directement les APIs natives d'eclipse et ne touche donc jamais aux fichiers de config. Il laisse eclipse le faire. Pour les librairies manquantes j'ai ce genre de message dans la vue problems : Description : The container 'Maven Dependencies' references non existing library '/Users/arnaud/.m2/repository/org/openqa/selenium/client-drivers/selenium-java-client-driver/0.9.2/selenium-java-client-driver-0.9.2.jar' Resource : org.gatein.wci:wci-wci Location : Build path Type : Build Path Problem Sur ce faut que j'aille corriger ce problème :-)

      • Laisser un commentaire

      Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *


      Ce formulaire est protégé par Google Recaptcha