Ant vs Maven vs Gradle

Cet article fait partie d'une série: • Introduction à Gradle

• Ant vs Maven vs Gradle (article actuel) • Rédaction de plugins Gradle personnalisés

• Créer un Fat Jar dans Gradle

1. Introduction

Dans cet article, nous explorerons trois outils d'automatisation de build Java qui dominaient l'écosystème JVM: Ant, Maven et Gradle .

Nous présenterons chacun d'eux et explorerons comment les outils d'automatisation de build Java ont évolué.

2. Apache Ant

Au début, Make était le seul outil d'automatisation de construction disponible au-delà des solutions locales . Make existe depuis 1976 et en tant que tel, il a été utilisé pour créer des applications Java dans les premières années Java.

Cependant, beaucoup de conventions des programmes C ne cadraient pas avec l'écosystème Java, donc avec le temps Ant a pris le relais comme une meilleure alternative.

Apache Ant («Another Neat Tool») est une bibliothèque Java utilisée pour automatiser les processus de construction des applications Java . De plus, Ant peut être utilisé pour créer des applications non Java. Il faisait initialement partie de la base de code Apache Tomcat et a été publié en tant que projet autonome en 2000.

Dans de nombreux aspects, Ant est très similaire à Make, et c'est assez simple pour que tout le monde puisse commencer à l'utiliser sans aucun prérequis particulier. Les fichiers de construction Ant sont écrits en XML et, par convention, ils sont appelés build.xml .

Les différentes phases d'un processus de construction sont appelées «cibles».

Voici un exemple de fichier build.xml pour un projet Java simple avec la classe principale HelloWorld :

Ce fichier de construction définit quatre cibles: nettoyer , compiler , jar et exécuter . Par exemple, nous pouvons compiler le code en exécutant:

ant compile

Cela déclenchera d'abord le nettoyage de la cible qui supprimera le répertoire «classes». Après cela, la compilation cible recréera le répertoire et y compilera le dossier src.

Le principal avantage de Ant est sa flexibilité. Ant n'impose aucune convention de codage ni structure de projet. Par conséquent, cela signifie que Ant oblige les développeurs à écrire toutes les commandes par eux-mêmes, ce qui conduit parfois à d'énormes fichiers de construction XML difficiles à maintenir.

Comme il n'y a pas de conventions, le simple fait de connaître Ant ne signifie pas que nous comprendrons rapidement n'importe quel fichier de construction Ant. Il faudra probablement un certain temps pour s'habituer à un fichier Ant inconnu, ce qui est un inconvénient par rapport aux autres outils plus récents.

Au début, Ant n'avait pas de support intégré pour la gestion des dépendances. Cependant, comme la gestion des dépendances est devenue incontournable ces dernières années, Apache Ivy a été développé en tant que sous-projet du projet Apache Ant. Il est intégré à Apache Ant et suit les mêmes principes de conception.

Cependant, les limitations initiales d'Ant dues à l'absence de prise en charge intégrée de la gestion des dépendances et les frustrations lors de l'utilisation de fichiers de construction XML ingérables ont conduit à la création de Maven.

3. Apache Maven

Apache Maven est un outil de gestion des dépendances et d'automatisation de construction, principalement utilisé pour les applications Java. Maven continue d'utiliser des fichiers XML comme Ant mais d'une manière beaucoup plus gérable. Le nom du jeu ici est la convention sur la configuration.

Alors que Ant donne de la flexibilité et exige que tout soit écrit à partir de zéro, Maven s'appuie sur des conventions et fournit des commandes prédéfinies (objectifs).

En termes simples, Maven nous permet de nous concentrer sur ce que notre build doit faire et nous donne le cadre pour le faire. Un autre aspect positif de Maven était qu'il fournissait un support intégré pour la gestion des dépendances.

Le fichier de configuration de Maven, contenant les instructions de construction et de gestion des dépendances, est par convention appelé pom.xml . De plus, Maven prescrit également une structure de projet stricte, tandis que Ant y offre également une flexibilité.

Voici un exemple de fichier pom.xml pour le même projet Java simple avec la classe principale HelloWorld d'avant:

 4.0.0 baeldung mavenExample 0.0.1-SNAPSHOT Maven example   junit junit 4.12 test   

Cependant, la structure du projet a également été standardisée et est conforme aux conventions Maven:

+---src | +---main | | +---java | | | \---com | | | \---baeldung | | | \---maven | | | HelloWorld.java | | | | | \---resources | \---test | +---java | \---resources

Contrairement à Ant, il n'est pas nécessaire de définir manuellement chacune des phases du processus de construction. Au lieu de cela, nous pouvons simplement appeler les commandes intégrées de Maven.

Par exemple, nous pouvons compiler le code en exécutant:

mvn compile

À la base, comme indiqué sur les pages officielles, Maven peut être considéré comme un cadre d'exécution de plugins, car tout le travail est effectué par des plugins. Maven prend en charge une large gamme de plugins disponibles, et chacun d'eux peut être configuré en plus.

