java vs - Pourquoi utiliser Gradle au lieu de Ant ou Maven?





tutoriel 2018 (9)


Gradle peut être utilisé à de nombreuses fins - c'est un bien meilleur couteau suisse que Ant - mais il est spécifiquement axé sur les constructions multi-projets.

Tout d'abord, Gradle est un outil de programmation de dépendance qui signifie également que c'est un outil de programmation. Avec Gradle, vous pouvez exécuter n'importe quelle tâche aléatoire dans votre configuration et Gradle s'assurera que toutes les dépendances déclarées sont exécutées correctement et en temps opportun. Votre code peut être réparti sur de nombreux répertoires dans n'importe quel type de mise en page (arborescente, plate, dispersée, ...).

Gradle a deux phases distinctes: l'évaluation et l'exécution. Fondamentalement, pendant l'évaluation, Gradle cherchera et évaluera les scripts de construction dans les répertoires qu'il est supposé regarder. Pendant l'exécution, Gradle exécutera les tâches qui ont été chargées lors de l'évaluation en tenant compte des interdépendances des tâches.

En plus de ces fonctionnalités de programmation de dépendances, Gradle ajoute des fonctionnalités de dépendance de projet et JAR par intégration avec Apache Ivy. Comme vous le savez, Ivy est un outil de gestion des dépendances beaucoup plus puissant et beaucoup moins opiniâtre que Maven.

Gradle détecte les dépendances entre les projets et entre les projets et les fichiers JAR. Gradle fonctionne avec les dépôts Maven (télécharger et télécharger) comme l'iBiblio ou vos propres dépôts, mais aussi les supports et autres types d'infrastructure de dépôt que vous pourriez avoir.

Dans les constructions multi-projets, Gradle est à la fois adaptable et s'adapte à la structure et à l'architecture de la construction. Vous n'avez pas besoin d'adapter votre structure ou votre architecture à votre outil de construction, comme cela serait nécessaire avec Maven.

Gradle essaie très fort de ne pas vous gêner, un effort que Maven ne fait presque jamais. La convention est bonne, tout comme la flexibilité. Gradle vous donne beaucoup plus de fonctionnalités que Maven, mais le plus important dans de nombreux cas, Gradle vous offrira une transition sans douleur loin de Maven.

Qu'est-ce qu'un autre outil de construction destiné à Java m'apporte vraiment?

Si vous utilisez Gradle sur un autre outil, pourquoi?




Je n'utilise pas Gradle dans la colère moi-même (juste un projet de jouet jusqu'ici) [auteur signifie qu'ils ont utilisé Gradle sur seulement un projet de jouet jusqu'à présent, pas que Gradle est un projet de jouet - voir commentaires] , mais je dirais que Les raisons pour lesquelles on pourrait envisager de l'utiliser seraient à cause des frustrations de Ant et Maven.

Dans mon expérience Ant est souvent en écriture seule (oui je sais qu'il est possible d'écrire magnifiquement modulaire, élégant , mais le fait est que la plupart des gens ne le font pas). Pour tous les projets non triviaux, cela devient stupéfiant, et prend grand soin de s'assurer que les builds complexes sont vraiment portables. Sa nature impérative peut conduire à la réplication de la configuration entre les builds (bien que les macros puissent aider ici).

Maven adopte l'approche inverse et s'attend à ce que vous intégriez complètement le cycle de vie de Maven. Les utilisateurs d'Ant expérimentés trouvent cela particulièrement discordant car Maven supprime de nombreuses libertés que vous avez dans Ant. Par exemple, il y a un blog Sonatype qui énumère de nombreuses critiques Maven et leurs réponses.

Le mécanisme de plugin Maven permet des configurations de construction très puissantes, et le modèle d'héritage permet de définir un petit ensemble de POM parentaux encapsulant vos configurations de construction pour l'ensemble de l'entreprise et les projets individuels peuvent hériter de ces configurations, les laissant légères. La configuration de Maven est très verbeuse (bien que Maven 3 promette d'y remédier), et si vous voulez faire quelque chose qui ne soit pas "Maven", vous devez écrire un plugin ou utiliser l'intégration hacky Ant. Remarque Il m'arrive d'écrire des plugins Maven, mais j'apprécie que beaucoup d'entre eux s'opposeront à l'effort.

