Tags

, , , , ,

J’ai eu l’occasion jeudi dernier d’assister à une présentation de l’outil de build Gradle par Hans Dockter, son fondateur. Cet événement était organisé par la société Zenika.

Dans son discours, Hans explique clairement avoir créé Gradle pour pallier au manque de flexibilité de Maven. Il souligne qu’avec Maven, on ne peut pas interagir avec les plugins, mais seulement les configurer de la façon spécifée. Ainsi, Gradle est un langage de build (et non un framework !) basé sur le principe qu’il est difficile de prévoir tous les scénarios auxquels nous pourrions être confrontés. Indéniablement, la présentation de Hans se déroule comme une partie de bras de fer avec Maven. Il anticipe immédiatement la question que tout le monde se pose : n’est-il pas risqué de s’affranchir des limites posées par Maven, sachant que c’est justement son caractère déclaratif et ses conventions qui en ont fait le succés, comparativement à ANT notamment ? A cette question Hans répond que nous sommes des informaticiens et que nous avons besoin d’outils pointus. “We need sharp tools”, dit-il.

Avec Gradle, les fichiers XML de ANT ou de Maven sont remplacés par des scripts Groovy. Ces scripts sont composés de “tasks” dépendant les unes des autres, comme avec ANT. On retrouve également de nombreuses notions inspirées de Maven, à commencer par la gestion des dépendances. Sur ce point, Gradle s’appuie sur Ivy qui lui confère un fonctionnement analogue à celui de Maven : compatibilité avec les dépôts Maven (repositories), transitivité, etc. La notion de “cycle de vie” de Maven est également présente. L’utilisation du plugin “Java”, par exemple, permet de bénéficier d’un cycle de vie proche de celui de Maven. On pourra ainsi lancer un “gradle clean package”.

Par contre, contrairement à Maven, les plugins fournis nativement font partie intégrante de la distribution Gradle, et évoluent donc au rythme de ses versions. Avantage : inutile de spécifier les versions des plugins pour obtenir un build reproductible. Inconvénients : en cas de bug sur un plugin, il faut attendre la version suivante de Gradle, et en cas de changement de version, les évolutions sur tous les plugins sont imposées. Notez à ce propos que depuis sa version 2.09, Maven fixe une version par défaut pour ses principaux plugins afin d’éviter toute contrainte. Le build n’est plus alourdi inutilement par des déclarations de versions mais il reste possible de surcharger les choix par défaut.

En ce qui concerne l’aspect dynamique du langage, Hans démontre effectivement que Gradle ne manque pas de souplesse. Le descripteur du build étant codé en Groovy, toute l’API Gradle est directement accessible : manipulation des dépendances, modification du comportement des tâches existantes. Il semble que tout soit possible. Les builds multi-projets sont supportés, et Gradle n’impose aucune contrainte quant à la structure des projets.

A l’exécution, Gradle propose un processus ingénieux, en deux phases. Avant l’exécution proprement dite, une phase de configuration est réalisée, sorte de “compilation” destinée à optimiser le déroulement du build. Cela offre également un autre intérêt : procurer aux tâches la capacité de connaître l’avenir, c’est-à-dire d’adapter leur comportement en fonction des tâches ultérieures.

ANT est intégré de façon bidirectionnelle : il est non seulement possible d’invoquer des tâches ANT depuis le script, mais aussi de compléter ou de modifier leur comportement, tout comme pour les tâches Gradle elles-mêmes. C’est Groovy qui rend cela possible en fournissant nativement un accès à son AntBuilder (voir à ce sujet l’article “Practically Groovy: Ant scripting with Groovy“).

Hans souligne qu’il prévoit également une forte intégration avec Maven.

Lors de la séance de questions, l’aspect “debugging” est évoqué. Hans indique qu’un debugger est disponible pour IntelliJ IDEA, l’IDE choisi pour développer Gradle, du fait de son support de Groovy. Le debugger n’est malheureusement pas disponible pour d’autres IDE. La nécessité d’avoir recours à un debugger est significative. Nous sommes bel et bien en présence d’un langage à part entière, et le build lui-même peut être considéré comme “un projet dans le projet”. C’est un inconvénient de ANT souvent cité, qui engendre des builds complexes, hétéroclites, peu maintenables.

La question de la compatibilité ascendante est également soulevée. Gradle étant actuellement en version 0.6.1, qu’adviendra-t-il lors du passage en 1.0 ? Hans répond qu’il y aura forcément des changements mais qu’il ne faut pas s’en inquiéter outre mesure. Avec un nom comme le sien, j’aurais pourtant juré qu’il n’était pas Normand 😉

Vient enfin la question de l’intégration avec Eclipse, et la problématique épineuse de la synchronisation des classpaths. Tout comme Maven, Gradle possède un plugin permettant de générer les fichiers .classpath et .project d’Eclipse. Malheureusement, cette méthode est loin de me convaincre car le véritable besoin dans ce domaine est d’avoir un plugin qui prenne la main sur le système de build natif d’Eclipse au moment de la compilation. L’intégration avec les IDE constitue, à mon sens, l’un des plus gros challenges pour un système de build. Pour l’avoir vécu avec Maven, je suis convaincu que c’est la condition sine qua non pour être en mesure d’utiliser efficacement les mécanismes de déploiement et de test d’Eclipse. En effet, avant l’apparition de plugins Eclipse pour Maven tels que M2Eclipse ou Q4E, il était difficilement envisageable de faire du “hot code replace”, c’est-à-dire de modifier du code à chaud, en phase de debug.
Ces plugins sont également à l’origine d’une réelle intégration de Maven dans Eclipse, autorisant l’usage, de façon transparente, de fonctionnalités telles que le filtrage des ressources. Enfin ils ont apporté un confort considérable en exécutant automatiquement certaines phases du build lors de la modification du POM Maven, et en mettant à jour, par la même occasion, le classpath d’Eclipse.

Quoi qu’il en soit, Gradle apporte sa pierre à l’édifice des problématiques d’assemblage, alors que la communauté Maven est en pleine préparation de sa version 3.0. L’effet ne peut être que positif.

Advertisements