@Sebsauvage ces derniers temps je suis souvent en désaccord avec toi, mais ça n'empêche pas que quand je partage ton avis, je le fais à 100000% (oui rien que ça) et là, je partage vraiment ton avis !!

Permets-moi d'ajouter à ta liste, les développeurs qui empêchent le zoom sur les sites mobiles quand c'est écrit trop petit
ヽ(`⌒´メ)ノ

Réponse rapide : il n'y a pas de bonnes façon de faire cela.

Cela fait bientôt trois ans que je cherche une façon propre et pérenne d'utiliser Gradle au-delà d'un niveau "amateuriste" et ça n'est juste pas possible de le faire simplement. Pourquoi me direz-vous ? Parce que Gradle ne repose pas sur une configuration déclarative mais sur un DSL, c'est-à-dire du code ni plus ni moins.

En Gradle on écrit du code pour compiler, tester et packager du code. C'est une sorte de gros ANT où le XML à laisser sa place au Groovy avec un moteur certes hyper rapide mais Gradle demeure une immense régression en terme de gestion de projet par rapport à Maven et je compte argumenter.

En une phrase : un processus ce n'est pas un plugin !

Il est possible de coder un plugin pour Maven, mais ce plugin représente une tâche, une action spécifique, un traitement unique qui reposera sur une convention, restera paramétrable et surtout sera parfaitement réutilisable d'un projet à un autre projet.

Un exemple parfait : le maven-assembly-plugin permettant de fabriquer des tar.gz. Je peux donc avec Maven déclarer dans une configuration (donc pas du code) un processus qui fasse :

1. Compilation (avec le kotlin-maven-plugin)
2. Exécution des TU (avec le maven-surefire-plugin)
3. Archivage des classes dans des JAR (avec le maven-jar-plugin)
4. Analyse SAST des failles de sécurités des libs (avec le dependency-check-maven-plugin)
5. Production du bundle qui embarquera jars + exec + conf (avec le maven-assembly-plugin)

L'ordre d'exécution c'est mon workflow, c'est mon processus de build. À aucun moment je n'ai eu à écrire du code pour réaliser tout ça. Mieux encore, ce processus standard peut être mis dans un projet à part en tant que workflow unique et standard de l'entreprise. Cela implique que tous les projets de l'entreprise en hériteront et cela garantira que chaque projet subira les mêmes contrôles. Mieux encore il peut être décomposer en plusieurs projets ou chacun est une couche spécialisée dans une préoccupation : la packaging, les tests, les rapports, les analyses de sécurité... Bref c'est facile et hyper-maintenable.

Il est possible de fabriquer plusieurs de ces configurations, une par types de projets (serveur, lib, batch, etc) et il est même possible d'avoir un héritage entre ces configuration afin qu'elles partagent un maximum de chose et ou chaque nouveau fils raffine le processus de build dans son domaine.

Avec Gradle, il faut que je code un plugin unique qui embarque toutes ces étapes... Comment expliquer à quel point c'est pourri...?... C'est vraiment pourri ! Voilà. Mais pourquoi est-ce donc pourri ?

Simple :
1) Parce que le code appelle le code. Plus j'en écris, plus je devrai en écrire alors qu'une configuration non.
2) Le code c'est incroyablement dur à relire, alors qu'une configuration non.
3) Le code doit être testé alors qu'une configuration non.
4) Le code a toujours le risque d'être écrit pour une plateforme particulière (linux, windows, etc) l'exemple typique étant le séparateur de répertoires '/' ou '\' qui est hardcodé, alors qu'une configuration non.
5) Le plugin Gradle embarquant le workflow implique que tout le processus est rédigé au même endroit, alors qu'une configuration non (elle peut-être éclatée).
6) Si j'ai deux processus distincts, je devrai écrire deux plugins distincts, alors qu'une configuration (je fais référence à celle de Maven) peut être étendue à chaque pom enfant (oui parce que si nos classes doivent être petite, nos pom doivent l'être aussi).
7) Une configuration peut être surchargée, alors que c'est impossible sur un plugin.

En résumé, je pense que Groovy est un langage qui s'appuie sur tout un tas de mauvaise idées (il possède quand même quelques bonnes, mais le typage faible qui est l'anti-pattern absolu sur la longue vie d'un projet est à mon sens le meilleur exemple). Je pens qu'un DSL est une encore plus mauvaise idée car il nécessite un apprentissage du DSL et la plupart du temps des fonctionnalités du vrai langage sous-jacent (et en toute franchise je n'ai pas le temps d'apprendre la techno de merde qui habite votre cœur)_.

Alors un DSL en Groovy ça me "juste tue"... Et Gradle mise sur ça !? C'est l'une des raisons pour lesquelles je préconise mille fois plus Gitlab-CI en lieu et place de Jenkins, car GitLab s'appuie sur une configuration déclarative et non sur du code à copier-coller en DSL-Groovy (et je vous recommande Go Task au passage pour ceux qui souhaitent se rendre indépendant d'un CI).

Je ne fais pas dans la bidouille, je dois gérer plusieurs centaines de builds par jour dans un département de 200 personnes qui fourni des outils rendant service à littéralement 60 millions de clients, je travaille à un niveau professionnel et non dans une "team-startup" qui code une appli Android en moins de 3 semaines et où bidouiller des scripts de build à l'image d'un étudiant en TP est un comportement tout à fait standard et acceptable.

Pour toutes ces raisons, Gradle ne peut pas être un outil que je recommande au niveau industriel. J'ai donc trois souhaits au choix :

• Soit que quelqu'un remplace le DSL de Gradle par une conf évolutive.
• Soit que Maven change son moteur pour rattraper les performances de Gradle au build.
• Soit que quelqu'un m'indique un troisième outil qui ferait mon bonheur en alliant conf et performances.

Pour les prochains dojos que je dois préparer avec Bichon en septembre !

Je suis d'accord

Ce qu'il faut faire et ne pas faire en PHP

Anti-patterns de tests unitaires.

Un lien que j'avais oublié de me bookmarker