LCC 175 - Interview sur la build avec Cédric Champeau et Arnaud Héritier - partie 2

Les Cast Codeurs Podcast

Guillaume, Cédric et Arnaud se retrouvent autour du micro pour parler pendant une session marathon de 3h30 du build, de Maven et de Gradle. Dans cette deuxième partie, on y discute tests puis on aborde des questions spécifiques à chaque outil. On aborde enfin le dilemme: migrer ou ne pas migrer, telle est la question. Le tout basé sur les questions posées sur la mailing list des cast codeurs : merci à vous !

Enregistré le 19 juillet 2017

Téléchargement de l’épisode LesCastCodeurs-Episode–175.mp3

Interview

Ta vie ton œuvre

Cédric Champeau Gradle Inc. Arnaud Héritier Cloudbees

Gradle Maven

Les tests

Gradle / Maven: Quelle est la philosophie officielle des deux outils pour la gestion des tests au delà des tests unitaires (une fois les différents modules assemblés et déployés) ? Dans des projets maven par exemple, je vois des fois des modules dédiés, en scope test ou scope runtime et lancés à la main, d’autres fois des projets indépendants. Chaque équipe a plus ou moins sa propre façon de gérer la chose mais rien n’a l’air vraiment normalisé (ou du moins partagé par la communauté).

Gradle / Maven: Quels sont les ‘best practices’ pour faire du ‘test and watch’ (genre infinitest) avec maven et gradle ?

Les intégrations

Gradle: Pourquoi je ne peux pas faire de Run Tests sur un projet en Gradle dans IntelliJ alors qu’avec Maven je peux ? Gradle / Maven: Pour les deux, qu’en est il de l’intégration dans les différents IDE ? J’ai été agréablement surpris par l’intégration de Gradle dans Netbeans, mais je n’ai pas beaucoup joué avec. Gradle / Maven: “Quid de l’intégration dans mon IDE préféré ?” Gradle / Maven: “Quid de l’intégration dans mon continuous build préfére ?”

Gradle en profondeur

Gradle: Y’a moyen de voir en Gradle à quel test je suis rendu ?

Gradlew/mvnw

• Gradle: Pourquoi mvnw et gradlew ne downloadent par leurs jars au lieu de nous forcer à les mettre dans .mvn et gradle ?
• Gradle: Pour Gradle, vous ne trouvez pas affreux ces fichiers “gradlew” et “gradlew.bat” à la racine de chaque projet dans github ?

Scripting vs XML

• Gradle: Est-il prevu de pouvoir avoir un fichier build.gradle a chaque niveau de la hierarchie de tes modules au lieu d’avoir besoin de decrire manuellement tous les paths dans un fichier settings.gradle ? C’est un point que j’ai trouvé penible (par ex https://github.com/xwiki/xwiki-commons/blob/master/settings.gradle et là je ne liste que qq modules - en pratique il y en a des centaines ds le build xwiki).
• Gradle: Est-ce que Gradle travaille a essayer d’homogénéiser encore plus les builds Gradle ? Qd j’ai essayé de convertir le build Maven de XWiki en Gradle, j’ai lu la doc puis j’ai regarde 4–5 builds differents en gradle pour voir les bonnes practices. Et la j’ai ete embete car chacun avait des pratiques un peu differentes. Au debut j’etais meme paumé et puis apres qq heures de recherches j’ai commencé à identifier des patterns communs mais qd meme avec pas mal de variations. Du coup je n’ai pas su trouver facilement les best practices et j’ai du me les faire et en consequence le build Gradle XWiki est lui aussi encore un peu different des autres probablement. Qu’est-il prevu sur le sujet ? En gros comme simplifier encore plus l’onboarding Gradle ?

BOM

Gradle: Le BOM de maven est-il une invention du malin ? Et quel est son équivalent pour Gradle ?

Android

Gradle: Pourquoi l’intégration de ces outils dans Android Studio est-elle aussi pathétiquement mauvaise ? (je suis obligé d’utiliser ce sous-outil, et j’ai mal à mon gradle : je ne peux pas voir mes dépendances facilement, et l’intégration se résume à une lecture de la liste des tâches et à leur lancement).

Maven en profondeur

Maven: Quand est-ce que le bogue Maven du shade plugin qui ne remplace pas le jar d’origine pas le jar shadé sera corrigé? (et que donc l’équipe Maven reviendra à la raison) ? Maven: Pour revenir au cycle de vie de Maven, serait-il possible de configurer des cycles de vies (notion de descripteurs de cycles de vie). En gros, pouvoir dire que mon projet suit un cycle de vie à 3 phases qui sont “resource, compile, install” et qu’un autre avec X phases comme compile, “prepare, …, install, deploy-maven-repository, deploy-env”) Maven: Pour Maven encore, il y avait il me semble un projet polyglot pour les descripteurs, qu’en est-il ? Pourrait on imaginer des descripteurs en yaml et/ou json ? Maven: y’a t’il beaucoup de boites qui dev leurs petits plugins Maven perso pour adapter à leurs problématiques ?

