VT2016 Gradle

=Présentation=
 * Sujet : Gradle et application à eCOM avec Docker Plugin
 * Auteur : Rémi GATTAZ
 * Enseignants : Didier Donsez, Georges-Pierre Bonneau
 * Date : 30/09/2016



=Résumé= Gérer manuellement le cycle de vie d'une application se fait par la répétition d'actions simples. De ce constat, des logiciels appelés moteurs de productions ont été développés. Le premier d'entre eux était Make. Depuis, beaucoup d'autre ont vu le jour et notamment Gradle. Créé en 2007, il est aujourd'hui un des moteurs de production les plus populaires. Conçus pour allier le meilleur de deux alternatives très populaire, Graddle est aujourd'hui présenté comme un logiciel très complet pour gérer le cycle de vie d'un logiciel.


 * Mots-clés : Gradle, Moteur de production, cycle de vie

=Abstract= Handling manually the life cycle of an application is done through the repetition of simple tasks. From that finding, build automation solution were designed. The first of them was Make. Since, many others were created and among them is Gradle. Created in 2007, it has become one of the most used build automation solution. Gradle was desgined to bring the best of two of very popular alternatives while removing their issues, Gradle is considered to be a good solution to handle the life cycle of a software.


 * Keywords : Gradle, build automation, life cycle

=Synthèse=

Moteurs de production
Les moteurs de production sont des logiciels dont le but est principalement d'automatiser la gestion d'un développement logiciel. La compilation, la création de documentation, la gestion de tests automatisés ou encore la publication de livrables sont les actions les plus classiques qui peuvent généralement être automatisées avec ces logiciels. Leurs utilisations permet donc de faciliter le lancement de ces tâches et ainsi d'augmenter la productivité.

Il existe beaucoup de moteur de production. Les plus connus sont les suivants :
 * Apache Ant
 * Apache Maven
 * CMake
 * GNU Make
 * Gradle
 * NMake
 * SCons
 * Waf

Les actions ou tâches qui vont être possible d'effectuer et les langages de développement supportés vont varier selon les moteurs de production.

La configuration de ces actions passe toujours par la modification de fichier de configuration. La syntaxe de ces fichiers va elle aussi changer selon l'outil utilisé. Parmis les modèles les plus répandus se trouvent les fichiers xml et Yaml.

Configuration exemple du moteur Apache Ant tirée du manuel officiel

Gradle
Gradle est un moteur de production crée en 2007 qui se base sur les concepts de Apache Ant et Apache Maven, deux autres moteurs de production. Le projet est née pour apporter la création d'un outil alliant les avantages de ces deux outils tout en essayant de retirer les défauts.

Pour cette raison, Gradle dispose tout comme Maven d'un gestionnaire de dépendance intégré et du concept de convention plutôt que configuration permettant d'obtenir des fichiers de configurations léger. Aussi, Gradle dispose tout comme Apache Ant d'une très forte flexibilité au niveau de l'écriture du fichier de configuration. En revanche, contrairement à Maven et Apache Ant qui utilisent des fichiers de configuration XML dont la structure peut rapidement devenir importante, Gradle utilise des fichiers de configurations dans un langage s'apparentant à Groovy. L'utilisation de ce langage permet de rendre les fichiers de configurations beaucoup moins verbeux et ainsi beaucoup plus clair.

A sa première version, sortie en 2012, le logiciel était uniquement capable de gérer des projets Java, Scala et Groovy et se basait très fortement sur Apache Ant et Maven pour fonctionner. Aujourd'hui en version 3.1, beaucoup des fonctionnalités qui provenaient de Ant et Maven sont maintenant dans le coeur de Gradle. Et puisque le moteur de production a été conçu avec la notion de plugin, il a été très fortement étendue et il peut donc être utilisé pour pratiquement n'importe quel type de projet. Les plugins officiels et de la communauté permettent à Gradle de supporter plus de 60 langages et augmentent très fortement ses capacités.

Le fichier build.gradle
Le fichier build.gradle est l'emplacement principal de la configuration des tâche Gradle. Une tâche gradle étant ce qui est effectué lorsque Gradle est exécuté.

Exemple: Exemple d'un fichier build.gradle minimaliste

Cet exemple est très simple et est tiré d'un projet java avec seulement quelques fichiers qu'il faut mettre dans un jar qu'on rend exécutable en spécifiant le point d'entrée du programme dans le fichier manifest du jar.

