Je tweete du contenu technique que je considère intéressant, mais les tweets amusants sont ceux qui obtiennent le plus d'engagement. J'ai assisté à la conférence JavaLand en mars, je suis tombé sur le stand Gradle et j'ai trouvé ce joyau : Bien sûr, à un moment donné, un fanboy a détourné le fil et revendiqué la Dans cet article, j'aimerais faire la lumière sur ma position, afin que je puisse y diriger les gens au lieu de démystifier le même "raisonnement" à plusieurs reprises. soi-disant supériorité de Gradle. Pour gérer ça, j'ai besoin de remonter dans le temps. Le développement de logiciels est un domaine en évolution rapide, et une grande partie de notre compréhension est basée sur l'expérience personnelle. Alors voici le mien. Mon premier outil de construction : Fourmi J'ai commencé en 2002. A l'époque, il n'y avait pas d'outils de build : nous compilions et construisions via l'IDE. Pour mémoire, j'ai d'abord utilisé Visual Age pour Java ; puis, je suis passé à Borland JBuilder. à développer en Java Construire avec un IDE pose un énorme problème : chaque développeur a des paramètres dédiés, de sorte que la génération d'artefacts dépend de la combinaison développeur-machine. Les builds non répétables sont un problème séculaire. Ma première expérience avec des builds reproductibles est Apache Ant : Apache Ant est une bibliothèque Java et un outil de ligne de commande dont la mission est de piloter les processus décrits dans les fichiers de construction en tant que cibles et points d'extension dépendant les uns des autres. La principale utilisation connue d'Ant est la construction d'applications Java. Ant fournit un certain nombre de tâches intégrées permettant de compiler, assembler, tester et exécuter des applications Java. Ant peut également être utilisé efficacement pour créer des applications non Java, par exemple des applications C ou C++. Plus généralement, Ant permet de piloter tout type de processus pouvant être décrit en termes de cibles et de tâches. -- https://ant.apache.org/ Ant est basé sur trois abstractions principales : Une est une unité de travail atomique, pour compiler des fichiers Java, pour assembler une archive Web, etc. Ant fournit de nombreuses tâches prêtes à l'emploi mais permet d'en ajouter des personnalisées. tâche par exemple javac war Une est une liste de tâches. cible Vous pouvez définir des dépendances entre les tâches, telles que en fonction de . À cet égard, vous pouvez voir Ant comme un moteur d'exécution de flux de travail. package compile Je suis rapidement devenu « maîtrisant » Ant. En tant que consultant, j'allais d'entreprise en entreprise, de projet en projet. Au départ, j'ai principalement configuré Ant, mais Ant s'est répandu au fil du temps et j'ai rencontré des configurations Ant existantes. J'étais cohérent dans mes projets, mais les autres projets étaient très différents les uns des autres. Chaque fois, en arrivant sur un nouveau projet, vous deviez lire attentivement la configuration Ant pour comprendre la construction personnalisée. De plus, la structure de chaque projet était différente. Certains placent leurs sources dans , d'autres dans , d'autres dans une structure imbriquée, etc. src sources Je me souviens d'un fichier de construction générique qui tentait de répondre à l'ensemble des besoins du projet d'une organisation. Il a défini plus de 80 cibles dans plus de 2 000 lignes de XML. Il m'a fallu un temps non négligeable pour comprendre comment l'utiliser avec de l'aide et encore plus de temps pour pouvoir le peaufiner sans casser les projets. Mon deuxième outil de build : Maven Le projet ci-dessus m'a beaucoup fait réfléchir. Je voulais améliorer la situation car les mainteneurs avaient déjà repoussé les limites d'Ant. A l'époque, je travaillais avec mon ami (du célèbre Sonar). Nous avons parlé, et il m'a indiqué Maven. J'avais déjà mais je n'avais aucune autre expérience préalable. J'ai étudié la documentation pendant des heures et, à travers des tentatives d'essais et d'erreurs, sous la tutelle de Freddy, j'ai migré l'intégralité du fichier de construction Ant vers un simple POM parent. Freddy Mallet construit un projet avec Maven Dans Ant, vous devez tout définir dans chaque projet. Par exemple, Ant nécessite la configuration de l'emplacement des fichiers Java pour la compilation ; Maven suppose qu'ils sont sous , bien qu'il soit possible de le remplacer. Maven a révolutionné le domaine de la construction Java avec son approche . De nos jours, de nombreux logiciels proposent une configuration sensée par défaut. src/main/java Convention over Configuration Pour les développeurs qui vont de projet en projet, comme je l'ai fait, cela signifie qu'il y a beaucoup moins de charge cognitive lorsqu'ils rejoignent un nouveau projet. Je m'attends à ce que les sources Java soient situées sous . Les conventions Maven continuent au-delà de la structure du projet. Ils définissent également le cycle de vie du projet, de la compilation au téléchargement de l'artefact dans un registre distant, en passant par les tests unitaires et d'intégration. src/main/java Enfin, les développeurs juniors ont tendance à l'ignorer, mais Maven a défini le terme . Il a introduit l'idée de registres d'artefacts, où l'on peut télécharger des dépendances immuables et pousser des artefacts vers. Avant cela, chaque projet devait stocker les dépendances dans son référentiel dédié. gestion des dépendances Pour mémoire, il y avait quelques dépendances stockées sur le projet mentionné ci-dessus. Lorsque j'ai migré d'Ant vers Maven, j'ai dû trouver la version exacte de la dépendance. Pour la plupart, c'était simple, comme c'était dans le nom du fichier ou le manifeste du JAR. Un, cependant, avait été mis à jour avec des classes supplémentaires. Voilà pour l'immuabilité. Maven a eu une profonde influence sur tous les outils de construction ultérieurs : ils se sont définis en référence à Maven. Aucun outil de construction à moi: Gradle La principale revendication de Gradle était de corriger les lacunes de Maven, ou du moins ce qu'il percevait comme tel. Bien que Maven ne soit pas exempt de reproches, Gradle a supposé que le problème le plus important était son manque de flexibilité. C'est une hypothèse surprenante car c'est précisément ce que Maven a amélioré par rapport à Ant. Les projets Maven ont des structures similaires et utilisent le même cycle de vie : le en vigueur. Inversement, Gradle permet de personnaliser presque tous les aspects de la construction, y compris le cycle de vie. principe de moindre surprise Avant d'aborder l'argument de la flexibilité, permettez-moi de reconnaître deux grandes fonctionnalités originales de Gradle que Maven a implémentées par la suite : le démon Gradle et le wrapper Gradle. Maven et Gradle sont deux applications Java qui s'exécutent sur la JVM. Démarrer une JVM coûte cher en temps et en ressources. L'avantage est que la JVM de longue durée optimisera le code JIT-ed au fil du temps. Pour les tâches de courte durée, le bénéfice est nul voire néfaste si l'on tient compte du temps de démarrage de la JVM. Gradle a créé le démon Gradle. Lorsque vous exécutez Gradle, il recherche un démon en cours d'exécution. Sinon, il en démarrera un nouveau. L'application de ligne de commande déléguera tout au démon. Comme son nom l'indique, le démon ne s'arrête pas lorsque la ligne de commande est terminée. Le démon exploite les avantages de la JVM. Il y a de fortes chances que votre application survive à vos outils de construction actuels. Que se passe-t-il lorsque vous devez corriger un bogue dans cinq ans, pour constater que l'outil de construction du projet n'est pas disponible en ligne ? L'idée derrière le wrapper de Gradle est de conserver la version exacte de Gradle avec le projet et juste assez de code pour télécharger la version complète sur Internet. Comme effet secondaire, les développeurs n'ont pas besoin d'installer Gradle localement ; utilisent tous la même version, évitant toute divergence. Démystifier la flexibilité de Gradle Gradle a apporté les deux fonctionnalités ci-dessus que Maven a intégrées, prouvant que la concurrence est bonne. Malgré cela, je ne trouve toujours aucun avantage à Gradle. Je vais essayer de repousser le côté émotionnel. À ses débuts, Gradle marketing a essayé de rabaisser Maven à chaque occasion possible, a publié des tableaux de comparaison fous et a généralement été agressif dans sa communication. Disons que cette phase a duré bien plus qu'il ne serait acceptable pour une jeune entreprise essayant de trouver sa place sur le marché. On pourrait dire que Gradle était très œdipien dans son approche : essayer de tuer son "père" Maven. Enfin, après toutes ces années, il semble qu'il ait compris et maintenant "aime Maven". très N'oubliez pas qu'avant que Maven ne prenne le relais, chaque projet Ant était ad hoc. Maven a mis un terme à cela. Il a apporté la loi au Far West mondial des projets personnalisés. Vous pouvez être en désaccord avec la loi, mais c'est la loi de toute façon, et tout le monde doit s'y tenir. Les normes Maven sont tellement ancrées que même s'il est possible de remplacer certains paramètres, , l'emplacement de la source, personne ne le fait jamais. par exemple J'ai ressenti deux symptômes de la flexibilité de Gradle. Je soupçonne qu'il en existe beaucoup plus. Phases de cycle de vie personnalisées Maven gère les tests d'intégration en quatre phases, exécutées dans l'ordre : : configurez tout ce dont les tests ont besoin pre-integration-test : exécute les tests integration-test : nettoyer les ressources, le cas échéant post-integration-test : agir sur les résultats des tests verify Je n'ai jamais utilisé les phases pré et post, car chaque test avait une logique de configuration et de démontage dédiée. De l'autre côté, . Pourtant, les fanboys de Gradle se feront un plaisir de vous expliquer que vous pouvez ajouter les phases que vous souhaitez. En effet, Gradle permet la "personnalisation" du cycle de vie : vous pouvez ajouter autant de phases supplémentaires dans le cycle de vie normal que vous le souhaitez. Gradle n'a aucune notion de tests d'intégration C'est la pagaille, car chaque projet devra trouver à la fois le nombre de phases requises et leur nom : , , , (pour les paresseux), etc. Les options sont infinies. integration-test integration-tests integration-testing it Le syndrome du flocon de neige Maven traite chaque projet comme un projet standard régulier. Et si vous avez des besoins spécifiques, il est possible d'écrire un plugin pour cela. Écrire un plugin Maven n'est certainement pas amusant ; par conséquent, vous n'en écrivez un que lorsque c'est nécessaire, pas seulement parce que vous avez décidé que la loi ne s'applique pas à vous. Gradle affirme que le manque de flexibilité est un problème ; par conséquent, il veut le réparer. Je maintiens le contraire : le manque de flexibilité de mon outil de build est une fonctionnalité, pas un bug. Gradle facilite le piratage de la construction. Par conséquent, quiconque pense que son projet est un flocon de neige spécial et mérite une personnalisation le fera avec plaisir. Confrontation à la réalité : c'est rarement le cas ; quand c'est le cas, c'est pour les frameworks, pas pour les projets réguliers. Les partisans de Gradle disent qu'il offre toujours des normes tout en permettant une configuration facile. Le cœur du problème est qu'il ne s'agit pas d'une norme si elle peut être modifiée au gré de quiconque. Gradle est l'outil de construction pour . Dans l'une des entreprises pour lesquelles j'ai travaillé, quelqu'un a écrit du code Groovy personnalisé dans la version Gradle pour exécuter Sonar et envoyer les métriques à l'instance interne de Sonar. Il n'y avait pas de plugin Sonar prêt à l'emploi à l'époque, ou je suppose qu'il ne l'a pas coupé. Jusqu'ici, tout va bien. de facto les projets Android Lorsqu'une autre équipe a créé le deuxième projet Android de l'entreprise, elle a copié-collé la structure du premier projet et le fichier de construction. La chose intelligente à faire aurait été, à ce moment-là, de créer un plugin Gradle interne à partir du code spécifique à Sonar. Mais ils ne l'ont pas fait parce que Gradle a facilité le piratage de la construction. Et moi, le Gradle-hater, j'ai pris sur moi de créer le plugin. Cela aurait pu être une meilleure expérience de développeur, c'est le moins qu'on puisse dire. Faute de documentation de qualité et utilisant un langage non typé (Groovy), j'ai utilisé la console pour imprimer la structure des objets pour progresser. Conclusion La concurrence est bonne, et Gradle a apporté de nouvelles idées que Maven a intégrées, le wrapper et le démon. Cependant, Gradle est construit sur le principe que la flexibilité est bonne, alors que mon expérience m'a montré le contraire. Ant était très flexible et la charge cognitive pour passer d'un projet à l'autre était élevée. Nous, développeurs, sommes des êtres humains : nous aimons penser que nos projets sont différents des autres. La plupart du temps, ils ne le sont pas. La personnalisation n'est qu'un moyen de satisfaire notre ego. Des outils de construction flexibles nous permettent de mettre en œuvre une telle personnalisation, qu'elle soit justifiée ou non. Les personnalisations non pertinentes n'apportent aucun avantage et sont faciles à développer mais coûteuses à entretenir. Si la gestion des actifs logiciels fait partie de mes responsabilités, je choisirai toujours la stabilité plutôt que la flexibilité pour mon outil de construction. Publié à l'origine sur le 6 août 2023 A Java Geek

This story contains new, firsthand information uncovered by the writer.

Cet audio est produit dans la langue originale de l'histoire !

Trop long; Pour lire

 Add passwordless user experiences to your app

HackerNoon Mobile

Gradle est-il vraiment meilleur que Maven ? - Mon verdict final

Trop long; Pour lire

@nfrankel

Credibility

HISTOIRES CONNEXES