Le plugin Gradle de Hudson s’améliore
Nous venons de releaser la version 1.2 du plugin Gradle pour le moteur d’intégration continue Hudson.
Parmi les nouveautés, on peut noter:
- Distinction plus claire entre la notion de switches et de tasks Gradle
- La possibilité de spécifier un script de build situé dans un niveau de l’arborescence du workspace Hudson
- Une aide utilisateur améliorée
Fonctionnement du plugin
Le plugin fonctionne comme l’intégration du builder ANT. Il suffit simplement de spécifier les switches et les tasks Gradle, c’est a dire l’équivalent des options et des cibles ANT (targets).
Si vous avez plusieurs installations de Gradle et que vous souhaitez choisir pour un projet la configuration Gradle qui sera utilisé; ou que tout simplement dans le cas où l’outil Gradle n’est pas dans le PATH
Le pourquoi d’un plugin Gradle ?
Hudson supporte un certain nombre de type de build comme Ant, Maven. Il supporte également l’exécution de scripts shell ou de scripts batch Windows permettant d’invoquer tout type de commande.
En Gradle, le dossier qui contient le script Gradle définit un projet Gradle. Sans surcharge, le nom du projet sera le nom du dossier conteneur (il s’agit d’une particularité que nous ne retrouvons pas dans les autres systèmes de build comme Maven). Dans ces conditions, les chemins relatifs qui seraient invoqués en dehors du dossier projet vont échouer. Ce problème peut être résolu facilement par l’invocation de la commande “cd” avant d’invoquer Gradle. Nous obtenons la configuration suivante
On voit alors que cela n’est pas pratique et peu maintenable.
Les futurs évolutions
Dans les prochaines versions, il est prévu d’ajouter la prise en compte d’un projet multi module. L’objectif est de fournir une intégration similaire à l’actuelle intégration de Maven (navigation par module, segmentation des logs, personnalisation de la chaîne de build par module). L’autre axe d’amélioration est une gestion assistée du système de niveau des traces (logging).