Search
Calendar
July 2017
S M T W T F S
« Sep    
 1
2345678
9101112131415
16171819202122
23242526272829
3031  
Your widget title
Archives

PostHeaderIcon Retours du Devoxx France 2016 (4): Gradle: Harder, Better, Stronger, Faster

La conference est animee par Andres Almiray de Canoo Fellow, un Java Champion qui nous vient du Mexique. Officiellement, il s’agit de presenter Gradle pour un usage avance ; neanmoins, Andres dissimule a peine son intention de nous faire quitter Maven pour Gradle.

Entendons-nous bien: je suis persuade que Gradle a de nombreuses qualites que Maven n’a pas. Je dirais meme qu’a terme je ne vois pas pourquoi Maven ne subirait pas la meme destinee qu’Apache Ant.

Andres presente les qualites suivantes de Gradle:

  • “conventions over (not instead) configuration”: la convention a certes une importance, mais elle n’empeche pas de configurer finement le projet
  • les descriptions de projet de Gradle sont “expressive, extensible, productive and convenient”, et par consequent “Continous Integration friendly”.
  • alors que Maven et surtout Ivy sont sur une pente  descendante, Gradle est de plus en plus rependu au niveau des projets open source… avec des prises de choix, comme par exemple les modules de Spring recemment migres sous Gradle.

Au niveau des fonctionalites interessantes, Andres mentionne les points suivants:

  • “caching of task input and outputs: knows what to recompile/retest/repackage”: Gradle est assez intelligent pour batir un arbre de dependance et ne recompiler que ce qui est necessaire.
  • “richer, configurable lifecycle”: le cycle de vie et les scopes des dependances sont totalement libres. Andres note que par exemple, il est possible de definir un etat pour une dependance qui serait “provided”, mais uniquement pour les tests, ou bien necessaire uniquement pour la compilation des tests… ce que ne permet pas Maven.
  • le “gradle daemon”: il permet de ne pas avoir a redemarrer une JVM a chaque build.
  • le “gradle wrapper”
  • Gradle n’est pas seulement compatible avec les projets multi-modules: il a ete designed pour.
  • le developpement de plugins est assez intuitif
  • la documentation est riche et maintenue
  • l’installation est tres simple, en deux lignes:
curl -s get.sdkman.io | bash

, puis:

sdk install gradle
  • le fichier de configuration par default est build.gradle, mais il est possible de changer le nom. Cette fonctionnalite n’existe pas chez Maven d’apres Andres. Je ne suis pas d’accord: il est possible d’appeler Maven avec l’option -f, par exemple: mvn clean install -f toto/tata/titu/foo.xml.
  • Gradle n’est pas limite a Java. Une compilation canonique appelle un plugin java, mais rien n’empeche d’utiliser Maven pour des projets C++ ou autres.
  • jcenter, l’equivalent Gradle de Maven Central, contient plus d’artefacts.
  • Gradle est beaucoup moins verbeux que Maven. Andres donne l’exemple d’une application executable elementaire, qu’il decrit en 75 lignes d’XML sous Maven, contre 21 sous Gradle. Je suis tres critique de ce point, cela manque d’honnetete intellectuelle. Maven supporte certes le XML, mais aussi le YaML et tout autre langage de formatage via des plugins associes (bien que la majorite des IDE ne supportent que le XML).  On ne peut comparer deux outils comme Maven et Gradle en se basant uniquement sur les fonctionnalites permises par leurs plugins, qui sont, par nature, totalement libres et .
  • les lazybones: ce sont des outils pour demarrer rapidement des projets, un peu a l’image des archetypes Maven.

En conclusion, si le contenu du message d’Andres est tres pertinent (Gradle etant somme toute un tres bon outil), la demonstration ne me paraissait pas tres fair-play

Leave a Reply