Les blocs présent dans l'exemple ne sont pas des tâches. Il s'agit de configurations. Une tâche est décrite selon la syntaxe suivante :

Dans l'exemple, même si aucune tâche n'est spécifié dans ce fichier, les tâches 'build', 'javadoc', 'jar' sont disponibles puisqu'elle proviennent du plugin java.

Ses forces

 * La plus grande force de Gradle provient de son extensibilité. Puisqu'il est basé sur un principe de plugin, la communauté peut proposer ses plugins et les publier sur le site de Gradle afin de les partager. Le nombre de plugins existant n'est pas communiqué mais est important. https://plugins.gradle.org/

https://docs.gradle.org/current/userguide/userguide.html
 * Sa documentation est également très fourni et contient beaucoup d'exemple permettant de comprendre l'outil facilement et ainsi prendre rapidement en main le logiciel.

http://www.slideshare.net/ZeroTurnaround/java-build-tools-part-2-a-decision-makers-guide
 * Selon des tests effectués par Revel Labs en janvier 2014, les performances générales de Gradle sont supérieure à Apache Ant et Maven.

Gradle et docker
Parmi les plugins de Gradle créés et diffusés par la communauté, il existe des plugins pour gérer des images et conteneurs docker. Parmi ceux ci se trouve notamment docker-remote-api, un plugin se trouvant dans le pack [gradle-docker-plugin https://github.com/bmuschko/gradle-docker-plugin].

Ce plugin a été conçu pour permettre la gestion de conteneurs et d'images docker depuis Graddle. Ainsi, avec ce plugin, il est possible de créer des images et de les exécuter pour obtenir des environnement de développement, de tests et production. Utiliser ce plugin permet ainsi de contrôler les environnements utilisés et ainsi permettre leurs harmonisations pour que les environnements finaux (de production) soit les plus proches possibles de ceux de test et de developpement.

Gradle, docker et le projet eCOM
Dans le cadre du projet eCOM, il est imposé de créer une application Java EE qu'il faut packager dans un fichier .ear qui doit être publié sur un serveur compatible tel que GlassFish ou WildFly.

Pour suivre cette consigne, il est possible de générer un fichier .ear puis de manuellement le déployer sur un serveur. Il est également possible de le publier directement avec Gradle en précisant dans le fichier de build.gradle l'adresse du serveur et les identifiants nécessaire.

Une dernière solution, qui va être détaillé ici, est d'utiliser docker avec Gradle afin de produire une image Docker contenant l'application complète. C'est à dire le serveur d'application java et le fichier .ear qui est produit. Au cours du développement de cette application, il est alors possible d'utiliser cette image pour tester l'application eCOM et éventuellement la déployer en production.

Architecture
Le plugin docker-remote-api qui va être utilisé pour construire l'image docker peut être utilisé avec un fichier Dockerfile ou en définissant dans le fichier build.gradle les éléments du fichier qui est alors généré dynamiquement.

Pour faciliter ce cas d'utilisation et limiter le contenu du fichier build.gradle, nous allons créer un fichier Dockerfile et le placer dans le dossier docker situé à la racine du projet.

DockerFile
La première chose à définir est le choix du serveur. Puisque l'image docker du serveur GlassFish est très mal supporté et qu'elle a été déprécié, l'utilisation de WildFly est préféré.

La construction de l'image WildFly dans lequel un fichier .ear est déployé est simple puisqu'il suffit de déposer un fichier .ear dans le dossier /opt/jboss/wildfly/standalone/deployments/ de l'image. Le fichier Dockerfile faisant cette création est donc le suivant : Notons toutefois qu'il faut avoir accès au fichier .ear dans le dossier Docker

Ajout de la configuration gradle
Voici la configuration nécessaire à mettre en place pour construire l'image docker.

La tâche copyBuildRes permet de copier le fichier myApp.ear construit par Graddle dans le dossier docker. Ainsi, le fichier Dockerfile aura accès à l'ear.

Build
Une fois ces fichiers mis en place, la tâche buildImage permet de construire l'image Docker de l'application eCOM.

=Bibliographie=
 * https://gradle.org/
 * https://docs.gradle.org/current/userguide/ear_plugin.html
 * https://github.com/gradle/gradle/tree/master/subprojects/docs/src/samples
 * https://github.com/bmuschko/gradle-docker-plugin
 * https://hub.docker.com/r/jboss/wildfly/