ANT vs Maven vs Gradle

par

Avant de se lancer dans ANT, Maven ou Gradle, nous devons d’abord comprendre quelques éléments qui leur sont liés.

Dépendance : En général, une dépendance se réfère à quand quelque chose exige une certaine autre chose pour obtenir exécuté lui-même. En termes simples, ‘A’ a une dépendance sur ‘B’ si ‘A’ a besoin de ‘B’ pour son exécution réussie. Dans le monde des logiciels, une dépendance est tout ce dont votre application a besoin pour s’exécuter correctement. Il s’agit essentiellement de toute bibliothèque de support externe requise par l’application. par exemple, zuul, hystrix, lombok, jdbc, etc.

Initialement, nous avions l’habitude de gérer les dépendances en :

  • téléchargeant manuellement le fichier jar de la bibliothèque requise depuis Internet et en l’ajoutant à notre projet.
  • écrivant un script qui téléchargera automatiquement la bibliothèque depuis une source externe sur le réseau.

Problèmes rencontrés avant ces outils :

  • Ajouter les dépendances en les téléchargeant manuellement depuis internet est une tâche très fatigante.
  • Nos scripts pourraient échouer si l’URL de la source externe change sur internet.
  • Il est très difficile d’identifier et de gérer les dépendances transitives dans notre application.

Outil de gestion des dépendances : Il résout et gère les dépendances requises par l’application.

Outil de construction : Il automatise la création d’applications exécutables à partir du code source. La construction incorpore la compilation, la liaison et l’emballage du code dans une forme utilisable ou exécutable. L’automatisation de la construction implique :

  1. Le téléchargement des dépendances
  2. La compilation du code source en code binaire
  3. L’empaquetage de ce code binaire
  4. L’exécution de tests
  5. Le déploiement sur des systèmes de production

La gestion des dépendances et les outils de construction en java :

  • ANT + Ivy (2000/2004)
  • Maven (2004)
  • Gradle (2012)

Apache ANT (Another Neat Tool) est un projet open source d’Apache, publié en 2000. Il s’agit d’une bibliothèque java utilisée pour automatiser les processus de construction des applications java. Elle peut également être utilisée pour construire des applications non-java. Il suit le principe de « Configuration over convention ». Dans Ant, les différentes phases du processus de construction sont appelées « cibles ». Les fichiers de construction ANT sont écrits en XML et par convention, ils sont appelés « build.xml ». Il contient trois éléments : projet, cible et tâche. Chaque fichier de compilation contient un projet. Chaque chose dans le build.xml est sous l’élément project. Le projet contient au moins une cible (par défaut). La cible contient un ensemble de tâches et définit un état spécifique du processus de construction. Une tâche est un morceau de code qui peut être exécuté. Chaque nœud peut avoir des attributs qui lui sont associés:

Attributs du projet:

  • Nom : Le nom du projet.
  • Basedir : Le dossier racine du projet et il est facultatif.
  • Défaut : La cible par défaut pour la construction. Le projet peut avoir un ou plusieurs nombre de cibles. Il est utilisé pour spécifier la cible par défaut du projet.

Attributs de la cible:

  • Nom : Le nom de la cible.
  • Description : Une description sur la cible.
  • Depends : Liste de toutes les cibles, séparées par une virgule, dont cette cible dépend.
  • Si : La cible est exécutée si l’attribut est vrai.
  • Unless : La cible est exécutée si l’attribut n’est pas défini.

Exemple de Build.xml:

<?xml version="1.0"?>
<project>
<target name="hello">
<echo>Hello, World</echo> 
</target>
</project>

Ajouter une dépendance dans Ant + Ivy:

<dependency org="org.projectlombok" name="lombok" rev="1.18.10"/>

Le principal avantage de Ant est sa flexibilité. Ant n’impose aucune convention de codage ou structure de projet au développeur. Par conséquent, cela signifie que Ant demande aux développeurs d’écrire toutes les commandes par eux-mêmes, ce qui conduit parfois à des fichiers de construction volumineux et difficiles à maintenir. Initialement, Ant n’avait pas de support intégré pour la gestion des dépendances. Plus tard, il a adopté Apache Ivy, développé comme un sous-projet du projet Apache Ant, dans le but de gérer les dépendances.

