Avril 2022 marque l'anniversaire de la présentation de JReleaser à la communauté Java. Après un an avec deux sorties régulières par mois, Andres Almiray, créateur de JReleaser, fête cet anniversaire avec le déploiement de la version 1.0. Pendant ce temps, la prise en charge d'autres packagers de plates-formes a été ajoutée : Macports et GoFish. La prise en charge de gestionnaires de packages supplémentaires sera probablement ajoutée à l'avenir.
Au cours des derniers mois, l'outil a été repris par d'autres projets pour élaborer leurs versions, principalement ceux utilisant GraalVM Native Image pour générer des fichiers binaires spécifiques à la plate-forme.
Même si la communauté Java a fourni de nombreuses contributions open-source à JReleaser au cours de l'année écoulée, Andres Almiray continue d'être le force motrice derrière elle. InfoQ a contacté Andres Almiray pour mieux comprendre comment JReleaser a évolué.
InfoQ : Bonjour Andres, un an s'est écoulé depuis notre dernier échange, en avril 2021, lorsque vous veniez de lancer JReleaser. Vous déployez maintenant la version 1.0. Qu'est-ce qui a changé au cours de ces mois depuis notre dernière conversation ?
Andres Almiray : Pour commencer, JReleaser s'attend à ce que les binaires soient construits et assemblés par l'outil de build de votre choix. Au début, nous avons remarqué qu'il y avait un chevauchement avec les distributions binaires créées avec jlink, jpackage et GraalVM Native Image. Ainsi, nous avons ajouté la prise en charge de ces outils dans le cadre de l'étape d'assemblage qui est censée être invoquée séparément de l'étape de publication, vous donnant la possibilité d'invoquer les assembleurs autant de fois que nécessaire ou dans les bonnes circonstances, comme sur un système d'exploitation spécifique comme c'est le cas pour jpackage et native image.
InfoQ : la mission supposée de JReleaser est de "publier des artefacts sur plusieurs gestionnaires de packages". Pouvez-vous s'il vous plaît expliquer si et comment JReleaser aide avec d'autres cibles de build, telles que les fichiers WAR/JAR, les images Docker ou Kubernetes ? Ou d'autre ?
Andres Almiray : les fichiers JAR, comme le cas typique de packaging et la cible de déploiement pour les binaires Java, sont parfois une application autonome qui peut inclure toutes ses dépendances, et elle est également configurée pour être exécutable. Homebrew et Scoop prennent en charge cette option de packaging dès le départ, d'autres nécessitent des fichiers supplémentaires tels que des scripts de lancement ou un exécutable binaire (le mécanisme de template et le support de packager de JReleaser comble cette lacune).
Les JAR peuvent être livrés avec une image Docker, JReleaser fournissant des options pour créer des Dockerfiles basés sur des modèles.
Il n'y a pas de support explicite pour les fichiers WAR ou Kubernetes pour le moment.
InfoQ : Le nom est fortement enraciné dans l'environnement Java. JReleaser prend-il en charge les langages de programmation et les outils de build non liés à la JVM ?
Andres Almiray : C'est exact. GoReleaser a servi d'inspiration pour JReleaser, ainsi non seulement le comportement de l'ancien outil a été imité, mais aussi le surnom, d'où JReleaser (Release4J étant une autre option). Cependant, compte tenu de sa flexibilité, il est possible de publier n'importe quel type de projet.
Par exemple, vous pouvez publier des binaires Rust : le workflow de build habituel Cargo produit les binaires, les raccorde à JReleaser et crée une release. Un blueprint pour la release des binaires sur MacOS (Intel et ARM), Linux (Intel et ARM) et Windows (Intel) compilé à partir de Rust peut être une source d'inspiration pour n'importe quel langage de programmation (Rust, Python, Perl, JavaScript, etc.) qui produit ou non des binaires.
InfoQ : Rétrospectivement, y a-t-il quelque chose qui doit être changé ? Que réserve l'avenir pour vous et JReleaser ?
Andres Almiray : Peut-être un nom plus inclusif (Releasy est une option pour l'instant) dans la version 2 pour souligner que l'outil peut être utilisé avec n'importe quel projet, quel que soit son code source.
Parmi les idées qui circulent : l'intégration avec d'autres packagers de plate-forme tels que Flatpak ou AppImage ; livrer les exécutables natifs de l'outil avec GraalVM Native Image ; et l'intégration avec BitBucket et Azure DevOps.
Dans l'écosystème Java actuel, JReleaser semble être unique, selon Andres Almiray, car étant le seul à avoir toutes les actions requises sous le même parapluie. Même s'il est préfixé du "J" typique des outils axés uniquement sur l'écosystème JVM, JReleaser promet de pouvoir travailler avec des projets écrits dans d'autres langages de programmation et peut-être qu'un nom plus inclusif viendra dans sa deuxième version.