LCC 175 - Interview sur la build avec Cedric Champeau et Arnaud Heritier - partie 2
Guillaume, C\xe9dric 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\xe8me partie, on y discute tests puis on aborde des questions sp\xe9cifiques \xe0 chaque outil. On aborde enfin le dilemme: migrer ou ne pas migrer, telle est la question. Le tout bas\xe9 sur les questions pos\xe9es sur la mailing list des cast codeurs : merci \xe0 vous !
Enregistr\xe9 le 19 juillet 2017
T\xe9l\xe9chargement de l\u2019\xe9pisode LesCastCodeurs-Episode\u2013175.mp3
Interview\xa0
Ta vie ton \u0153uvreC\xe9dric Champeau
Gradle Inc.
Arnaud H\xe9ritier
Cloudbees
Gradle / Maven: Quelle est la philosophie officielle des deux outils pour la gestion des tests au del\xe0 des tests unitaires (une fois les diff\xe9rents modules assembl\xe9s et d\xe9ploy\xe9s) ?
Dans des projets maven par exemple, je vois des fois des modules d\xe9di\xe9s, en scope test ou scope runtime et lanc\xe9s \xe0 la main, d\u2019autres fois des projets ind\xe9pendants. Chaque \xe9quipe a plus ou moins sa propre fa\xe7on de g\xe9rer la chose mais rien n\u2019a l\u2019air vraiment normalis\xe9 (ou du moins partag\xe9 par la communaut\xe9).
Gradle / Maven: Quels sont les \u2018best practices\u2019 pour faire du \u2018test and watch\u2019 (genre infinitest) avec maven et gradle ?
Les int\xe9grationsGradle: Pourquoi je ne peux pas faire de Run Tests sur un projet en Gradle dans IntelliJ alors qu\u2019avec Maven je peux ?
Gradle / Maven: Pour les deux, qu\u2019en est il de l\u2019int\xe9gration dans les diff\xe9rents IDE ? J\u2019ai \xe9t\xe9 agr\xe9ablement surpris par l\u2019int\xe9gration de Gradle dans Netbeans, mais je n\u2019ai pas beaucoup jou\xe9 avec.
Gradle / Maven: \u201cQuid de l\u2019int\xe9gration dans mon IDE pr\xe9f\xe9r\xe9 ?\u201d
Gradle / Maven: \u201cQuid de l\u2019int\xe9gration dans mon continuous build pr\xe9f\xe9re ?\u201d
Gradle: Y\u2019a moyen de voir en Gradle \xe0 quel test je suis rendu ?
Gradlew/mvnw- Gradle: Pourquoi mvnw et gradlew ne downloadent par leurs jars au lieu de nous forcer \xe0 les mettre dans .mvn et gradle ?
- Gradle: Pour Gradle, vous ne trouvez pas affreux ces fichiers \u201cgradlew\u201d et \u201cgradlew.bat\u201d \xe0 la racine de chaque projet dans github ?
- Gradle: Est-il prevu de pouvoir avoir un fichier build.gradle a chaque niveau de la hierarchie de tes modules au lieu d\u2019avoir besoin de decrire manuellement tous les paths dans un fichier settings.gradle ? C\u2019est un point que j\u2019ai trouv\xe9 penible (par ex https://github.com/xwiki/xwiki-commons/blob/master/settings.gradle et l\xe0 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\u2019homog\xe9n\xe9iser encore plus les builds Gradle ? Qd j\u2019ai essay\xe9 de convertir le build Maven de XWiki en Gradle, j\u2019ai lu la doc puis j\u2019ai regarde 4\u20135 builds differents en gradle pour voir les bonnes practices. Et la j\u2019ai ete embete car chacun avait des pratiques un peu differentes. Au debut j\u2019etais meme paum\xe9 et puis apres qq heures de recherches j\u2019ai commenc\xe9 \xe0 identifier des patterns communs mais qd meme avec pas mal de variations. Du coup je n\u2019ai pas su trouver facilement les best practices et j\u2019ai du me les faire et en consequence le build Gradle XWiki est lui aussi encore un peu different des autres probablement. Qu\u2019est-il prevu sur le sujet ? En gros comme simplifier encore plus l\u2019onboarding Gradle ?
Gradle: Le BOM de maven est-il une invention du malin ? Et quel est son \xe9quivalent pour Gradle ?
AndroidGradle: Pourquoi l\u2019int\xe9gration de ces outils dans Android Studio est-elle aussi path\xe9tiquement mauvaise ? (je suis oblig\xe9 d\u2019utiliser ce sous-outil, et j\u2019ai mal \xe0 mon gradle : je ne peux pas voir mes d\xe9pendances facilement, et l\u2019int\xe9gration se r\xe9sume \xe0 une lecture de la liste des t\xe2ches et \xe0 leur lancement).
Maven en profondeurMaven: Quand est-ce que le bogue Maven du shade plugin qui ne remplace pas le jar d\u2019origine pas le jar shad\xe9 sera corrig\xe9? (et que donc l\u2019\xe9quipe Maven reviendra \xe0 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 \xe0 3 phases qui sont \u201cresource, compile, install\u201d et qu\u2019un autre avec X phases comme compile, \u201cprepare, \u2026, install, deploy-maven-repository, deploy-env\u201d)
Maven: Pour Maven encore, il y avait il me semble un projet polyglot pour les descripteurs, qu\u2019en est-il ? Pourrait on imaginer des descripteurs en yaml et/ou json ?
Maven: y\u2019a t\u2019il beaucoup de boites qui dev leurs petits plugins Maven perso pour adapter \xe0 leurs probl\xe9matiques ?
Maven: comment g\xe9rer les builds o\xf9 l\u2019appli finale est la r\xe9sultante de nombreux multi-module Maven project, chacun dans un repo git perso avec leur version. Nous avons des probl\xe8mes pour g\xe9rer les \xe9volutions de versions de chacun de ces multi-modules et faire en sorte que les modules qui en d\xe9pendent se MAJ vers la nouvelle version. Les BOM Maven sont une piste mais c\u2019est pas clair\u2026
Maven: est-ce une bonne pratique de consid\xe9rer comme absolue la r\xe8gle selon laquelle tous les modules d\u2019un multi-module Maven project doivent avoir le m\xeame num\xe9ro de version ?
Maven: est-ce bien une mauvaise pratique que de mettre dans le m\xeame repo Git 2 multi-module Maven projects qui ne partagent pas le m\xeame parent ?
Maven: les devs familiers avec Maven n\u2019ont ils pas trop tendance \xe0 d\xe9couper leurs appli en modules Maven alors qu\u2019ils pourraient se contenter des package Java ? Je me rend compte que c\u2019est mon cas perso\u2026
Maven: Pour des grosses applis, faites-vous plusieurs petits builds et un meta-build d\u2019assemblage final agr\xe9geant 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: \u201cclasspath too long\u201d: c\u2019est la r\xe9sultante du point pr\xe9c\xe9dant. Nous commen\xe7ons \xe0 nous heurter \xe0 des probl\xe8mes de \u201cclasspath too long\u201d 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\xe8me en ayant utilis\xe9 la commande mklink pour simlinker le repo Maven sur c:\\repo et gagner quelques caract\xe8res sur chaque d\xe9pendance\u2026 oui, c\u2019est tres moche)
Maven: quid du param\xe9trage du build ? Par exemple actuellement nous avons une phase de packaging assez g\xe9n\xe9rique qui prend en entr\xe9e un num\xe9ro de version de l\u2019application \xe0 packager. Merci Jenkins.
Migrer vers Gradle, mais pourquoi (pas) ? Et la valeur du build dans tout \xe7a \u2026
Gradle: Pourquoi est-ce que depuis 3 ans, je vais voir une prez de C\xe9dric sur Gradle, et j\u2019en ressors en me disant \u201cGradle, \xe7a a l\u2019air quand m\xeame vachement bien\u201d, et que l\u2019ann\xe9e qui suit, je retourne voir une prez de C\xe9dric l\u2019ann\xe9e suivante sans avoir rien chang\xe9 sur mes projets Java ?
Gradle: Suis-je tellement fain\xe9ant dans mon petit confort de build Maven pour reposer sur mes acquis et ne pas switcher ? Je veux dire \u2026 \xe0 chaque fois j\u2019ai de bons arguments apport\xe9s par C\xe9dric pour migrer, et pourtant, le switch ne se fait finalement pas.
Gradle / Maven: Consid\xe8re-t-on aujourd\u2019hui 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\u2019ai l\u2019impression qu\u2019il n\u2019est pas si isol\xe9 que \xe7a) Ou au contraire, est-ce tellement critique et relativement assez peu agile qu\u2019on a trop peur d\u2019en changer? Si on reprend le cas de Ant vs Maven, pas mal de gens ont traine a migrer, c\u2019etait trop risque, les bonnes pratiques etaient encore peu connues, tout le monde avait peur de crasher son projet a cause de ca\u2026 Personne ne veut essuyer les platres d\u2019une \u201cnouvelle\u201d 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\u2019apps ca devrait changer vite si c\u2019est le cas; tant qu\u2019Android l\u2019infidele 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\u2019effort et le risque? J\u2019ai pas l\u2019impression de lire beaucoup de retour d\u2019experience de projets qui disent avoir gagne drastiquement en productivite en en qualite grace a une migration Maven->Gradle.
Gradle / Maven: \u201cje d\xe9marre un projet, Gradle ou Maven ?\u201d
Gradle / Maven: les devs et le build: g\xe9n\xe9ralement, la grande majorit\xe9 des devs ne s\u2019y int\xe9ressent pas. A titre perso, je trouve \xe7a fondamental, si le build est mal fait, \xe7a handicap tout le projet sans que les gens ne s\u2019en aper\xe7oivent malgr\xe9 les effets n\xe9gatifs, ils ne voient pas comment faire autrement => est-ce un ressenti que vous avez ?
Nous contacterFaire 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? sponsors@lescastcodeurs.com