Granularité / découpage de modules avec Maven

Maven: comment gérer les builds où l’appli finale est la résultante de nombreux multi-module Maven project, chacun dans un repo git perso avec leur version. Nous avons des problèmes pour gérer les évolutions de versions de chacun de ces multi-modules et faire en sorte que les modules qui en dépendent se MAJ vers la nouvelle version. Les BOM Maven sont une piste mais c’est pas clair… Maven: est-ce une bonne pratique de considérer comme absolue la règle selon laquelle tous les modules d’un multi-module Maven project doivent avoir le même numéro de version ? Maven: est-ce bien une mauvaise pratique que de mettre dans le même repo Git 2 multi-module Maven projects qui ne partagent pas le même parent ? Maven: les devs familiers avec Maven n’ont ils pas trop tendance à découper leurs appli en modules Maven alors qu’ils pourraient se contenter des package Java ? Je me rend compte que c’est mon cas perso… Maven: Pour des grosses applis, faites-vous plusieurs petits builds et un meta-build d’assemblage final agrégeant les petits morceaux ? Ou alors faites-vous un bon gros build qui dure longtemps mais recompile/repackage tout ? Ou alors vous laissez-vous le choix en faisant en sorte de pouvoir faire les 2 (sur Jenkins)

Maven: “classpath too long”: c’est la résultante du point précédant. Nous commençons à nous heurter à des problèmes de “classpath too long” sous Windows pour des Proof of Concepts mixant de nombreux projets. Le point de non-retour est-il proche ? (Pour info, nous contournons temporairement le problème en ayant utilisé la commande mklink pour simlinker le repo Maven sur c:\repo et gagner quelques caractères sur chaque dépendance… oui, c’est tres moche) Maven: quid du paramétrage du build ? Par exemple actuellement nous avons une phase de packaging assez générique qui prend en entrée un numéro de version de l’application à packager. Merci Jenkins.

Migration

Migrer vers Gradle, mais pourquoi (pas) ? Et la valeur du build dans tout ça … Gradle: Pourquoi est-ce que depuis 3 ans, je vais voir une prez de Cédric sur Gradle, et j’en ressors en me disant “Gradle, ça a l’air quand même vachement bien”, et que l’année qui suit, je retourne voir une prez de Cédric l’année suivante sans avoir rien changé sur mes projets Java ? Gradle: Suis-je tellement fainéant dans mon petit confort de build Maven pour reposer sur mes acquis et ne pas switcher ? Je veux dire … à chaque fois j’ai de bons arguments apportés par Cédric pour migrer, et pourtant, le switch ne se fait finalement pas. Gradle / Maven: Considère-t-on aujourd’hui le build comme accessoire sur un projet Java pour ne pas vouloir engager un investissement de migration ? (je parle beaucoup de mon cas perso ici, mais j’ai l’impression qu’il n’est pas si isolé que ça) Ou au contraire, est-ce tellement critique et relativement assez peu agile qu’on a trop peur d’en changer? Si on reprend le cas de Ant vs Maven, pas mal de gens ont traine a migrer, c’etait trop risque, les bonnes pratiques etaient encore peu connues, tout le monde avait peur de crasher son projet a cause de ca… Personne ne veut essuyer les platres d’une “nouvelle” techno de build avec son projet. Gradle: Peut-etre Gradle en est-il encore la et a du mal a passer le cap des Early-Adopters (ceci dit, avec Android et son armee de developpeurs d’apps ca devrait changer vite si c’est le cas; tant qu’Android l’infidele decide de rester sur Gradle :P Gradle: Et enfin, LE point-cle: est-ce que la migration de Maven a Gradle amene une valeur ajoutee suffisante pour justifier l’effort et le risque? J’ai pas l’impression de lire beaucoup de retour d’experience de projets qui disent avoir gagne drastiquement en productivite en en qualite grace a une migration Maven->Gradle. Gradle / Maven: “je démarre un projet, Gradle ou Maven ?”

Conclusion

Gradle / Maven: les devs et le build: généralement, la grande majorité des devs ne s’y intéressent pas. A titre perso, je trouve ça fondamental, si le build est mal fait, ça handicap tout le projet sans que les gens ne s’en aperçoivent malgré les effets négatifs, ils ne voient pas comment faire autrement => est-ce un ressenti que vous avez ?

Nous contacter

Faire un crowdcast ou une crowdquestion Contactez-nous via twitter https://twitter.com/lescastcodeurs sur le groupe Google https://groups.google.com/group/lescastcodeurs ou sur le site web https://lescastcodeurs.com/ Flattr-ez nous (dons) sur https://lescastcodeurs.com/ En savoir plus sur le sponsoring? [e-mail]