Apache Maven

C’est un outil de gestion des dépendances et d’automatisation de la construction, sorti en 2004. Il continue à utiliser XML mais surmonte les inconvénients en suivant le principe de « Convention over configuration ». Il s’appuie sur des conventions et fournit des commandes prédéfinies (goals). Son fichier de configuration, contenant les instructions de construction et de gestion des dépendances, est par convention appelé « pom.xml » et est présent dans le dossier racine du projet.

Flux de travail deaven

Le moteur deaven prend pom.xml et le projet comme entrées. Il lit le fichier pom.xml et télécharge les dépendances qui y sont mentionnées sous forme de fichiers jar dans le référentiel local. Ensuite, il exécute les cycles de vie, les phases de construction et les plugins. A la fin, un artefact packagé et testé est généré.

exemple de pom.xml:

Certaines balises importantes dans le fichier pom.xml:

  • groupId : Il représente l’organisation à laquelle appartient le projet.
  • artifactId : Il représente le nom du projet.
  • version : Elle représente la version du projet.
  • packaging : Il représente la forme finale de la construction du projet. par exemple, jar, war.

Ajouter une dépendance dans maven:

<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.10</version>
</dependency>

Dépôt maven:

Un dépôt est un répertoire où tous les fichiers jar empaquetés existent avec leurs propres fichiers pom. Ces fichiers pom contiennent les dépendances externes de ce projet. De cette façon, maven télécharge la dépendance des dépendances de votre projet de manière récursive jusqu’à ce que toutes les dépendances requises soient présentes dans votre dépôt local. Il existe trois types de dépôts dans maven:

  1. Dépôt local : C’est un référentiel présent sur la machine même du développeur.
  2. Référentiel au niveau de l’organisation/à distance : C’est un référentiel présent au sein de l’organisation.
  3. Référentiel central : C’est un dépôt sur internet, créé et maintenu par la communauté maven.

Chaque fois qu’une dépendance est spécifiée dans le fichier pom.xml d’un projet, maven la recherche dans le dépôt local. Si elle n’y est pas trouvée, il la cherche dans le dépôt distant/org wide repository. S’il n’est pas présent même là, alors il le cherche dans le dépôt central.

Maven prescrit une structure de projet stricte, tandis que Ant fournit une flexibilité là aussi. Ses conventions strictes viennent avec le prix d’être beaucoup moins flexible que Ant – la personnalisation des objectifs est très difficile.

Des inconvénients de maven:

  1. La gestion des dépendances ne gère pas bien les conflits entre les différentes versions de la même bibliothèque.
  2. La personnalisation des objectifs est difficile.

Gradle

C’est un outil open-source de gestion des dépendances et d’automatisation des builds, sorti en 2012. Il combine les bonnes parties d’Apache Ant et d’Apache Maven et construit au-dessus d’eux et utilise un langage spécifique au domaine (basé sur Groovy) au lieu de XML. Il a adopté la flexibilité de Ant et son cycle de vie de Maven. Il suit également le principe de « Convention over configuration ». Il prend en charge les référentiels Maven et Ivy pour récupérer les dépendances. Son fichier de configuration est par convention connu sous le nom de « build.gradle » et est présent dans le dossier racine du projet. Gradle a donné à ses étapes de construction le nom de « tâches », par opposition aux « cibles » de Ant ou aux « phases » de Maven. Google a adopté Gradle comme outil de construction par défaut pour Android OS.

Gradle n’utilise pas XML. Au lieu de cela, il avait son propre langage spécifique au domaine basé sur Groovy (l’un des langages JVM). En conséquence, les scripts de construction Gradle ont tendance à être beaucoup plus courts et plus clairs que ceux écrits pour Ant ou Maven. La quantité de code boilerplate est beaucoup plus faible avec Gradle.

