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

Gradle peut être utilisé à de nombreuses fins - c'est un couteau suisse bien meilleur 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, 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 (arbre, plat, dispersé, ...).

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

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

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

Dans les builds multi-projets, Gradle est à la fois adaptable et s'adapte à la structure et à l'architecture de la construction. Vous n'avez pas à adapter votre structure ou 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 mais la flexibilité aussi. 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 que c'est un langage de programmation À part entière.

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

Maven essaie d'adopter l'approche inverse consistant à essayer d'être complètement déclaratif et à vous forcer à é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 convention-over-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-modules supérieur à Ant et Maven
• Il a un DSL qui rend les choses 80% faciles et les choses 20% possibles (contrairement à d'autres outils de construction qui rendent le 80% facile, 10% possible et 10% effectivement impossible).

Gradle est le plus outil de construction configurable et flexible que je n'ai pas encore utilisé. Il nécessite un certain investissement à l'avance pour apprendre le DSL et des concepts tels que les configurations, mais si vous avez besoin d'un outil de construction JVM complètement configurable et sans fioritures, il est difficile à battre.

Gradle combine bien 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 construction java standard, comme dans maven, mais la tâche de test doit faire une étape personnalisée, elle pourrait ressembler à ci-dessous.

Construire.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 pouvoir 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, groovy-like, ie.

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 donne une meilleure gestion des dépendances que Maven, mais il n'y a pas un grand support pour les constructions multi-projets. Vous finissez par faire beaucoup de codage pour prendre en charge les builds multi-projets. Avoir aussi une construction par convention est agréable et rend les scripts de construction plus concis. Avec Maven, il faut construire par convention trop loin, et la personnalisation de votre processus de construction devient un hack. En outre, Maven promeut chaque projet publiant un artefact. Parfois, vous avez un projet divisé en sous-projets, mais vous voulez que tous les sous-projets seront construits et versionné ensemble. Pas vraiment quelque chose Maven est conçu pour.

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 construction conventionnel avec votre propre tâche. Et vous n'êtes pas obligés d'utiliser une convention si vous ne souhaitez pas. Groovy est beaucoup plus agréable à coder que XML. Dans Gradle, vous pouvez définir 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, donc il a une excellente gestion des dépendances. Le seul inconvénient réel pour moi jusqu'à présent est le manque d'intégration d'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 est de Thoughtworks' Radar de la technologie d'octobre 2012:

Deux choses ont causé de la fatigue avec des outils de construction basés sur XML comme Ant et Maven: trop d'accolades pointues en colère et la grossièreté du plug-in architecture. Alors que les problèmes de syntaxe peuvent être traités à travers génération, les architectures de plug-in limitent sévèrement la capacité de construction des outils pour grandir gracieusement à mesure que les projets deviennent plus complexe. Nous sommes venus pour sentir que les plug-ins sont le mauvais niveau d'abstraction, et préfèrent des outils basés sur la langue comme Gradle et Rake à la place, car ils offrent abstractions plus fines et plus de flexibilité à long terme.

Gradle remettre 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é que la partie "buildit" du travail de développement était un mal nécessaire. Il y a quelques mois, notre entreprise s'est lassée de ne pas utiliser de repo binaire (aka vérification des pots dans le vcs) et on m'a donné la tâche d'enquêter sur cela. Commencé avec ivy car il pourrait être boulonné sur ant, n'a pas eu beaucoup de chance d'obtenir mes artefacts construits publiés comme je le voulais. Je suis pour maven et piraté avec xml, a travaillé splendide pour quelques libs d'aide simples mais j'ai rencontré de sérieux problèmes en essayant de regrouper des applications prêtes à être déployées. Hassled un certain temps googler des plugins et des forums de lecture et liquidé télécharger des milliards de pots de soutien pour divers plugins que j'ai eu du mal à utiliser. Finalement, je suis allé pour gradle (devenir assez amer à ce stade, et agacé que "ça ne devrait pas être si dur!")

Mais dès le premier jour, mon humeur a commencé à s'améliorer. J'ai été faire quelque part. Il m'a fallu deux heures pour migrer mon premier module ant et le fichier de construction n'était fondamentalement rien. Facilement équipé d'un écran. Le grand " wow " était: build scripts {[4] } en xml, à quel point est-ce stupide? le fait de 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 page. A partir de là, j'ai été sur un rouleau constant, pour chaque problème que j'ai rencontré jusqu'à présent, il y a une solution simple et élégante. Je pense que ce sont les motifs:

• 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. Comment le malade est qui?

Il est également beaucoup plus facile de gérer les builds natifs. Ant et Maven sont effectivement Java uniquement. 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 gâchis de fourmis. Lorsque nous avons commencé à introduire la gestion des dépendances aux projets natifs, c'était désordonné. Nous Maven a réussi à 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 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 nous en tenir à maven lui-même pour deux questions nous avons rencontré avec gradle ( la vitesse est plus lente que maven, le proxy ne fonctionnait pas).