Gradle promet de toucher le bon endroit entre Ant et Maven. Il utilise l'approche d' Ivy pour la résolution des dépendances. Il permet la convention sur la configuration mais inclut également les tâches Ant en tant que citoyens de première classe. Il vous permet également d'utiliser judicieusement les dépôts Maven / Ivy existants.

Donc, si vous avez frappé et êtes coincé avec l'un des points de douleur Ant / Maven, il vaut probablement la peine d'essayer Gradle, mais à mon avis il reste à voir si vous ne serait pas juste échanger des problèmes connus pour ceux inconnus. La preuve du pudding est dans le fait de manger alors je réserverais mon jugement jusqu'à ce que le produit soit un peu plus mature et que d'autres aient aplani tout vrillage (ils appellent ça saigner pour une raison). Je vais quand même l'utiliser dans mes projets de jouets, c'est toujours bon d'être au courant des options.




Gradle a retrouvé le plaisir de construire / assembler des logiciels. J'ai utilisé des fourmis pour construire des logiciels pendant toute ma carrière et j'ai toujours considéré que la partie «build» réelle du travail de développement était un mal nécessaire. Il y a quelques mois, notre société en a eu marre de ne pas utiliser un repo binaire (c'est-à-dire d'avoir jeté des bogues dans les vcs) et on m'a confié la tâche d'enquêter. Commencé avec lierre car il pourrait être boulonné sur le dessus de la fourmi, n'a pas eu beaucoup de chance pour obtenir mes artefacts construits publiés comme je le voulais. Je suis allé pour maven et piraté avec xml, travaillé splendide pour certaines bibliothèques d'aide simples, mais j'ai rencontré de graves problèmes en essayant de regrouper les applications prêtes pour le déploiement. J'ai pris du temps à chercher des plugins et à lire des forums et j'ai fini par télécharger des milliers de milliards de fichiers de support pour divers plugins que j'avais du mal à utiliser. Enfin, je suis allé pour Gradle (devenir assez amer à ce stade, et agacé que "Cela ne devrait pas être si dur!")

Mais dès le premier jour, mon humeur a commencé à s'améliorer. J'arrivais quelque part. Cela m'a pris deux heures pour migrer mon premier module de fourmis et le fichier de construction n'était pratiquement rien. Facilement équipé d'un écran. Le grand "wow" était: construire des scripts en XML, comme c'est stupide? le fait que déclarer une dépendance prenne une ligne est très attrayant pour moi -> vous pouvez facilement voir toutes les dépendances pour un certain projet sur une seule page. À partir de ce moment-là, j'ai été constamment en mouvement, car pour chaque problème rencontré jusqu'à présent, il existe une solution simple et élégante. Je pense que ce sont les raisons:

  • groovy est très intuitif pour les développeurs java
  • la documentation est géniale à génial
  • la flexibilité est infinie

Maintenant, je passe mes journées à essayer d'imaginer de nouvelles fonctionnalités à ajouter à notre processus de construction. Comme c'est malade?




Cela peut être un peu controversé, mais Gradle ne cache pas le fait que c'est un langage de programmation à part entière.

Ant + ant-contrib est essentiellement un langage de programmation complet que personne ne veut vraiment programmer.

