Points Clés
- JReleaser a l'intention de rationaliser le processus de publication et de publication des binaires Java de manière à ce que ces binaires puissent être consommés par des gestionnaires de packages spécifiques à la plate-forme (fichier ZIP, TAR ou JAR).
- JReleaser vous permet de publier des binaires sur Homebrew, Scoop, Snapcraft, Chocolatey, entre autres.
- La publication avec JReleaser garantira la création du journal des modifications à partir de la balise la plus récente, le calcul des sommes de contrôle, la signature PGP si la signature est activée, la création et la publication d'images Docker basées sur le fichier Docker créé selon les modèles fournis.
- JReleaser peut être utilisé directement avec Maven, Gradle, Bach et Ant. Pour ceux qui utilisent des outils de construction personnalisés, JReleaser expose sa propre interface ToolProvider, ce qui la rend simple à intégrer. C'est exactement ce que fait l'outil de construction Bach aujourd'hui.
Quel que soit le type de projet que vous écrivez, qu'il s'agisse d'une application en microservices, d'une application mobile ou même d'applications natives, vous devez vous assurer que votre code est correctement conditionné et distribué via les canaux appropriés pour atteindre son public. Actuellement, les services poussent à avoir des temps de développement aussi courts que possible et à toucher un public aussi large que possible.
Andres Almiray, principal product manager chez Oracle, avait pour objectif d'apprendre le langage de programmation Go. Cela l'a amené à découvrir GoReleaser, un outil d'automatisation des versions pour les projets Go, et l'impact qu'il avait sur l'écosystème Go. Andres Almiray s'est également inspiré d'une discussion avec Max Raydahl Andersen, distinguished engineer chez Red Hat, sur la manière dont JBang a géré ses versions. Ces expériences ont conduit au concept de JReleaser, un outil de construction et de distribution pour l'écosystème Java similaire à ce que GoReleaser a fait pour l'écosystème Go. Après seulement quelques mois de développement, Andres Almiray a présenté JReleaser à la communauté Java en avril 2021. Depuis lors, Andres Almiray a publié trois versions (une toutes les deux semaines et gérée par JReleaser lui-même) qui se situe actuellement à la version 0.4.0. Des versions plus récentes ont contribué à rendre JReleaser encore plus polyvalent en assurant la prise en charge du Java Runtime pour MacOS, Windows, Linux (glibc) et Linux (musl) communément appelé Alpine Linux. JReleaser actuellement s'intègre avec 14 outils CI et il offre la possibilité de télécharger des artefacts sur le Gestionnaire de référentiel Artifactory de JFrog et serveurs HTTP personnalisés.
Pour mieux comprendre la mission de JReleaser et comment il peut faciliter la vie des développeurs de logiciels, InfoQ a contacté Andres Almiray pour en savoir plus sur ce que c'est et comment il peut fournir un moyen plus simple de gérer des projets Java.
InfoQ : Merci d'avoir pris le temps de répondre aux questions de nos lecteurs. Quelles sont vos responsabilités au quotidien actuellement ? Existe-t-il un lien entre votre travail quotidien et JReleaser ?
Andres Almiray : Merci de m'avoir reçu. Je suis senior principal product manager au sein de l'Oracle’s Database group, ce qui peut être une nouvelle choquante pour certains car j'ai une expérience professionnelle avec Java au cours des 25 dernières années ; Je suis même devenu membre du programme Java Champions en 2010. La raison pour laquelle j'ai rejoint le groupe Database est de continuer à construire des ponts entre les produits de base de données Oracle et la communauté Java, et à ce titre, je me fais un devoir de garder un œil sur les projets open-source, parler aux développeurs et rapporter ces précieux commentaires à nos équipes internes. En passant, je continue également à travailler sur des projets open source dans lesquels j'ai été impliqué pendant des années avant de rejoindre Oracle pour la deuxième fois. JReleaser se trouve être l'un de ces projets open source nés de la nécessité de maintenir d'autres projets à jour. Cela étant dit, il n'y a pas de relation directe entre mon travail actuel et JReleaser autre qu'il est écrit en Java et que j'utilise Java au travail.
InfoQ : Quelle a été l'inspiration pour JReleaser et comment avez-vous commencé ?
Andres Almiray : il y a des années, j'ai publié un projet open source appelé Ikonli qui se trouve être assez populaire dans l'espace JavaFX. Ce projet fournit des icônes qui peuvent être intégrées dans une application Swing ou JavaFX. Au fil du temps, le nombre de packs d'icônes augmentait, ce qui rendait difficile la détermination des icônes pouvant être ajoutées à une application. Ikonli fournit une documentation HTML avec des icônes aide-mémoire, mais j'avais envie d'une application qui ferait la même chose, un navigateur d'icônes, si vous voulez. Construire une telle application avec JavaFX est assez simple, mais la rendre accessible à tous est la partie délicate. Comment conditionner et publier une application qui nécessite des binaires spécifiques à la plate-forme ? Pensez-vous que l'utilisateur disposera de la bonne version de Java pour exécuter l'application ? Regroupez-vous un Java Runtime avec les binaires ? Est-ce suffisant de publier des fichiers ZIP ou les gestionnaires de packages de plate-forme sont-ils mieux adaptés ? J'ai continué à chercher des réponses à ces questions lorsque je suis tombé sur deux autres projets : JBang et GoReleaser.
JBang est un projet basé sur Java qui est conditionné pour plusieurs canaux de distribution tels que Homebrew, Scoop, Chocolatey, Docker, etc. Cela résout en quelque sorte la plupart des questions que j'avais avec Ikonli, mais l'automatisation de la construction nécessite un certain travail car la configuration nécessite beaucoup d'efforts pour être appliquée à un autre projet. En d'autres termes, la configuration est unique aux besoins de JBang. GoReleaser, en revanche, fournit exactement ce que je cherchais, sauf qu'il ne fonctionne que pour les projets Golang.
Un après-midi, Max Andersen (créateur de JBang) et moi parlions de la configuration des builds, des versions et d'autres trucs de geek quand nous avons compris : et s'il existait une version Java de GoReleaser ? C'est-à-dire un outil qui vous permettrait de packager, de livrer et de publier des projets Java de la même manière que GoReleaser le fait pour Golang, mais qui prendrait plutôt en charge Java ? Et si cet outil s'appuyait sur les leçons apprises par JBang pour en arriver là où il en est aujourd'hui ? Et c'est ainsi que JReleaser est né.
InfoQ : Quelle est sa mission ? Pour quel type de projets est-il conçu ?
Andres Almiray : la mission initiale de JReleaser est de rationaliser le processus de livraison et de publication des binaires Java de manière à ce que ces binaires puissent être consommés par des gestionnaires de packages spécifiques à la plate-forme, c'est-à-dire fournir un fichier ZIP, TAR ou JAR. JReleaser s'occupera du reste, vous permettant de publier des binaires sur Homebrew, Scoop, Snapcraft, Chocolatey, etc. En d'autres termes, JReleaser raccourcit la distance entre vos binaires et vos consommateurs en les rencontrant là où ils préfèrent gérer leurs packages et binaires.
Au début de la conception de JReleaser, il est devenu évident que diviser le travail en plusieurs étapes pouvant être invoquées, individuellement ou comme une seule unité, serait une meilleure approche que ce que GoReleaser propose aujourd'hui. Ce choix de conception permet aux développeurs de microgérer chaque étape selon les besoins pour accrocher JReleaser à un point spécifique de leur processus de publication sans avoir à tout réécrire. Par exemple, vous pouvez lancer JReleaser et lui faire créer une version Git (GitHub, GitLab ou Gitea) avec un journal des modifications formaté automatiquement, ou vous pouvez dire à JReleaser d'ajouter des actifs à une version Git existante qui a été créée par d'autres moyens, ou peut-être êtes-vous uniquement intéressé par l'empaquetage et la publication d'un package sur Homebrew, quelle que soit la façon dont la version Git a été créée.
La possibilité d'invoquer des étapes, individuellement ou dans leur ensemble, vous donne suffisamment de latitude pour jouer. Et pas seulement cela, il vous donne également la possibilité d'appliquer JReleaser à tout type de projet, pas seulement aux projets Java. Par exemple, vous pouvez l'utiliser pour créer des versions pour Git, que le projet soit basé sur Java ou non ; vous pouvez également configurer JReleaser pour qu'il s'exécute sur n'importe quel logiciel CI existant.
Bien sûr, si le projet est basé sur Java, vous bénéficiez d'avantages supplémentaires car la gestion des packages est actuellement spécialisée pour ce type de projet. Il va sans dire que si le projet est basé sur Golang, il est préférable de s'en tenir à GoReleaser car il offre des fonctionnalités spécifiques à Golang que JReleaser ne propose pas.
En résumé, tout projet souhaitant créer et diffuser des releases Git bénéficiera de JReleaser. S'il s'agit d'un projet Java, il bénéficie d'avantages supplémentaires. Les applications CLI telles que celles implémentées avec PicoCLI, Micronaut, Quarkus ou Spring Boot peuvent certainement tirer parti de ces avantages supplémentaires. Il va également sans dire que les applications JavaFX bénéficient également d'un coup de pouce.
InfoQ : Vous pouvez facilement imaginer comment JReleaser pourrait être utilisé pour des projets open source. Qu'est-ce qui serait différent dans les projets privés ?
Andres Almiray : Content que vous ayez posé la question. Je suis heureux de dire qu'il n'y a aucune différence du tout. JReleaser peut être personnalisé pour prendre en charge les versions d'entreprise du logiciel de release Git de votre choix. Sa documentation suggère l'utilisation de licences approuvées par OSI et d'identifiants SPDX car ceux-ci sont requis par des gestionnaires de packages spécifiques, cependant JReleaser ne valide pas ces licences. Vous pouvez utiliser n'importe quel système de licence requis par le projet. JReleaser prend également en charge une large gamme de services CI, ne faisant aucune distinction entre leurs offres gratuites et payantes.
Info : JReleaser compte-t-il sur lui-même pour gérer ses propres versions ?
Andres Almiray : Oui ! Depuis la première version, JReleaser a été publié en utilisant une version instantanée de lui-même. En fait, la version de JReleaser est configurée de manière à produire des versions à accès anticipé à chaque push vers son référentiel Git. Ces versions à accès anticipé sont créées avec la version instantanée précédente de JReleaser, Inception.
InfoQ : Recommanderiez-vous aux développeurs d'adopter JReleaser ? Ou devons-nous procéder avec prudence ?
Andres Almiray : JReleaser s'appuie sur les leçons apprises par GoReleaser, JBang et tous les autres projets open source avec lesquels j'ai travaillé dans le passé. Il y a beaucoup d'histoire là-dedans malgré le fait que la base de code soit relativement jeune en comparaison. Étant donné que JReleaser s'utilise lui-même pour la publication, cela signifie que nous pouvons détecter les problèmes dès le début du développement. Bien sûr, d'autres projets ont des besoins différents et c'est là que nous puisons l'inspiration pour de nouvelles fonctionnalités et comportements. J'encourage certainement les autres à essayer. Ne vous laissez pas berner par son numéro de version actuel, JReleaser a du punch !
InfoQ : Pouvez-vous nous donner quelques conseils pour démarrer rapidement ?
Andres Almiray : le meilleur endroit pour commencer est peut-être de consulter les Guides de démarrage rapide, puis procédez à la configuration via DSL et à certaines des exemples trouvés dans le guide. J'aime les conventions plutôt que la configuration, donc j'aime quand un outil fait la plupart des choix pour moi. Cependant, j'aime aussi quand je peux faire mes propres choix et conventions. Pour cette raison, JReleaser prend en charge plusieurs façons de se configurer : vous pouvez utiliser des DSL externes avec les formats YAML, TOML ou JSON lors de l'exécution en mode CLI ; ou vous pouvez utiliser le Maven DSL associé au jreleaser-maven-plugin ; ou le Gradle DSL associé au jreleaser-gradle-plugin.
InfoQ : Y a-t-il des limitations avec JReleaser ?
Andres Almiray : Oui, en particulier en ce qui concerne la prise en charge de plusieurs plates-formes. Certains conditionneurs, tels que Snapcraft et Chocolatey, doivent s'exécuter sur des environnements très spécifiques ; Linux pour le premier et Windows pour le second. Cela signifie que vous ne pouvez pas packager les deux sur le même nœud. Il en va de même pour les binaires GraalVM Native Image, un type de distribution que JReleaser prend également en charge, car il n'existe actuellement aucun moyen de générer des binaires multiplateformes. JReleaser est capable de générer des runtimes Java multiplates-formes avec Jlink tant qu'il n'y a pas de modules spécifiques à la plate-forme. Cela entrave la création de ces environnements d'exécution pour les applications JavaFX car ils nécessitent des modules macOS, Linux ou Windows.
La solution de contournement actuelle consiste à créer des packages et des distributions spécifiques à la plate-forme dans différents nœuds CI, à collecter les résultats et à les publier à partir d'un seul nœud. Ainsi, en fonction de votre configuration, vous pouvez créer des versions à la fois localement et à distance avec la même configuration (pas de packages spécifiques à la plate-forme, par exemple) ou vous pouvez avoir besoin d'une configuration supplémentaire et de serveurs de build pour construire les binaires, perdant ainsi la possibilité de créer des versions localement.
InfoQ : Pouvez-vous nous faire un tour rapide de ce qui se passe sous le capot ?
Andres Almiray : étonnamment, ce qui anime le moteur JReleaser est un processeur de fichier template. Un développeur fournit la configuration du projet en entrée (le modèle) qui est traitée à chaque étape du workflow de publication. La plupart des étapes prennent cette entrée et génèrent des fichiers basés sur des modèles, qui à leur tour sont également utilisés comme entrées pour l'étape en cours ou la suivante. Par exemple, le modèle définit une distribution de type JAVA_BINARY (typiquement un fichier ZIP avec des fichiers JAR et un lanceur d'exécutable) et active le packager Docker. L'appel de l'étape de publication effectuera les tâches suivantes :
- Créer un changelog depuis la balise la plus récente jusqu'au HEAD actuel.
- Calculer les sommes de contrôle sur la distribution d'entrée.
- Créer des signatures PGP si la signature est active.
- Créer un fichier Docker sur la base des modèles fournis.
- Créer une image Docker basée sur le fichier Docker résolu.
- Publier l'image Docker sur le(s) serveur(s) configuré(s).
Le modèle fournit un bon nombre de valeurs par défaut sensibles et vous oblige à modifier les fichiers générés. Mais au cas où cela ne suffirait pas, vous pouvez également fournir vos propres modèles, remplaçant ou complétant ceux par défaut.
InfoQ : Quel a été le plus grand défi technique auquel vous avez été confronté lors du développement de JReleaser ?
Andres Almiray : Je pense que cela permettrait de maintenir le nombre de dépendances aussi bas que possible, ainsi que d'établir Java 8 comme version Java minimale prise en charge. Pourquoi donc ? Cela permet de prendre en charge l'exécution de JReleaser en tant que plug-ins Ant, Maven et Gradle. J'aimerais passer à Java 11, adopter pleinement le système de module Java et accéder aux fonctionnalités plus récentes ajoutées au langage Java. Cependant, bien jouer avec tous les outils de construction nécessite des compromis.
InfoQ : Comment s'intègre-t-il dans les pipelines CI ?
Andres Almiray : il existe actuellement deux moyens simples d'y parvenir. Vous pouvez soit lancer JReleaser en tant que processus Java, soit utiliser son image Docker.
La première forme est ce que fait l'action jreleaser/release-action GitHub. Il télécharge une version (configurable) de JReleaser en un seul überjar et exécute sa classe principale. Cela nécessite un Java Runtime sur le nœud cible, dans ce cas un Runtime Java 11 pour être précis, car l'überjar lance une instance de ToolProvider.
La deuxième forme regroupe un environnement d'exécution Java et les binaires JReleaser sous forme d'image Docker, vous permettant de l'utiliser avec n'importe quel serveur CI pouvant exploiter des images de conteneur.
La troisième façon, si vous voulez vraiment le faire, consiste à utiliser une stratégie de téléchargement personnalisée pour récupérer le fichier ZIP ou TAR à partir du releases, décompresser et exécuter. Ou vous pouvez également utiliser SDKMAN ! pour l'installer, ce qui, à ce stade, n'est pas surprenant que JReleaser puisse publier et diffuser des packages à SDKMAN ! aussi.
InfoQ : Existe-t-il un moyen de personnaliser l'utilisation de JReleaser pour les outils personnalisés ? Ou une sorte de mécanisme d'extension ?
Andres Almiray : pour le moment, JReleaser peut être utilisé directement avec Maven, Gradle, Bach, et Ant. Ces intégrations nécessitent une petite abstraction sur le moteur d'exécution. Si l'outil de construction s'appuie sur l'interface ToolProvider de Java 9 pour personnaliser son comportement, j'ai une nouvelle : JReleaser expose déjà son propre ToolProvider, ce qui le rend très simple à intégrer. C'est exactement ce que fait l'outil de construction Bach aujourd'hui.
Le moteur est écrit de telle manière qu'il est facile à intégrer avec n'importe quel autre outil de construction si le besoin s'en fait sentir. Si tel devait être le cas, j'encourage vivement les personnes intéressées par une nouvelle intégration à rejoindre notre page Discussions et de présenter l'idée.
Peu importe le type de projet que vous créez, quelle que soit sa complexité ou la façon dont il est écrit, tous les projets logiciels ont besoin d'un moyen de gérer leurs versions. Le plus souvent, les procédures et processus de publication sont soit des listes de tâches qui doivent être exécutées automatiquement, à la main, ou avec des outils ou des scripts personnalisés utilisés dans différentes entreprises. Avec la complexité toujours croissante des produits logiciels et des projets, ceux-ci sont encore plus difficiles à assembler dans un produit ou un projet cohérent.
Info : Pouvez-vous nous donner un aperçu de l'avenir de JReleaser ? Existe-t-il une feuille de route définie ?
Andres Almiray : le projet prend en charge une grande variété d'intégrations, allant de : la publication de versions vers GitHub, GitLab et Gitea ; packaging avec Homebrew, Scoop, Chocolatey, Snapcraft, JBang, Docker; annonce des releases sur SDKMAN !, Twitter, Gitter, Discord, Zulip, e-mail, Slack, Microsoft Teams ; prise en charge des types de distribution tels que Java binaire, JAR unique, Jlink et GraalVM Native Image.
Il existe d'autres services qui pourraient être intégrés à l'avenir, une autre plate-forme Git peut-être, ou peut-être encore un autre packageur spécifique à la plate-forme, ou un service d'annonces. C'est ici que nous comptons sur les retours des utilisateurs pour nous faire savoir avec quels services ils peuvent avoir besoin d'intégrer dans leurs projets.
Java 16 a ajouté jpackage comme option de création installateurs spécifiques à la plate-forme. Cela pourrait aussi être un autre type de distribution qui pourrait être ajouté à l'avenir. Après tout, certaines des sorties produites par jpackage peuvent être distribuées avec Homebrew (.dmg et.pkg en tant que casks), par exemple.
Récemment, la possibilité de créer un journal des modifications formaté a été ajoutée, mais elle le fait en ne regardant que les commits locaux pour le moment. Cela signifie que nous manquons de métadonnées disponibles à distance, telles que les demandes d'extraction, les étiquettes de problème et d'autres données. Il sera peut-être possible à l'avenir de configurer JReleaser pour récupérer ces données avant de générer le journal des modifications.
InfoQ : avril a été un mois important pour JReleaser. Il a eu son lancement initial et la version 0.2.0 a suivi deux semaines plus tard. Quelles sont les fonctionnalités les plus importantes jusqu'à présent ?
Andres Almiray : En effet. Le projet a progressé lentement en mode furtif depuis septembre 2020 alors que l'équipe contributrice reprenait toujours des idées et testait des hypothèses. En mars 2021, nous savions que nous disposions d'un noyau solide et avons défini la feuille de route pour la première version.
Peut-être que sa caractéristique la plus importante est sa flexibilité : JReleaser peut décider beaucoup de choses pour vous si vous suivez les conventions. Vous vous asseyez simplement et laissez JReleaser piloter le processus de publication. Mais en même temps, vous pouvez prendre le volant et décider comment et où vous voulez aller avec la release. Une taille unique ne convient pas à tous dans ce cas, JReleaser s'efforce de prendre en charge autant de cas d'utilisation que cela a du sens.
Cette flexibilité se traduit également par sa mise en œuvre pour l'intégration d'un nouveau service, packageur ou outil d'annonce, qui sont toutes des tâches assez simples.
InfoQ : Actuellement, cela ressemble à un one-man show. Y a-t-il des plans pour développer une communauté ? Un conseil pour les développeurs qui souhaitent contribuer ?
Andres Almiray : Cela ressemble certainement à ça, n'est-ce pas ? Cependant, le projet a eu un petit nombre de contributeurs depuis le début. Ce que j'aime à propos de JReleaser, c'est qu'il fournit un modèle unifié pour créer et publier des binaires quel que soit l'outil de build choisi, le service d'hébergement Git ou la solution CI. Je m'attendrais à ce que d'autres développeurs arrivent à la même conclusion et fassent un tour du projet, avec la probabilité de commentaires, de demandes de fonctionnalités et de correctifs en conséquence. Nous accueillons toutes sortes de contributions, qu'il s'agisse de tri des problèmes, de documentation, de correctifs ou autres.
Un bon point de départ est de participer à notre page Discussions et de poster une question, ou de jeter un œil à notre outil de suivi des problèmes et fournissez des commentaires sur un problème ou même un correctif. C'est toujours une bonne idée de commencer une conversation avant de travailler sur le code, de cette façon, nous pouvons vous aider à mettre la fonctionnalité ou le correctif en forme pour une fusion rapide.
Conclusion
Quel que soit l'outil que vous utilisez pour organiser votre projet, Maven, Gradle ou même Ant, et les canaux que vous utilisez pour publier ou annoncer vos releases, la mission de JReleaser est de les coller ensemble de manière cohérente et de s'assurer que tout fonctionne comme prévu. Avec une cadence de publication cohérente une fois toutes les deux semaines, JReleaser suit sa mission pour devenir l'outil de facto pour la gestion des versions dans le monde Java.
À propos de l'interviewé
Andres Almiray est un développeur Java/Groovy et un Java Champion avec plus de 20 ans d'expérience dans la conception et le développement de logiciels. Il a été impliqué dans le développement d'applications web et desktop depuis les premiers jours de Java. Andres est un vrai partisan de l'open source et a participé à des projets populaires comme Groovy, Griffon et DbUnit, tout en lançant ses propres projets (Json-lib, EZMorph, GraphicsBuilder, JideBuilder). Membre fondateur du framework Griffon et de l'événement communautaire Hackergarten.