Le projet Maven Daemon vise à augmenter la vitesse des builds Maven en utilisant des techniques connues de Takari et Gradle. Ses concepteurs se sont concentrés sur l'optimisation et les technologies et méthodes de pointe : GraalVM est utilisé à la place d'une JVM, les classes compilées par le JIT sont mises en cache et la création de plusieurs processus si nécessaire.
La version la plus ancienne de Maven que la page d'historique de Maven affiche est la version 1.0-beta-2 du 30/03/2002, il y a presque 19 ans. Maven a apporté un changement de paradigme dans les outils de build de l'écosystème Java : il est passé de l'approche procédurale d'Apache Ant à un modèle déclaratif. En outre, il a évolué vers une manière plus conventionnelle d'organiser un projet, garantissant que les plugins peuvent être réutilisés plusieurs fois. Près de deux décennies plus tard, Apache Maven est le leader des outils de compilation reposnat sur la JVM selon le rapport Snyk's JVM Ecosystem avec une part de 64%. Néanmoins, la complexité et la taille croissantes des projets logiciels d'aujourd'hui, ainsi que la nécessité de déployer plus rapidement, plus souvent et avec une interruption de service minimale, voire aucune, ont fait de la vitesse de build une priorité. Une étude menée par Gradle montre Maven comme étant dans certains cas 100 fois plus lent que les builds exécutés avec Gradle.
Afin de mieux comprendre ce qu'est Maven Daemon et comment nous pouvons en bénéficier, InfoQ a contacté Guillaume Nodet, l'initiateur de mvnd, et Peter Palaga, l'un des principaux contributeurs, pour une série de questions.
InfoQ : Merci d'avoir pris le temps de répondre à certaines questions pour nos lecteurs. Pouvons-nous commencer par vous demander de vous présenter et de décrire votre travail au quotidien et votre rôle dans le développement de mvnd ?
Peter Palaga : je fais partie de l'équipe d'intégration Red Hat et je porte principalement des composants Camel vers Quarkus dans le projet appelé Camel Quarkus. Les outils de build sont mon passe-temps.
InfoQ : Quel était le raisonnement derrière la création de mvnd ?
Peter Palaga : Le build de grandes arborescences de sources (Camel Quarkus a plus de 1200 modules Maven) fait partie de ma routine quotidienne. J'ai été tout de suite excité quand j'ai appris que Guillaume avait un prototype fonctionnel de mvnd. En effet, cela m'a fait gagner beaucoup de temps.
Guillaume Nodet : Au cours des derniers mois, j'ai travaillé à réduire le temps de build du projet Apache Camel. À un moment donné, j'ai dû commencer à creuser dans Maven lui-même pour améliorer sa vitesse. L'idée est née de ce travail d'utiliser une architecture client/serveur pour bénéficier de la mise en cache et du JIT.
InfoQ : Combien de contributeurs travaillent actuellement sur mvnd ? Dans quelle mesure le projet est-il durable ? Comment pensez-vous que la communauté se développera ?
Peter Palaga : Guillaume et moi sommes les principaux contributeurs pour le moment. Nous avons eu quelques contributions de code de la communauté - le package Homebrew de Michael Simons étant le plus important. Une dizaine de personnes regardent notre dépôt GitHub, dont certaines sont actives pour discuter des problèmes et des nouvelles fonctionnalités. Je pense que nous sommes sur la bonne voie pour bâtir une communauté saine.
InfoQ : Pourquoi utiliserait-on le démon ? Quels sont les gains de vitesse lors de son utilisation ?
Peter Palaga : gagner du temps est la raison la plus convaincante de l'utiliser. Les gains de vitesse dépendent du scénario. Lors du build d'un ou deux modules, l'accélération peut être sept, 10 fois ou plus par rapport au stock Maven. Prenons l'exemple de camel-activemq. Il a environ 4060 lignes de code Java, donc ce n'est pas du tout gros. Construire ce module unique avec le stock Maven (mvn install -DskipTests, avec toutes les dépendances en cache dans le référentiel Maven local) prend 5,8 secondes sur ma machine.
La première compilation avec mvnd qui démarre le démon en arrière-plan prend à peu près le même temps. Chaque compilation suivante est beaucoup plus rapide : la seconde ne prend que 0,32 sec (18 fois plus rapide), car le démon est déjà en cours d'exécution, aucun JAR n'a besoin d'être lu à partir du disque, aucun noyau Maven et aucune classe de plug-in ne doivent être chargées. Tout est en mémoire prêt à exécuter la demande de build. Les versions ultérieures peuvent devenir encore plus rapides, car le compilateur Just-In-Time (JIT) de la JVM intervient et optimise le code en fonction des données d'exécution. Dans notre exemple, avec le quatrième build, le temps passe à 0,22 s (26 fois plus rapide).
C'était une question de gain de temps lors de la création d'un petit ensemble de modules. Voyons maintenant comment créer de grands ensembles de modules. Prenons l'exemple de Camel Quarkus avec ses 1242 modules. Le construire avec le stock Maven (mvn clean install -Dquickly, avec toutes les dépendances en cache) prend 2 m 51 s. (L'option -Dquickly désactive les tests, les vérifications de source et d'autres choses qui ne sont généralement pas nécessaires lors de la reconstruction de l'arborescence entière).
Déjà la première compilation avec mvnd (mvnd clean install -Dquickly) est beaucoup plus rapide : 45,9 s (3,7 fois plus rapide). Ceci est dû au fait que mvnd construit les modules en parallèle et au fait que je possède une machine avec 24 cœurs. Cette arborescence de sources particulière permet un degré élevé de concurrence, donc la plupart du temps, le démon peut utiliser tous les cœurs pour construire les différents modules.
Comme nous l'avons vu dans l'exemple précédent, le second build doit être plus rapide, car le démon n'a pas besoin de charger à nouveau ses classes, et le compilateur JIT peut avoir optimisé certains chemins d'accès. Dans le cas de Camel Quarkus, le second build prend 32 sec (5,2 fois plus rapide par rapport à stock Maven). La troisième version est quelques secondes plus rapide en raison d'une compilation JIT plus importante : 29,7 secondes (5,7 fois plus rapide).
InfoQ : Dans quel contexte vous ne recommanderiez pas d'utiliser le démon ?
Peter Palaga : mvnd est principalement conçu pour le développement itératif sur un poste de travail développeur. Je pense que cela vaut la peine de l'essayer en remplacement du stock Maven. En cas de problèmes, les utilisateurs sont invités à les signaler dans le projet. Je vois peu de potentiel pour mvnd dans le domaine de l'intégration continue (CI).
Guillaume Nodet : actuellement, mvnd est lié à Maven 3.6.3, donc si votre build dépend vraiment d'une ancienne version de Maven, cela peut poser quelques problèmes. Le meilleur moyen serait de passer à la dernière version de Maven pour pouvoir tirer parti de mvnd.
InfoQ : Actuellement, mvd est à la version 0.1.0. Est-il suffisamment stable pour être utilisé en production ? Ou est-il toujours en mode d'essai ?
Peter Palaga : Il est assez stable et utilisable dans l'ensemble des scénarios que j'utilise :). Les utilisateurs potentiels sont invités à essayer de voir comment cela fonctionnera pour eux. À en juger par le nombre croissant d'étoiles dans GitHub et de followers sur Twitter, je pense que, mvnd fonctionne bien pour beaucoup.
InfoQ : Quel a été le plus grand défi auquel vous avez été confronté lors du développement du démon ?
Peter Palaga : porter le côté client de mvnd vers GraalVM a été un défi, mais plutôt agréable. Grâce à cela, l'outil de ligne de commande mvnd est un exécutable natif qui rend les builds encore plus rapides, car aucune JVM n'a besoin de démarrer côté client. L'exécutable natif démarre très vite et consomme une fraction de mémoire par rapport à la JVM traditionnelle. Le client mvnd est là pour transmettre la demande de build au démon et présenter les résultats. Vous pouvez voir un enregistrement court de mvnd fonctionnant sur 23 cœurs.
InfoQ : Quelle est la future feuille de route ? À quelle distance êtes-vous d'une version 1.0 ?
Peter Palaga : le plan actuel est d'améliorer l'interface graphique par petites étapes, d'avoir une documentation appropriée (un membre de la communauté a même fait don de mvndaemon.org pour nous!) et catalyser l'écosystème des plugins Maven pour mieux supporter les builds parallèles. Les contributions sont les bienvenues, en particulier demander à quelqu'un de préparer un package Chocolatey pour les utilisateurs de Windows serait bien!
InfoQ : quel est le taux de téléchargement ? Avez-vous des statistiques sur son utilisation ?
Peter Palaga : ce site agrège quelques statistiques de l'API GiHub. Jusqu'à présent, nous avions quelques centaines de téléchargements par version. Ces chiffres doivent couvrir à la fois les téléchargements directs depuis GitHub et les téléchargements via SDKMAN !, Homebrew et les gestionnaires de packages asdf.
InfoQ : Y a-t-il une question que j'aurais dû vous poser, mais je ne l'ai pas fait ?
Peter Palaga : bien sûr qu'il y en a!
InfoQ : Quelle est la relation entre mvnd et le projet ASF Maven ?
Peter Palaga : nous sommes formellement indépendants, ne sous-tendant aucun processus ASF. Cependant, nous veillons à ce que tout notre code soit sous licence Apache et une fois que nous pensons que notre code est suffisamment stable et testé, nous aimerions que mvnd fasse partie du projet ASF Maven.