Au revoir Maven... et place à Gradle !

Le titre se veut volontairement provocateur tout comme la conférence à Devoxx France de Cédric Champeau : "Gradle ne fait pas que remplacer Maven". Je vous propose un retour sur cette conférence pour voir les différences entre ces deux solutions et les apports de Gradle.

Maven : un structurateur de build

Apache Maven est aujourd'hui utilisé par la majorité des développeurs pour automatiser la construction (build) et le déploiement (deploy) des applications.

Le concept de "Convention over configuration" impose de respecter un certain nombre de règles :
  • nommage et structure des répertoires projet
  • définition du ou des pom (fichiers xml décrivant les règles de construction du projet : nom, version, dépendances, plugins...)
Maven se veut être un véritable structurateur de build laissant peu de place aux spécificités.
Pour builder avec Maven, il faut donc respecter les conventions, minimiser les configurations autant que possible et se plugger au cycle de vie à travers les différents goals (compile, test, package, install deploy...)
En cas de spécificités, la solution est bien souvent d'écrire un plugin Maven spécifique ou d'en chercher un pouvant répondre au besoin.

Et Gradle dans tout ça ?

En mélangeant et en reprenant les meilleurs concepts d'Ant, Maven, Ivy et Groovy, Gradle apporte de la flexibilité et de la souplesse pour répondre aux problématiques de build.

Contrairement à Maven, Gradle permet :
  • de générer plusieurs artifacts pour un même build
  • de décorréler le build et le déploiement
Gradle repose sur le concept de tâches (tasks) qu'il est possible de créer dynamiquement notamment grâce à la puissance du langage Groovy.

L'autre point fort de Gradle est la notion de build incrémental qui permet de gagner du temps dans la construction des livrables grâce à la définition de points d'entrée et de sortie permettant à Gradle de savoir que le build est ou non UP-TO-DATE.
L'initialisation d'un projet par la commande "gradle init" génère un wrapper dédié au projet contenant toutes les informations de versions y compris celle de Gradle, ce qui fait que le build du projet est portable sur n'importe quel environnement.
Un fichier de build Gradle (build.gradle) pour un projet Java tient en une ligne :
apply plugin:'java'
Il suffit ensuite de lancer gradle build pour construire le projet.

Gradle permet aussi de la souplesse dans la définition des repositories (adresse d'un repository officiel, adresse d'un proxy, adresse d'un serveur partagé et toute autre ressource au sens large) pour faciliter la récupération des librairies ou autres.
Les temps d'exécution des builds sont proches et équivalents à ceux de Maven si "--daemon" est ajouté en option dans les commandes Gradle.
Pour terminer, quelques mots sur le futur de Gradle. Actuellement en version 1.11, le cycle de release aboutit en moyenne à une nouvelle version toutes les 6 semaines. Une version 2 est d'ores et déjà prévue avec la prise en compte du parralélisme pour optimiser les builds dans des environnements distribués.
De toute évidence, Gradle est une solution à envisager dans la construction de projet embarquant des architectures/technologies différentes entre front (Angular, Dart...) et back (Java, .NET...)

Autour du même sujet