L'un des plugins disponibles est Apache Maven Dependency Plugin qui a un objectif de dépendances de copie qui copiera nos dépendances dans un répertoire spécifié.

Pour montrer ce plugin en action, incluons ce plugin dans notre fichier pom.xml et configurons un répertoire de sortie pour nos dépendances:

   org.apache.maven.plugins maven-dependency-plugin   copy-dependencies package  copy-dependencies   target/dependencies       

Ce plugin sera exécuté dans une phase de package , donc si nous exécutons:

mvn package

Nous allons exécuter ce plugin et copier les dépendances dans le dossier target / dependencies.

Il existe également un article sur la création d'un fichier JAR exécutable à l'aide de différents plugins Maven. De plus, pour un aperçu détaillé de Maven, jetez un œil à ce guide de base sur Maven, où certaines fonctionnalités clés de Maven sont explorées.

Maven est devenu très populaire car les fichiers de construction étaient désormais standardisés et la maintenance des fichiers de construction prenait beaucoup moins de temps que Ant. Cependant, bien que plus standardisés que les fichiers Ant, les fichiers de configuration Maven ont toujours tendance à devenir volumineux et encombrants.

Les conventions strictes de Maven ont le prix d'être beaucoup moins flexibles que Ant. La personnalisation des objectifs est très difficile, donc l'écriture de scripts de construction personnalisés est beaucoup plus difficile à faire que Ant.

Bien que Maven ait apporté de sérieuses améliorations pour rendre les processus de création d'applications plus faciles et plus standardisés, il a toujours un prix car il est beaucoup moins flexible que Ant. Cela a conduit à la création de Gradle qui combine le meilleur des deux mondes - la flexibilité d'Ant et les fonctionnalités de Maven.

4. Gradle

Gradle est un outil de gestion des dépendances et d'automatisation de construction qui a été construit sur les concepts de Ant et Maven.

L'une des premières choses que nous pouvons noter à propos de Gradle est qu'il n'utilise pas de fichiers XML, contrairement à Ant ou Maven.

Au fil du temps, les développeurs sont devenus de plus en plus intéressés à avoir et à travailler avec un langage spécifique à un domaine - ce qui, tout simplement, leur permettrait de résoudre des problèmes dans un domaine spécifique en utilisant un langage adapté à ce domaine particulier.

Cela a été adopté par Gradle, qui utilise un DSL basé sur Groovy ou Kotlin. Cela a conduit à des fichiers de configuration plus petits avec moins d'encombrement puisque le langage a été spécialement conçu pour résoudre des problèmes de domaine spécifiques. Le fichier de configuration de Gradle est par convention appelé build.gradle dans Groovy ou build.gradle.kts dans Kotlin.

Notez que Kotlin offre un meilleur support IDE que Groovy pour l'auto-complétion et la détection des erreurs.

Voici un exemple de fichier build.gradle pour le même projet Java simple avec la classe principale HelloWorld d'avant:

apply plugin: 'java' repositories { mavenCentral() } jar { baseName = 'gradleExample' version = '0.0.1-SNAPSHOT' } dependencies { testImplementation 'junit:junit:4.12' }

Nous pouvons compiler le code en exécutant:

gradle classes

À la base, Gradle fournit intentionnellement très peu de fonctionnalités. Les plugins ajoutent toutes les fonctionnalités utiles. Dans notre exemple, nous utilisions le plugin java qui nous permet de compiler du code Java et d'autres fonctionnalités précieuses.

Gradle a donné à ses étapes de construction le nom de «tâches», par opposition aux «cibles» de Ant ou aux «phases» de Maven. Avec Maven, nous avons utilisé Apache Maven Dependency Plugin, et c'est un objectif spécifique de copier les dépendances dans un répertoire spécifié. Avec Gradle, nous pouvons faire de même en utilisant des tâches:

task copyDependencies(type: Copy) { from configurations.compile into 'dependencies' }

Nous pouvons exécuter cette tâche en exécutant:

gradle copyDependencies

5. Conclusion

Dans cet article, nous avons présenté Ant, Maven et Gradle - trois outils d'automatisation de build Java.

Sans surprise, Maven détient aujourd'hui la majorité du marché des outils de construction.

Gradle, cependant, a connu une bonne adoption dans des bases de code plus complexes, pour les raisons suivantes:

  • De nombreux projets open-source tels que Spring l'utilisent maintenant
  • Il est plus rapide que Maven pour la plupart des scénarios, grâce à ses builds incrémentiels
  • Il offre des services avancés d'analyse et de débogage

Cependant, Gradle semble avoir une courbe d'apprentissage plus raide, surtout si vous n'êtes pas familier avec Groovy ou Kotlin.

Suivant » Ecrire des plugins Gradle personnalisés « Précédent Introduction à Gradle