Des builds incroyablement rapide avec Gradle 3
Par Cédric CHAMPEAU (@CedricChampeau) - Gradle
Commençons par quelques news :
-
Gradle 3 est disponible (version 3.2 sortie le 2016/11/14)
-
Gradle 4 est prévu pour début 2017
Gradle (3.x) se définit maintenant par :
-
un outil de build : celui que vous récupérez de https://gradle.org/
-
des services en ligne (Gradle Cloud Services) (faut bien manger !) : accessibles depuis https://gradle.com/
Les forces de Gradle 3
Gradle Daemon
-
Beaucoup plus stable depuis la version 3 (plus de lock sur le rep
build! On va enfin pouvoir le supprimer sans avoir besoin de redémarrer…) -
Après quelques run (merci le JIT), on gagne plus de 50% de temps de build.
Outils de profiling
-
gradle --profile: l’historique, avec déjà quelques infos, mais limitées et difficilement partageables -
service en ligne : build scans
Le nouvel outil, cloud, bien plus performant. Voir https://scans.gradle.com/s/ly5tnqtuoqlwe ou https://scans.gradle.com/s/mltba5qnktegg pour des exemples de build scan.
Pour l’utiliser, il faut ajouter le plugincom.gradle.build-scanà sonbuild.gradle, et builder avec-Dscan.
Les données d’analyse sont collectées au cours du build, PUIS envoyées en 1 fois au service dans le cloud.
Pour celles ou ceux qui renaclent à aller sur le cloud, il est toujours possible d’installer ces services sur un serveur en interne.
Voici quelques exemples de build scans :
Builds incrémentaux
Gradle permet de redéfinir les entrées / sorties de toutes les tâches (@InputFile et @OutputFile), ce qui lui permet de gérer des builds incrémentaux :
-
Si la tâche n’a pas encore donné d’output, c’est donc qu’il faut la lancer.
-
Si, par contre, un output existe, et que les entrées sont les mêmes, cette tâche n’a pas besoin d'être relancée.
Compilation incrémentale
Ce type de compilation est disponible (un peu comme sous Eclipse).
Gradle connaissant toutes les dépendances entre classes, il peut donc l’utiliser, contrairement à javac.
Et, même si encore expérimentale, elle est stable et permet des gains de performance non négligeables.
Elle s’active via la configuration de la task JavaCompile:
apply plugin: 'java'
compileJava {
//enable incremental compilation
options.incremental = true
}Continuous build
Ce type de build écoute en continue les changements dans les inputs des tasks.
Activable avec l’option -t. Exemple :
Gradle -t AsciidoctorDans l’exemple précédent, utilisé par Cédric pour builder les slides de sa présentation, le code Asciidoctor de la présentation est, à chaque modification, rebuilder pour générer la nouvelle version des slides.
Composite build : la killer feature de Gradle
Pour Cédric, il s’agit de LA killer feature de Gradle 3.x.
Quelques rappels :
-
mono-repo : 1 repo Git, et plein de sous-projets dedans
-
Avantage : on dispose de tout le code au même endroit, ce qui est pratique pour le débuggage
-
Inconvénient : il n’est pas toujours possible de charger tout le mono-repo dans son IDE…
-
-
multi-repo : 1 projet PAR module
Nous n’avons donc que des dépendances binaires avec nos modules.
Problème : Lorsqu’il y a un changement dans un module, il faut faire un checkout du projet associé, recompiler, rebuilder, republier,etc. Bref, pas ce qu’il y a de plus pratique.
Les composite builds vont permettrent de réunir ces 2 mondes, en nous gardant que les avantages.
Implications :
-
permet de substituer une dépendance binaire par une dépendance source.
Un énorme avantage pour débugger une dépendance problématique.
C’est également valable aussi pour les dépendances transitives.
Et, grâce à l’utilisation du graphe de dépendances de Gradle, il s’agit bien d’une substitution de dépendances, et non d’un simple remplacement.
Si le graphe de dépendances de la dépendance source est différent de celui de la dépendance binaire, c’est bien ce nouveau graphe qui est pris en compte. -
permet de splitter un build multi-projets en plusieurs morceaux (exploser un monolith en multi-modules)
On peut ne travailler avec le source que des projets qui nous intéressent, et garder le binaire pour les autres.
Les builds multi-modules se déclare soit via le fichier settings.gradle, soit en utilisant le flag --includeBuild.
Voir https://docs.gradle.org/current/userguide/composite_builds.html pour plus d’informations.
Task output cache (pour Gradle 4)
Même après un clean, j’ai pas envie de faire le boulot 2 fois…
Pour partager le résultat d’un build sur le réseau.
Ainsi, le voisin ne perdra pas 25 min de build à récupérer tous les modules dont vous vous êtes déjà chargés ; il n’aura plus qu'à les récupérer du cache.
Sympa d’un point de vue GreenIT car moins de compilation / build.
Ma conclusion
On sent bien au travers de la présentation de Cédric que Gradle continue de s’améliorer, et a peut-être même franchi un cap.
L’arrivée des services en ligne (build scans), et l'accent général mis sur la performance (jetez vraiment oeil au performance guide) montre bien cette volonté de Gradle de faire passer nos builds eux-mêmes dans l’aire de l’industrialisation, et de les rendre "rock-solid".
Pour finir, un schéma comparant les temps d’exécution d’un gradle clean test vs un mvn clean test :
Ressources
-
Vidéo de la présentation : https://www.youtube.com/watch?v=eMk685z0B1E
-
Slides et code de la présentation : https://github.com/melix/parisjug-fast-builds
-
La documentation de Gradle : http://gradle.org/documentation
-
Le performance guide de Gradle : https://gradle.github.io/performance-guide/
-
Cet article de Cédric, sur la blog Gradle, lui aussi dédié à la performance de l’outil : https://gradle.org/blog/performance-is-a-feature/
JEE quoi de neuf ?
Par Charles SABOURDIN et José PAUMARD
Charles et José nous proposent un retour sur les annonces de JavaOne et Devoxx BE concernant JEE, étant donné que la technologie avait souvent été décriée ces derniers temps ("JEE c’est mort…").
Ils nous explique que, malgré tout ce qui est dit :
-
la communauté JEE est et reste (très) grande
-
nombreuses sont les JSRs JEE8 qui avancent bien
-
de nombreux livres et ressources existent sur le sujet, régulièrement remis à jour
De plus, sur 450 présentations à JavaOne, plus de 50 portaient sur JEE. Pas mal pour une technologie "morte"…
Pour rappel, voici le contenu de JEE 7 :
Et voici où nous en sommes pour JEE 8 :
On note que :
-
JCache n’avance pas des masses (toute une histoire)
-
JSONB, le binding pour JSON, est très fortement demandé
Charles et José nous mettent également un petit peu en garde contre le mouvement "JEE Guardians", avant tout poussé par son fondateur, un ancien évangéliste JEE (récemment viré par Oracle comme la plupart de leurs évangélistes…), qui n’est pas forcément objectif à 100%.
Concernant la roadmap à venir, les sorties de JEE 8 et 9 vont être très proches (quelques mois d'écard) :
On note que l’on commence à avoir un grand écart entre les JEE et les JSE (grosse désynchronisation).
Un rappel général sur la philosophie de JEE : regrouper ce qui marche bien, pour proposer un standard, dans cet ordre (exemple avec Hibernate et CDI).
C’est pour ainsi dire un organe "en retrait" plutôt qu'à la pointe du progrès.
Ressources
-
vidéo de la présentation : https://www.youtube.com/watch?v=ZimyehjAl5s