Gradleの`compile`は7.0で消えた、今は`implementation`と`compileClasspath`

  • Gradle
  • Android

この記事は、構成と文章の整理にAIを使っています。
あくまで読みやすくするための補助で、内容そのものをAIにすべて任せて書いているわけではありませんが、ところどころ相談しながら整えています。

昔書いたメモに./gradlew dependencies --configuration compileというコマンドが残っていて、そのまま実行したら普通に落ちた。

> Could not find method compile() for arguments...

調べたらcompileconfigurationはとっくに非推奨になっていて、Gradle 7.0で完全に削除されていたらしい。非推奨自体はGradle 3.4(2017年3月)から始まっていて、当時書いたメモの直後くらいのタイミングだった。

今は依存関係の宣言も確認もimplementationベースでやることになっている。build.gradle側の宣言はとっくにimplementationに置き換えていたけど、依存関係を確認するときのconfiguration名まではメモを更新していなかった。

依存関係ツリーを見たいときは、宣言用のimplementationではなく解決済みのclasspathを表すcompileClasspathやruntimeClasspathを指定する。

$ ./gradlew -q app:dependencies --configuration compileClasspath

Androidの場合はここに一段ややこしさが加わる。ビルドバリアント(debug/release)ごとに別々のconfigurationが生成されるので、app:dependenciesをバリアント指定なしで叩くと全バリアント分がずらずら出てくる。特定のバリアントだけ見たいなら、バリアント名を頭に付けたconfiguration名を指定する。

$ ./gradlew -q app:dependencies --configuration debugCompileClasspath
$ ./gradlew -q app:dependencies --configuration releaseRuntimeClasspath

用途に応じて使い分けるconfigurationは主に4つ。

  • compileClasspath: コンパイル時に必要な依存関係
  • runtimeClasspath: 実行時に必要な依存関係
  • debugCompileClasspath / releaseCompileClasspath: ビルドバリアント別のコンパイル時依存関係
  • debugRuntimeClasspath / releaseRuntimeClasspath: ビルドバリアント別の実行時依存関係

compile一本で済んでいた頃と比べると指定は増えたけど、コンパイル時と実行時で本来別物だった依存関係が明確に分離された分、意図しない依存の混入には気づきやすくなっている。