プロジェクトのセットアップ中にQueryDSLの設定に関する記事をいくつか調べていたのですが、記事によって設定の内容が少しずつ異なっていました。
ある記事にはannotationProcessorの設定が書かれていて、別の記事ではプラグインのバージョンの話が先に出てきました。そこで自然とこんな疑問が浮かびました。
なぜSpringやQueryDSLを使っているのに、Gradleのバージョンまで確認する必要があるんだろう？
最初は自分もSpringがGradleに直接依存しているのかと思っていましたが、整理してみるとそうではありませんでした。
この記事は、そのときに混乱した内容を自分なりの理解でまとめた記録です。
Gradleは結局何をしてくれるのか？#
Gradleはビルドツールです。
Javaプロジェクトを実行可能な状態にするまでに必要な作業を代わりに処理してくれます。
自分の理解では、ライブラリの取得・Javaコードのコンパイル・テストの実行・最終的にjarなどの成果物としてまとめるところまでを担うツールだと捉えると、少しすっきりしました。
たとえばbuild.gradleに以下のように記述しておくと
dependencies {
implementation 'org.springframework.boot:spring-boot-starter-web'
}Gradleがリポジトリから該当ライブラリを取得し、必要な下位依存関係も一緒に持ってきてくれます。
そして以下のコマンドを実行すると
./gradlew testテストも自動的に実行してくれます。
つまり、開発者が毎回手動でやっていた作業を順序に従って実行してくれるツールだと理解すると分かりやすかったです。
なぜ設定の記事にはGradleのバージョンの話が一緒に出てくるのか？#
自分が混乱していたのはここでした。
アプリケーションはSpring Bootで作っているのに、なぜGradleのバージョン互換性の話が出てくるのかが分かりませんでした。
理由は、アプリケーションがGradleに依存しているのではなく、ビルド過程で使用するプラグインや設定がGradleのバージョンに影響を受けるからです。
たとえばSpring BootをGradleで使う場合、通常はプラグインを追加します。
plugins {
id 'org.springframework.boot' version '3.2.0'
}このプラグインはGradleの上で動作します。
つまり、Gradleが提供する機能や仕組みに合わせて作られています。そのため、Gradleのメジャーバージョンが変わると、古い方式で書かれたプラグインや設定コードが動かなくなるケースが出てきます。
だからSpring Bootの公式ドキュメントでも、対応しているGradleのバージョンを一緒に確認するようになっているのだと思います。
QueryDSLはなぜより敏感に感じたのか？#
QueryDSLは特に、設定に関する記事ごとの差異が大きく感じられました。
理由は、QueryDSLが単にライブラリを追加するだけでは終わらず、ビルド時にQClassを生成する工程が入るからです。
たとえばMemberエンティティがあると、ビルド時にQMemberのようなクラスが生成されます。
この作業は通常、annotation processingの過程で処理されますが、この部分がGradleのバージョンによって設定方法が微妙に変わります。
そのため、古い記事をそのまま参考にすると、現在のプロジェクトでは動かないケースが出てきます。
実際に調べた記事もGradleのバージョンがそれぞれ異なっていたため、設定コードが少しずつ違っていました。
まとめ#
結局、自分が理解したのはこういうことです。
SpringやQueryDSLが実行中にGradleを使っているわけではありません。Gradleはあくまでビルド時に必要なツールです。
ただし、ビルド過程に含まれるプラグインやannotation processingの設定はGradleのバージョンに影響を受けます。だからプロジェクトのセットアップ時にライブラリのバージョンだけでなく、Gradleのバージョンも一緒に確認する必要があったわけです。
最終的に、デプロイされたjarファイルの中にGradleが入っているわけではありません。
Gradleはビルドが終われば役目を終え、実際の実行はSpringアプリケーションが担います。
これを理解して初めて、なぜ公式ドキュメントや設定の記事で「Spring Bootのバージョン」「Gradleのバージョン」「Javaのバージョン」を一緒に確認するよう言われているのか、少し感覚がつかめました。