Gradle, un bel outil
Au travail, j'ai le « bonheur » d'utilisé Ant et son scripting fait de façon manuel et donc assez coûteux. J'ai déjà pu avoir une approche de Maven dont l'idée globale m'avais séduit (gestion de dépendance, projet archetype, …). L'implémentation et la lourdeur m'avais par contre un peu rebuté.
J'ai donc décidé d'approcher Gradle pour voir ce qu'il avait dans les tripes.
Au travail, j'ai le « bonheur » d'utilisé Ant et son scripting fait de façon manuel et donc assez coûteux. J'ai déjà pu avoir une approche de Maven dont l'idée globale m'avais séduit (gestion de dépendance, projet archetype, …). L'implémentation et la lourdeur m'avais par contre un peu rebuté.
J'ai donc décidé d'approcher Gradle pour voir ce qu'il avait dans les tripes.
Kesako ?
Gradle est un outil de gestion de livraison. Son objectif est donc de récupérer les différentes sources, de les compiler, et de packager tout ça en jar, ear, … Bien sur, Gradle ne s'arrête pas là, il vous offre également une gestion de dépendance => Vous indiquez de quelles librairies vous avez besoin, et Gradle vous la récupère ainsi que toutes ses dépendances !
Gradle se veut presque aussi puissant qu'un maven, tout en restant très flexible (presque autant que Ant!)
Utiliser la bête
Attention, je ne compte pas effectuer ici un tutorial complet mais juste vous donnez un aperçu de la bête.
Installation
L'installation de Gradle sur Windows est assez simple : il suffit de télécharger l'archive, de la dezipper, et de rajouter le dossier nouvellement crée dans le Path. Une nouvelle commande sera ainsi à disposition : gradle. Cette commande peut prendre différent paramètre, le plus important d'entre eux correspond à la tache à exécuter :
- gradle build effectuera la compilation, le packaging et les tests
- gradle test se contentera de compiler et de lancer les tests
- gradle assemble fera le package sans tester
Il y a bien sur beaucoup d'autre tache, mais il sera plus rare de les appeler.
Paramétrer un packaging
Bien, mais pour l'instant votre build ne va pas fonctionner. Pourquoi ? Il faut tout simplement donner quelques informations de base en crée un fichier build.gradle.
Il faut tout d'abord associer ce qu'on appelle un plugin. Ce plugin va importer avec lui un ensemble de tâche et de paramétrage. Dans un projet Java, il faut importer le plugin du langage en rajoutant dans le build :
apply plugin: 'java'
Une fois cette simple tâche utilisé, gradle va rechercher vos sources et essayer de les compiler. Par défaut, gradle utilise les dossiers suivants :
- src/main/java
- src/main/resources
- src/test/java
- src/test/resources
Gradle s’attend donc à avoir deux dossiers de sources (test et main) et les fichiers ressources associés. Le modèle est ici le même que celui de Maven. Il est toutefois très facile de modifier l'emplacement des dossiers de cette manière :
sourceSets {
main {
java {
srcDir 'src/'
}
resources {
srcDir 'resources/'
}
}
test {
java {
srcDir 'test/'
}
}
}
Donc ici, Gradle va rechercher les sources et les compiler. Mais qu'en est-il des dépendances ? Il faut également lui préciser. Vous pouvez le faire de cette manière :
compile 'com.sun.faces:jsf-impl:2.0.9',
'com.sun.faces:jsf-api:2.0.9'
runtime 'jstl:jstl:1.2'
testRuntime 'org.apache.geronimo.specs:geronimo-activation_1.1_spec:1.1'
testCompile "junit:junit:4+"
Dans cet exemple, j'ai introduit les 4 niveaux de dépendance standard :
compile quand vous en avez besoin à la compilation runtime quand vous en avez besoin à l'exécution. Inutile ici de remettre ce que vous avez mis en compilation. Les mêmes précéder de test pour tout ce qui concerne vos tests unitaires (junit ou testng)Simple non ?
À noter que dans mon cas, j'ai choisis d'utiliser les repositories maven. J'ai donc rajouter ceci :
repositories {
mavenCentral()
}
Gradle et mes sueurs froides
Histoire de faire simple, je me suis alors lancer dans un build multi-projet J2EE (avec EJB, Web, et Shared) qui avait été construit jusqu'alors par eclipse sans outils de gestion de dépendances. Commencer par ceci pour un premier exercice était sûrement un peu masochiste, mais c'était le meilleur cas pratique que j'avais pour prouver l'utilité de l'outil à mon travail:)
Malheureusement, Gradle est encore jeune et il est difficile de trouver des exemples pour des applications J2EE... Autant dire que paramétrer ce build a été loin d'être simple. Il m'a fallut à peine une soirée pour avoir un projet qui compilait, par contre il m'a fallu plus longtemps pour arriver à le packager correctement.
Après plusieurs heures de recherche, je suis tombé toutefois sur la commande magique :
deploy project(path: ':LissageWEB', configuration: 'archives')
Ce qui est important dans cette ligne est « configuration : 'archives' » qui indique à Gradle que je veux packager le war, et non uniquement un jar qui contient les sources. Malheureusement cette ligne n'est pas dans la documentation (ou en tout cas, je ne l'ai pas trouvé) et il a fallu que je traine sur des forums pour trouver l'origine de mon problème.
Interfacer avec des IDEs ?
Ce point fera l'objet d'un article à part ou j'expliquerai, avec mon cas tordu, comment interface avec les IDEs eclipse et netbeans. Suite donc dans les prochains jours.
Synthèse
|
|
