mai
2009
Utiliser Gradle pour télécharger des librairies
Après les billets expliquant comment télécharger un ensemble de librairies dans un répertoire local avec Maven puis avec Ant et Ivy, voici comment faire la même chose avec Gradle (merci à Grégory Boissinot pour ses explications).
Alors, j'ai une bonne et une mauvaise nouvelle.
La mauvaise, c'est que Gradle ne permet pas de le faire nativement.
La bonne, c'est qu'il y a moyen de ruser pour obtenir le résultat voulu, en combinant le cache local d'Ivy et une tâche Ant pour en extraire les librairies souhaitées. On a eu chaud.
Sans plus attendre, voici la solution.
Quelques explications pour les non-gradeliens :
- Les lignes 1 à 3 autorisent Ivy à utiliser les repositories Maven pour la recherche et la récupération des artefacts.
- Les lignes 5 à 9 définissent une configuration Ivy, c'est-à-dire un ensemble cohérent de dépendances...
- ...qui sont définies aux lignes 11 à 13
- Et enfin, le coeur du script : l'appel de la tâche Ant "copy" pour extraire les librairies du cache local et les copier dans le répertoire voulu, ici "lib".
Vous me direz que cela fait beaucoup de configuration juste pour récupérer quelques dépendances. Mais en y regardant de plus près, seule la dernière étape ne fait pas partie d'un build Gradle typique.
La seconde objection serait que cette solution télécharge d'abord les librairies dans un cache local, ce qui "pollue" inutilement la machine. Certes, mais on retrouve ici ni plus ni moins les inconvénients de Maven. En revanche, comparez la verbosité des scripts et vous comprendrez pourquoi Gradle a un bel avenir devant lui.
Commentaires
Je rêve ou la dernière étape est écrite avec une closure ? Serais-tu devenu un converti, Olivier ? Je croyais que tu les considérais comme peu lisibles ?
Je ne suis pas contre le principe des closures, bien au contraire. C'est plus léger et lisible que les classes anonymes. Et on doit pouvoir leur trouver des usages plus puissants également.
Ce que j'aime moins, c'est leur syntaxe radicalement différente de celle du reste du programme... En particulier, le fait que la dernière expression évaluée soit "magiquement" retournée me dérange, de même que la petite flèche pour séparer les arguments du code. Pourquoi ne pas passer les arguments entre parenthèses comme d'habitude, et utiliser "return" pour renvoyer explicitement une valeur ?
De même, comment les exceptions sont-elles déclarées et gérées ?
Si chacun réinvente sa propre syntaxe dans son coin, on n'est pas sortis de l'auberge...
Juste une petite remarque, une closure a toujours au moins un argument implicite it qui sera disponible dans le corps de la closure. On peut l'utiliser si aucun paramètre explicite n’est défini.
Nous aurions donc pu avoir dans notre exemple
task retrieveJars << {
configurations.jars.each { ant.copy(file: it, todir:'lib') }}
Désormais l’utilisation de la tâche copy de Ant est déprécié au profit de la tâche Copy de Gradle. Celle-ci fournit une API plus riche (inclusions et exclusions fine de fichiers, filtering, changement de noms des fichiers, …).
Ainsi, si vous utilisez la dernière monture de Gradle (v0.7), il est préférable d’écrire la tâche de récupération des librairies comme ci-dessous:
task retrieveJars << {
copy {
from configurations.jars
into new File('lib')
}
}
ou comme ceci:
task(retrieveJars, type: Copy) {
from configurations.jars
into new File('lib')
}