Création d'un plugin Gradle – Part 1

Gradle est un système de build à base de plugins. Chaque plugin apporte un ensemble de conventions et le traitement nécessaire à l’exécution de la chaîne de build. En dehors des plugins Gradle core comme java, groovy, ant, maven, jetty, …, vous pouvez avoir le besoin de créer votre propre plugin.
Cette fonctionnalité n’est actuellement pas documentée, et une série de billets sur ce sujet va vous montrer pas à pas la création d’un plugin avec un cycle de vie.

Première étape

Nous allons créer notre projet plugin et le builder avec Gradle lui-même. Nous allons utiliser une structure groovy conventionnée par Gradle (l’utilisation d’une structure Groovy au lieu d’une structure Java sera expliquée dans les prochains billets).

 firstplugin +-- build.gradle +-- libs +--- gradle-0.6.jar +--- groovy-all-1.5.6.jar +--- slf4j-api-1.5.3.jar +-- src/main/groovy/com/zenika/plugins/FirstPlugin.java

Nous définissions notre script Gradle build.gradle comme suit

  1. usePlugin(‘groovy’)
  2. version=1.0
  3. repositories {
  4. flatDir(dirs: file(‘lib’))
  5. }
  6. dependencies {
  7. groovy « :groovy-all:1.5.6 »
  8. groovy « :gradle:0.6 »
  9. groovy « :slf4j-api:1.5.3 »
  10. }

Notre plugin est pour le moment constitué d’une classe FirstPlugin.java. Voici son contenu

  1. package com.zenika.gradle.plugins;
  2. import org.gradle.api.*;
  3. import org.gradle.api.Plugin;
  4. import org.gradle.api.Project;
  5. import org.gradle.api.internal.project.PluginRegistry;
  6. import java.util.Map;
  7. public class FirstPlugin implements Plugin {
  8. public void apply(Project project, PluginRegistry pluginRegistry, final Map<String, ?> customValues) {
  9. System.out.println(« Hello World! »);
  10. }
  11. }

Il nous reste plus qu’à compiler et à packager notre plugin

gradle clean libs

Deuxième étape.

Après avoir construit notre plugin, il nous faut le déclarer pour l’utiliser dans notre projet Gradle. Il faut tout premièrement
créer un fichier « settings.gradle » avec le contenu suivant

  1. flatDir(dirs:« C:/dev/gradle/firstplugin/build/libs »)
  2. dependencies(« :firstplugin:1.0 »)

Nous déclarons une dépendance vers notre plugin Gradle.
Note: dans le cadre de ce billet, nous avons choisi d’utiliser directement le plugin à l’emplacement où il a été construit. En production, la mise à disposition du plugin dans une infrastructure d’entreprise comme dans un gestionnaire de repository Nexus sera plus judicieuse.
Ensuite dans le descripteur Gradle de notre projet, il nous reste à déclarer son utilisation

  1. usePlugin(com.zenika.gradle.plugins.FirstPlugin)
  2. task test <<{
  3. println « Testing plugin »
  4. }

Nous ajoutons une tâche fictive « test » pour pouvoir l’invoquer et le tester. En effet, pour le moment, notre plugin ne définit pas de tâches Gradle, et toute invocation de plugin doit être démarrée par l’exécution d’au moins une tâche Gradle.
Nous exécutons

gradle test

et le résultat est

 Hello World! :test Testing plugin

Remarque: La présence du fichier « settings.gradle », comparée à un plugin core, peut paraître un peu lourde pour la prise en compte d’un plugin utilisateur. Les prochaines versions de Gradle ne manqueront sûrement pas d’améliorer ce point.
Note: Si vous déployez votre plugin avec le code de la distribution, la déclaration de la dépendance vers le plugin Gradle n’est pas necessaire. Et vous pourrez aussi, utiliser un shortcut grâce au fichier « plugin.properties » avec un contenu comme ceci

  1. java=org.gradle.api.plugins.JavaPlugin
  2. groovy=org.gradle.api.plugins.GroovyPlugin
  3. war=org.gradle.api.plugins.WarPlugin
  4. osgi=org.gradle.api.plugins.osgi.OsgiPlugin
  5. jetty=org.gradle.api.plugins.jetty.JettyPlugin
  6. maven=org.gradle.api.plugins.MavenPlugin
  7. projectreports=org.gradle.api.plugins.ProjectReportsPlugin
  8. ant=org.gradle.api.plugins.ant.AntPlugin
  9. firstplugin=com.zenika.gradle.plugins.FirstPlugin

Conclusion

Nous savons maintenant créer un nouveau plugin Gradle. Dans les prochains billets, nous verrons les différentes manières de passer des propriétés à un plugin, puis nous verrons comment définir des tâches et des dépendances entre ces tâches afin de constituer un cycle de vie.

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

%d blogueurs aiment cette page :