Maven essaie de prendre l'approche inverse d'essayer d'être complètement déclaratif et de vous forcer à écrire et à compiler un plugin si vous avez besoin de logique. Il impose également un modèle de projet complètement inflexible. Gradle combine le meilleur de tous ces outils:

  • Il suit la convention sur-configuration (ala Maven), mais seulement dans la mesure où vous le voulez
  • Il vous permet d'écrire des tâches personnalisées flexibles comme dans Ant
  • Il fournit un support de projet multi-module supérieur à Ant et Maven
  • Il a un DSL qui rend les 80% de choses faciles et les 20% de choses possibles (contrairement à d'autres outils de construction qui rendent les 80% faciles, 10% possibles et 10% effectivement impossibles).

Gradle est l'outil de construction le plus configurable et flexible que je n'ai pas encore utilisé. Cela nécessite des investissements initiaux pour apprendre le DSL et des concepts comme les configurations, mais si vous avez besoin d'un outil de construction JVM simple et entièrement configurable, c'est difficile à battre.




Gradle combine à la fois Ant et Maven, en prenant le meilleur des deux cadres. Flexibilité de Ant et convention sur la configuration, la gestion des dépendances et les plugins de Maven.

Donc, si vous voulez avoir une build java standard, comme dans maven, mais que la tâche de test doit faire une étape personnalisée, elle pourrait ressembler à ci-dessous.

build.gradle:

apply plugin:'java'
task test{
  doFirst{
    ant.copy(toDir:'build/test-classes'){fileset dir:'src/test/extra-resources'}
  }
  doLast{
    ...
  }
}

En plus de cela, il utilise une syntaxe groovy qui donne beaucoup plus de puissance d'expression que le xml d'ant / maven.

C'est un surensemble de Ant - vous pouvez utiliser toutes les tâches Ant dans Gradle avec une syntaxe plus agréable et plus groovy, c'est-à-dire.

ant.copy(file:'a.txt', toDir:"xyz")

ou

ant.with{
  delete "x.txt"
  mkdir "abc"
  copy file:"a.txt", toDir: "abc"
}



Ce n'est pas ma réponse, mais ça résonne définitivement avec moi. C'est à partir du radar de technologie de ThoughtWorks d'octobre 2012 :

Deux choses ont causé de la fatigue avec les outils de construction basés sur XML comme Ant et Maven: trop d'accolades pointues en colère et la grossièreté des architectures de plug-in. Tandis que les problèmes de syntaxe peuvent être résolus via la génération, les architectures de plug-in limitent considérablement la capacité des outils de construction à croître de manière progressive à mesure que les projets deviennent plus complexes. Nous en sommes venus à penser que les plug-ins sont un mauvais niveau d'abstraction, et préférons les outils basés sur les langages comme Gradle et Rake, car ils offrent des abstractions plus fines et plus de flexibilité à long terme.




Il est également beaucoup plus facile de gérer les builds natifs. Ant et Maven sont effectivement Java seulement. Certains plugins existent pour Maven qui essaient de gérer certains projets natifs, mais ils ne font pas un travail efficace. Des tâches Ant peuvent être écrites pour compiler des projets natifs, mais elles sont trop complexes et complexes.

Nous faisons Java avec JNI et beaucoup d'autres bits natifs. Gradle a simplifié considérablement notre désordre Ant. Lorsque nous avons commencé à introduire la gestion des dépendances dans les projets natifs, c'était désordonné. Nous avons demandé à Maven de le faire, mais le code Gradle équivalent était une infime fraction de ce qui était nécessaire à Maven, et les gens pouvaient le lire et le comprendre sans devenir des gourous Maven.




Je suis en partie d'accord avec Ed Staub. Gradle est certainement plus puissant par rapport à Maven et offre plus de flexibilité à long terme.

Après avoir effectué une évaluation pour passer de maven à gradle, nous avons décidé de coller à maven lui-même pour deux problèmes rencontrés avec gradle (la vitesse est plus lente que maven, proxy ne fonctionnait pas).




La morale de cette étrangeté est:

  • Utilisez les dates et heures en UTC chaque fois que possible.
  • Si vous ne pouvez pas afficher une date ou une heure au format UTC, indiquez toujours le fuseau horaire.
  • Si vous ne pouvez pas exiger de date / heure d'entrée en UTC, indiquez un fuseau horaire explicitement indiqué.




java maven ant build-process gradle