2022年4月は、JReleaserがJavaコミュニティに公開されてちょうど1周年にあたる。過去1年間、毎月2回のリリースを着実に続けてきた開発者のAndres Almiray氏は、記念日をバージョン1.0のロールアウトで祝うことになる。1年の間には、MacportsとGoFishという、他プラットフォーム用のパッケージャのサポートが追加されている。パッケージマネージャのサポート追加は、今後もさらに続くことだろう。
何か月にもわたって、このツールは、GraalVM Native Imageによるプラットフォーム固有バイナリの生成を中心として、さまざまなプロジェクトで採用され、リリースの作成を担ってきた。
Javaコミュニティは1年間にわたって数々のオープンソースコントリビューションを提供してきたが、JReleaserの開発を支える原動力であり続けているのは、何といってもAlmiray氏だ。JReleaserの進化についてより詳しく知るべく、そのAlmiray氏に話を聞くことにした。
InfoQ: こんにちは、Andres。先回あなたがJReleaserをローンチした昨年4月にチャットしてから1年が経ちました。そして今回、バージョン1.0のロールアウトです。この12か月間、どのようなことが変わりましたか？
Andres Almiray: 最初に言いたいのは、JReleaserは、バイナリが開発者自身の選択したビルドツールによってビルドされ、アセンブルされることを前提としているという点です。このツールに、jlinkやjpackage、GraalVM Native Imageで生成されたバイナリディストリビューションと重複する部分があることは、開発の早い段階で気付いていました。そこで、リリースステップとは別に実行されることを想定したアセンブラステップの一部として、それらのツールに関するサポートを追加した上で、必要な回数、あるいはjpackageやネイティブイメージの場合には"特定のオペレーティングシステム"のように適切な環境下で、アセンブラの起動を指示するオプションを提供することにしたのです。
InfoQ: JReleaserのミッションは"アーティファクトを複数のパッケージマネージャに公開する"ことだと思うのですが、WAR/JARファイルやDockerイメージ、あるいはKubernetesといった他のビルドターゲットにはどのように対応するのか、説明して頂けますか？それら以外についてはどうでしょう？
Almiray: Javaバイナリのパッケージングとデプロイを行う場合、一般的なターゲットとなるのはJARファイルです。これには、すべての依存関係を含んだ自己完結型のアプリケーションである場合や、さらには実行可能なように構成されている場合もあります。HomebrewとScoopは、このようなパッケージオプションを最初からサポートしていますが、その他のパッケージマネージャでは、起動スクリプトや実行バイナリといった追加ファイルが必要です(JReleaserのテンプレートメカニズムとパッケージャは、このギャップを埋めるサポートをします)。
JReleaserには、テンプレートに基づいてDockerfileを生成するオプションが用意されているので、JARをDockerイメージと合わせて公開することができます。
今のところ、WARファイルやKubernetesに対する明示的なサポートはありません。
InfoQ: JReleaserという名称はJava環境に強く結び付いていますが、JVMに関係しないプログラミング言語やビルドツールもサポート対象なのでしょうか？
Almiray: その通りです。JReleaserのヒントになったのはGoReleaserです。そのため、GoReleaserの動作だけでなく名前も真似たことで、JReleaserになった(Release4Jという選択肢もありました)のですが、その柔軟性から、あらゆる種類のプロジェクトのリリースが可能になっています。
Rustバイナリのリリースも可能です — Cargoによる通常のビルドワークフローでバイナリを生成して、それをJReleaserにフックしてリリースを作成します。MacOS(IntelとARM)、Linux(IntelとARM)、Windows(Intel)でRustからコンパイルしたバイナリをリリースする手順が、バイナリを生成するかしないかに関わらず、他のプログラミング言語(Rust、Python、Perl、JavaScriptなど)のヒントになります。
InfoQ: この1年を振り返って、何か改めるべき点はありますか？JReleaserとあなた自身の今後についてもお聞かせください。
Almiray: バージョン2はもっと広い意味を持った名称にして、ソースコードに関係なく、あらゆるプロジェクトに使用できる点を強調することになるでしょう(今のところ、"Releasy"が候補のひとつです)。
さまざまなアイデアがあるのですが、FlatpakやAppImageといった他のプラットフォームパッケージャとのインテグレーション、GraalVM Native Imageを使ってツール自体のネイティブイメージを提供すること、BitBucketやAzure DevOpsとのインテグレーションなどを考えています。
現在のJavaエコシステムにおいて、必要なアクションをすべて同じ傘下に収めている唯一のものとして、JReleaserはユニークな存在である、とAlmiray氏は言う。JVMに特化したツールの典型である"J"で始まっていながら、他のプログラミング言語で記述されたプロジェクトでの動作も保証するJReleaserには、バージョン２でもっと包括的な名称が与えられることになるだろう。