Configurations Gradle

  • implémentation : Il est utilisé pour déclarer les dépendances que nous ne voulons pas exposer à la compilation de nos consommateurs.
  • api : Il est utilisé pour déclarer les dépendances qui font partie de notre API, c’est-à-dire pour les dépendances que nous voulons explicitement exposer à nos consommateurs.
  • compileOnly : Elle nous permet de déclarer des dépendances qui ne devraient être disponibles qu’au moment de la compilation, mais qui ne sont pas nécessaires au moment de l’exécution. Un exemple de cas d’utilisation pour cette configuration est un processeur d’annotation comme Lombok, qui modifie le bytecode au moment de la compilation. Après la compilation, il n’est plus nécessaire, donc la dépendance n’est pas disponible à l’exécution.
  • runtimeOnly : Il nous permet de déclarer des dépendances qui ne sont pas nécessaires au moment de la compilation, mais qui seront disponibles au moment de l’exécution. Un exemple est SLF4J où nous incluons slf4j-api à la configuration implementation et une implémentation de cette API (comme slf4j-log4j12 ou logback-classic) à la configuration runtimeOnly.
  • testImplementation : Similaire à implementation, mais les dépendances déclarées avec testImplementation ne sont disponibles que pendant la compilation et l’exécution des tests. Nous pouvons l’utiliser pour déclarer des dépendances à des frameworks de test comme JUnit ou Mockito dont nous avons seulement besoin dans les tests et qui ne devraient pas être disponibles dans le code de production.
  • testCompileOnly : Similaire à compileOnly, mais les dépendances déclarées avec testCompileOnly ne sont disponibles que lors de la compilation des tests et pas au moment de l’exécution.
  • testRuntimeOnly : Semblable à runtimeOnly, mais les dépendances déclarées avec testRuntimeOnly ne sont disponibles que pendant l’exécution des tests et non au moment de la compilation.

Projets et tâches dans Gradle

Chaque construction Gradle se compose d’un ou plusieurs projets. Chaque projet est constitué d’un ensemble de tâches. Chaque tâche représente une seule pièce de travail qu’un build effectue, par exemple générer un JavaDoc, publier certaines archives à un dépôt, etc.

Build.gradle exemple

Dépôt Gradle:

Les « alias » dans Gradle sont utilisés dans le cas de l’ajout de dépôts Maven à notre build de projet. Ces alias sont les suivants:

  • mavenCentral() : Cet alias représente les dépendances qui sont récupérées à partir du dépôt central de Maven 2.
  • jcenter() : Cet alias représente les dépendances qui sont récupérées à partir du dépôt Maven JCenter de Bintray.
  • mavenLocal() : Cet alias représente les dépendances qui sont récupérées à partir du dépôt Maven local.

Exemple : ajouter le dépôt Maven central dans notre projet, ajouter le bout de code suivant à notre fichier ‘build.gradle’:

repositories {
mavenCentral()
}

Ajouter une dépendance dans Gradle:

compile group: 'org.hibernate', name: 'hibernate-core', version: '3.6.7.Final'

Avantages:

  1. Il gère assez bien les dépendances transitives. Si une dépendance transitive conflictuelle existe dans le projet alors pour la résoudre, il sélectionne la dernière version de la dépendance. Par exemple, la dépendance ‘A’ nécessite en interne la dépendance ‘C’ avec la version 2.0 et la dépendance ‘B’ nécessite en interne la dépendance ‘C’ avec la version 3.0. Alors Gradle utilisera la dernière verison de la dépendance ‘C’.
  2. Les fichiers de configuration de Gradle sont plus petits en taille et plus propres car il utilise un langage spécifique au domaine, basé sur Groovy au lieu de XML.
  3. Gradle utilise le concept de construction incrémentale et évite le travail en suivant l’entrée et la sortie des tâches et en n’exécutant que ce qui est nécessaire, et en ne traitant que les fichiers qui ont changé quand c’est possible et donc, exécute plus rapidement que maven.

.

Laisser un commentaire