Pourquoi utiliser Gradle au lieu de Ant ou Maven? [fermé]

Qu'est-ce qu'un autre outil de build destiné à Java m'a vraiment apporté?

Si vous utilisez Gradle sur un autre outil, pourquoi?

Je ne me Gradle en colère moi - même (juste un projet de jouet à ce jour) [moyens d'auteur qu'ils ont utilisé Gradle que sur un projet de jouet jusqu'à présent, pas Gradle est un projet de jouet - voir les commentaires] , mais je dirais que les raisons pour lesquelles on envisagerait de l'utiliser seraient les frustrations d'Ant et Maven.

D'après mon expérience, Ant est souvent en écriture seule (oui je sais qu'il est possible d'écrire des builds magnifiquement modulaires et élégants , mais le fait est que la plupart des gens ne le font pas). Pour tous les projets non triviaux, cela devient époustouflant et prend grand soin de s'assurer que les constructions 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 vous intégriez complètement au cycle de vie de Maven. Les utilisateurs expérimentés de Ant trouvent cela particulièrement discordant, car Maven supprime la plupart des libertés que vous avez dans Ant. Par exemple, il existe un blog Sonatype qui énumère de nombreuses critiques de Maven et leurs réponses.

Le mécanisme de plug-in Maven permet des configurations de build très puissantes, et le modèle d'héritage signifie que vous pouvez définir un petit ensemble de POM parents encapsulant vos configurations de build pour toute l'entreprise et que les projets individuels peuvent hériter de ces configurations, les laissant légères. La configuration de Maven est très détaillée (bien que Maven 3 promette de résoudre ce problème), et si vous voulez faire quelque chose qui n'est "pas la manière Maven", vous devez écrire un plugin ou utiliser l'intégration hacky Ant. Notez que j'aime écrire des plugins Maven mais j'apprécie que beaucoup s'opposeront à l'effort impliqué.

Gradle promet de frapper le point idéal entre Ant et Maven. Il utilise l'approche d' Ivy pour la résolution des dépendances. Il permet une convention sur la configuration mais inclut également des tâches Ant en tant que citoyens de première classe. Il vous permet également d'utiliser judicieusement les référentiels Maven / Ivy existants.

Donc, si vous avez frappé et êtes resté coincé avec l'un des points douloureux Ant / Maven, cela vaut probablement la peine d'essayer Gradle, bien qu'à mon avis, il reste à voir si vous ne feriez pas simplement l'échange de problèmes connus contre des problèmes inconnus. La preuve du pudding se trouve dans l'alimentation, donc je réserve mon jugement jusqu'à ce que le produit soit un peu plus mûr et que d'autres aient corrigé les plis (ils appellent cela un bord saignant pour une raison). Je vais quand même l'utiliser dans mes projets de jouets, c'est toujours bon d'être conscient des options.

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épendances, ce 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 (arborescence, plat, dispersé, ...).

Gradle comporte deux phases distinctes: l'évaluation et l'exécution. Fondamentalement, lors de l'évaluation, Gradle recherchera et évaluera les scripts de construction dans les répertoires qu'il est censé rechercher. 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épendances 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 avisé que Maven.

Gradle détecte les dépendances entre les projets et entre les projets et les fichiers JAR. Gradle fonctionne avec les référentiels Maven (téléchargement et téléchargement) comme iBiblio ou vos propres référentiels, mais prend également en charge et d'autres types d'infrastructure de référentiel que vous pourriez avoir.

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

Gradle s'efforce de ne pas vous gêner, un effort que Maven ne fait presque jamais. La convention est bonne, tout comme la flexibilité. Gradle vous offre beaucoup plus de fonctionnalités que Maven, mais le plus important dans de nombreux cas, Gradle vous offrira un chemin de transition indolore loin de Maven.

Cela peut être un peu controversé, mais Gradle ne cache pas le fait qu'il s'agit d'un langage de programmation à part entière.

Ant + ant-contrib est essentiellement un langage de programmation complet et turing dans lequel personne ne veut vraiment programmer.

Maven essaie d'adopter l'approche inverse en essayant d'être complètement déclaratif et en vous forçant à écrire et à compiler un plugin si vous avez besoin de logique. Elle impose également un modèle de projet totalement inflexible. Gradle combine le meilleur de tous ces outils:

• Il suit la convention sur la configuration (ala Maven) mais seulement dans la mesure où vous le souhaitez
• 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 une DSL qui rend les choses à 80% faciles et les choses à 20% possibles (contrairement aux 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 un certain investissement à l'avance pour apprendre la DSL et des concepts comme les configurations, mais si vous avez besoin d'un outil de construction JVM sans fioritures et entièrement configurable, il est difficile à battre.

Gradle combine joliment Ant et Maven, tirant le meilleur parti 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 construction java standard, comme dans maven, mais la tâche de test doit faire une étape personnalisée à laquelle cela 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 de ant / maven.

C'est un surensemble de Ant - vous pouvez utiliser toutes les tâches Ant en gradle avec une syntaxe plus agréable et 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"
}

Nous utilisons Gradle et l'avons choisi sur Maven et Ant. Ant nous a donné une flexibilité totale et Ivy offre une meilleure gestion des dépendances que Maven, mais il n'y a pas un grand support pour les builds multi-projets. Vous finissez par faire beaucoup de codage pour prendre en charge les builds multi-projets. Avoir également une construction par convention est agréable et rend les scripts de construction plus concis. Avec Maven, la construction par convention est trop poussée et la personnalisation de votre processus de construction devient un hack. En outre, Maven promeut chaque projet publiant un artefact. Parfois, un projet est divisé en sous-projets, mais vous souhaitez que tous les sous-projets soient créés et versionnés ensemble. Pas vraiment quelque chose pour lequel Maven est conçu.

Avec Gradle, vous pouvez avoir la flexibilité de Ant et construire par convention de Maven. Par exemple, il est trivial d'étendre le cycle de vie de génération classique avec votre propre tâche. Et vous n'êtes pas obligé d'utiliser une convention si vous ne le souhaitez pas. Groovy est beaucoup plus agréable à coder que XML. Dans Gradle, vous pouvez définir des dépendances entre les projets sur le système de fichiers local sans avoir besoin de publier des artefacts pour chacun dans un référentiel. Enfin, Gradle utilise Ivy, il a donc une excellente gestion des dépendances. Le seul véritable inconvénient pour moi jusqu'à présent est le manque d'intégration Eclipse mature, mais les options pour Maven ne sont pas vraiment meilleures.

Ce n'est pas ma réponse, mais elle résonne définitivement avec moi. Il s'agit du radar technologique 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. Bien que les problèmes de syntaxe puissent être traités par la génération, les architectures de plug-in limitent considérablement la capacité des outils de construction à se développer avec élégance à mesure que les projets deviennent plus complexes. Nous avons fini par penser que les plug-ins ne sont pas le bon niveau d'abstraction, et préférons plutôt des outils basés sur le langage comme Gradle et Rake, car ils offrent des abstractions plus fines et plus de flexibilité à long terme.

Gradle a remis le plaisir dans la construction / assemblage de logiciels. J'ai utilisé ant pour construire des logiciels toute ma carrière et j'ai toujours considéré la partie "buildit" réelle du travail de développement comme un mal nécessaire. Il y a quelques mois, notre entreprise en avait assez de ne pas utiliser de référentiel binaire (c'est-à-dire archiver des bocaux dans les vcs) et j'ai été chargé d'enquêter. J'ai commencé avec le lierre car il pouvait être boulonné sur une fourmi, je n'ai pas eu beaucoup de chance pour que mes artefacts construits soient publiés comme je le voulais. Je suis allé pour maven et j'ai piraté avec xml, travaillé à merveille pour quelques bibliothèques d'assistance simples, mais j'ai rencontré de sérieux problèmes en essayant de regrouper des applications prêtes pour le déploiement. J'ai longtemps cherché des plugins sur Google et lu des forums, et j'ai fini par télécharger des milliards de pots de support pour divers plugins que j'ai eu du mal à utiliser.

Mais dès le premier jour, mon humeur a commencé à s'améliorer. J'allais quelque part. Cela m'a pris environ deux heures pour migrer mon premier module de fourmis et le fichier de construction n'était pratiquement rien. Un écran facilement adapté. Le gros "wow" était: construire des scripts en xml, c'est stupide? le fait que déclarer une dépendance prend UNE ligne est très attrayant pour moi -> vous pouvez facilement voir toutes les dépendances pour un certain projet sur une seule page. Depuis lors, je suis sur une lancée constante, 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 de trouver de nouvelles fonctionnalités à ajouter à notre processus de construction. Comment est-ce malade?

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

Nous faisons Java avec JNI et beaucoup d'autres bits natifs. Gradle a considérablement simplifié notre désordre de fourmis. Lorsque nous avons commencé à introduire la gestion des dépendances dans les projets natifs, c'était compliqué. Nous avons demandé à Maven de le faire, mais le code Gradle équivalent était une infime fraction de ce qui était nécessaire dans 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 définitivement plus puissant que Maven et offre plus de flexibilité à long terme.

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