Maven Daemonプロジェクトは、TakariとGradleで知られている手法を使用して、Mavenビルドの速度を上げることを目的としている。設計者は、最適化と最先端のテクノロジーとメソッドに焦点を当てた。JVMプロセスの代わりにGraalVMが使用され、JITコンパイル済みクラスがキャッシュされ、必要に応じて複数のプロセスが生成される。
Mavenの履歴ページに記録されているMavenの最も古いバージョンは、ほぼ19年前の2002年3月30日の1.0-beta-2だ。Mavenは、Javaエコシステム構築ツールにパラダイム変更をもたらした。それは、Apache Antが持っていた手続き型アプローチから宣言型モデルに移行した。また、プロジェクトを編成する従来の方法からシフトし、プラグインを複数回再利用できることを確立した。ほぼ20年後、SnykのJVMエコシステムレポートによると、Apache Mavenは64％のシェアを持つJVMのビルドツールのリーダーだ。それにもかかわらず、今日のソフトウェアプロジェクトの複雑さとサイズの増大は、より速く、より頻繁に、サービスの中断を最小限に抑えるか、まったく行わないで展開する必要性とともに、ビルド速度を優先する。Gradleが実施した調査によると、MavenはGradleで実行されるビルドよりも100倍遅い場合がある。
Maven Daemonとは何か、そしてそれからどのように利益を得ることができるかをよりよく理解するために、InfoQはmvndのイニシエーターであるGuillaume Nodetと主要な貢献者の1人であるPeter Palagaに一連の質問をした。
InfoQ: 読者への質問にお答えいただき、ありがとうございます。まず、自己紹介と、日々の仕事とmvndの開発におけるあなたの役割について説明していただけますか?
Peter Palaga氏: 私はRed Hat Integrationチームの一員であり、Camel QuarkusというプロジェクトでCamelコンポーネントをQuarkusに移植しています。ツールを作ることは私の趣味です。
InfoQ: mvnd作成の背後にある理由は何でしょうか?
Palaga氏: 大きなソースツリー (Camel Quarkusには1200以上のMavenモジュールがあります) の構築は、私の日常業務の一部です。Guillaume Nodet氏がmvndの実用的なプロトタイプを持っていると聞いたとき、私はすぐに興奮しました。確かに、それは多くの時間を節約します。
Guillaume Nodet氏: 過去数か月間、私はApache Camelプロジェクトのビルド時間を短縮することに取り組んできました。ある時点で、速度を向上させるためにMaven自体を掘り下げ始めなければなりませんでした。この作業から生まれたアイデアは、クライアント/サーバアーキテクチャを使用して、キャッシュとJITの恩恵を受けるというものです。
InfoQ: 現在mvndに取り組んでいる貢献者は何人くらいですか? プロジェクトはどの程度持続可能ですか? コミュニティはどのように成長すると思いますか?
Palaga氏: 現在、Guillaume氏と私が主な貢献者です。コミュニティからいくつかのコードの貢献がありました - Michael SimonsによるHomebrewパッケージが最も著名なものです。GitHubリポジトリを視聴している人は約10人で、そのうちの何人かは問題や新機能について積極的に話し合っています。私たちは健全なコミュニティを構築する良い道のりにあると思います。
InfoQ: なぜ Daemon を使用するのでしょうか? それを使用したときの速度の向上は何でしょうか?
Palaga氏: 時間を節約することが、それを使用する最も説得力のある理由です。速度の向上はシナリオによって異なります。1つまたは2つのモジュールを構築する場合、標準のMavenと比較して7倍、10倍、またはそれ以上のスピードアップが可能です。例としてcamel-activemqを取り上げましょう。Javaコードは約4060行あるため、それほど大きくはありません。標準のMaven (mvn install -DskipTests、すべての依存関係をローカルMavenリポジトリにキャッシュされている) を使用してその単一モジュールをビルドするには、私のマシンで5.8秒かかります。
バックグラウンドでデーモンを起動するmvndを使用した最初のビルドには、ほぼ同じ時間がかかります。 次の各ビルドははるかに高速です。デーモンがすでに実行されているため、2番目のビルドはわずか0.32秒 (18倍のスピードアップ) になります。ディスクからJARを読み取る必要はなく、Mavenコアとプラグインクラスをロードする必要もありません。すべてがメモリ内にあり、ビルド要求を実行する準備ができています。JVMのJust-In-Time (JIT) コンパイラが起動し、ランタイムデータに基づいてコードを最適化するため、以降のビルドはさらに高速になるかもしれません。この例では、4番目のビルドで、時間は0.22秒 (26倍のスピードアップ) に短縮されます。
それは、モジュールの小さなセットを構築するときの時間の節約についてでした。それでは、モジュールの大規模なセットを構築する方法を見てみましょう。例として、1242モジュールを備えたCamel Quarkusを取り上げましょう。標準のMaven (mvn clean install -Dquickly、すべての依存関係がキャッシュされている) でビルドするには、2分51秒かかります。(-Dquicklyフラグは、ツリー全体を再構築するときに通常必要とされないテスト、ソースチェック、およびその他のものを無効にします)
ここですでにmvndを使用した最初のビルド (mvnd clean install -Dquickly) は、はるかに高速です: 45.9秒 (3.7倍の高速化) 。これは、mvndがモジュールを並列に構築するという事実と、たまたま24コアのマシンを所有しているという事実のおかげです。この特定のソースツリーでは高度な同時実行が可能であるため、ほとんどの場合、Daemonはすべてのコアを利用して個々のモジュールを構築できます。
前の例で見たように、Daemonがクラスを再ロードする必要がないため、2番目のビルドは高速になるはずです。さらに、JITコンパイラがいくつかのホットパスを最適化しているかもしれません。Camel Quarkusの場合、2番目のビルドは32秒になります (標準のMavenに対して5.2倍のスピードアップ) 。3番目のビルドは、JITでコンパイルされたものが増えるため、さらに数秒速くなります: 29.7秒 (5.7倍のスピードアップ) 。
InfoQ: Daemonの使用を推奨しないのはどのコンテキストでしょうか?
Palaga氏: mvndは、主に開発者ワークステーションでの反復型開発用に設計されています。標準のMavenのドロップイン代替品として試す価値があると思います。問題が発生した場合、ユーザはプロジェクトでそれらを報告してほしいです。継続的インテグレーション (CI) の分野では、mvndの可能性はほとんどありません。Nodet氏: 現在、mvndはMaven 3.6.3にバインドされているため、ビルドが実際は古いバージョンのMavenに依存している場合、問題が発生する可能性があります。最善の方法は、mvndを活用できるように最新のMavenにアップグレードすることです。
InfoQ: 現在、mvdのバージョンは0.1.0です。プロダクション環境で使用するのに十分安定していますか? それともまだトライアルモードですか?
Palaga氏: かなり安定していて、私がたまたまそれを使用する一連のシナリオで使えています :) 潜在的なユーザは、それがどれほどうまくいくかを試してみることを歓迎します。GitHubのスターとTwitterのフォロワーの数が増えていることから判断すると、mvndは多くの人にとってうまく機能していると思います。
InfoQ: Daemon開発で直面した最大の課題は何でしたか?
Palaga氏: mvndのクライアント側をGraalVMに移植することは困難でしたが、むしろ楽しいものでした。そのおかげで、mvndコマンドラインツールは、クライアント側でJVMを開始する必要がないため、ビルドをさらに高速化するネイティブ実行可能ファイルです。ネイティブ実行可能ファイルは非常に速く起動し、従来のJVMと比較してメモリの一部しか消費しません。mvndクライアントは、ビルド要求をDaemonに転送して結果を表示するためにあります。23コアで実行されているmvndの短い記録を見ることができます。
InfoQ: 今後のロードマップは? 1.0バージョンまではどのくらい離れていますか?
Palaga氏: 現在の計画は、GUIを少しずつ改善し、適切なドキュメントをいくつか用意し (コミュニティのメンバーが、mvndaemon.org ドメインを私たちに寄付してくれました!) 、Mavenプラグインのエコシステムを促進して並列ビルドをより適切にサポートすることです。貢献は大歓迎です、特にWindowsユーザのためにChocolateyパッケージを準備してもらえるたら素晴らしいです!
InfoQ: ダウンロードレートはどのくらいですか? その使用法に関する統計はありますか?
Palaga氏: GiHub APIからいくつかの統計を、このサイトでは集約しています。これまでリリースごとに数百のダウンロードがありました。これらの数値は、GitHubからの直接ダウンロードと、SDKMAN!、Homebrew、およびasdfパッケージマネージャを通したダウンロードの両方をカバーする必要があります。
InfoQ: 私はあなたに先に尋ねるべきだった質問がありますが、質問してもよいですか?
Palaga氏: もちろんです!
InfoQ: mvndとASF Mavenプロジェクトの関係は何でしょうか?
Palaga氏: 私たちは正式に独立しており、ASFプロセスの基盤にはなりません。ただし、すべてのコードをApacheライセンスの下に置くように注意しており、コードが安定していて十分にバトルテストされていると判断したら、mvndをASF Mavenプロジェクトの一部にしたいと考えています。