ここ半年くらいGradleを以前よりは頻繁に触るようになった。Gradleのプロジェクトでは、Mavenで書かれた古いプロジェクトではあまり見なかったWrapperをよく見かけるので、その役割を調べてみた。

[公式ページの解説]

公式ページにGradle Wrapperの説明があった。

上記ページによると、Wrapperは一種のスクリプト（gradlewまたはgradlew.bat）であり、指定されたバージョンのGradleを、必要な場合にはダウンロードして、実行してくれる。

Wrapperを利用するメリットは以下の通り。

つまり、Wrapper自体はGitなどのバージョン管理システムに追加する必要がある。Wrapperはスクリプトとプロパティファイル、そして軽量なjarファイルなので、バイナリだがあまり問題にならない。

WrapperがないプレーンなGradleプロジェクトの場合、gradle wrapperコマンドを実行するとwrapperを追加できる。

また、Wrapperをバージョンアップする場合は./gradlew wrapper --gradle-version 7.1.1のようにコマンドを実行すればよい（Windowsマシンの場合は./gradlew.bat 〜）。

[感想]

複数の開発者やビルド環境間でのGradleバージョンの統一が容易、ということは逆にいうと、個人で、1台のマシンでGradleプロジェクトを実行している自分のケースではあまり必要ないかな、という気もしてきた。

とはいえ、仕事で使う場合はやはり必須だろう。

開発者のマシンもWindowsだったりLinuxだったり、ビルドする環境もUbuntuだったりAmazon Linux 2だったりするので、ビルドツールのバージョンの統一はやはり重要な関心事項になる気がする。

しかし、AWS CodeBuildのようなコンテナ環境でビルドする場合、毎回Gradleがインストールされるのだとしたら、それはそれでデータ転送にかかる費用が地味に蓄積されることになるのでもったいないような……。

と思ったらそういう場合はカスタムビルドキャッシュの仕組みを利用して回避できるらしい。なるほど。

buildspec.ymlは以下のようになるとのこと。

phases:
  build:
    commands:
      - ./gradlew soakTest -s

cache:
  paths:
    - '/root/.gradle/caches/**/*'
    - '/root/.gradle/wrapper/**/*'

最近はMavenにもWrapperがあるらしい。後発のGradleに影響されているとのこと。

こんな記事もあった。Maven Wrapperはmvnwまたはmvnw.cmdというスクリプトらしい。

また、同じ記事によれば、Gradleは頻繁にバージョンアップが行われ、スクリプトの互換性が問題になることが多かったことから、Wrapperの仕組みで実行バージョンを統一する仕組みができた、らしい。なるほど。