この記事について
Gradleをより理解するために公式ドキュメントを読んでメモ代わりとして私なりに訳していきます。
読んでいるドキュメントのバージョンは7.3.3です。
この記事で訳している章はAuthoring Gradle Builds>Structuring Individual Builds>Sharing Build Logic between Subprojectsとなります。
必要な章から読んでいるため、一連の記事は公式ドキュメントの章立て通りの順にはなっていません。
Structuring Individual Builds>Declaring Dependencies between Subprojects
Convention Plugins
通常、マルチプロジェクトビルドのサブプロジェクトはいくつかの特徴を共有します。たとえば、いくつかのサブプロジェクトは特定のプログラミング言語のコードを含んでいますが、あるサブプロジェクトはドキュメント専用かもしれません。コード品質管理はすべてのコードに適用されますが、ドキュメントには適用されません。同時に、一つの共有の特徴を持ったサブプロジェクトが、別々の目的を果たす場合もあります。例えば、下記のような異なるタイプの成果物を生成するかもしれません。
- 公開ライブラリ-あるリポジトリで公開されているライブラリ
- 内部ライブラリ-プロジェクト内の他のサブプロジェクトが内部的に依存しているライブラリ
- コマンドラインアプリケーション-特定のパッケージングが必要なアプリケーション
- Webサービス-上記とはまた異なるパッケージングが必要なアプリケーション
- その他
そのほか、コードサブプロジェクトはテスト機能も提供するでしょう。
上記の特徴はサブプロジェクトのタイプを識別するものです。言い換えると、サブプロジェクトのタイプはそれが持つ特徴を教えてくれます。
Gradleはビルドロジックの計画にはプラグインを使用することを推奨しています。プラグインはサブプロジェクトのタイプを定義します。事実、Gradleのコアプラグインは同様にモデル化されています。たとえばJavaプラグインは汎用的なJavaプロジェクトを構成し、一方で、Java Libraryプラグインは内部的にJavaプラグインを適用して追加でライブラリに特有な側面を構成します。同様に、Applicationプラグインは、JavaプラグインとDistributionプラグインを適用して構成します。
コアと外部プラグインの両方を適用、構成し、あなたの組織またはプロジェクトに特有の協約を構成するカスタムプラグインを作成することで新しいプロジェクトのタイプを定義することができます。この章の最初に挙げた特徴のそれぞれについても、与えられたタイプのサブプロジェクトに共通するロジックをカプセル化して記述することができます。
私たちはソースコードとテストに対するConventionプラグインをプロジェクトルートディレクトリ内の buildSrcディレクトリに置くことを推奨しています。
buildSrcについてのより詳細な情報はUsing buildSrc to organize build logicを参照してください。
[Conventionプラグインを使用したマルチプロジェクトのビルドロジックのモデル化のサンプルデモ]
(https://docs.gradle.org/current/samples/sample_convention_plugins.html "sample that demonstrates a multi-project build that models the build logic using convention plugins")をご覧ください。
また、さらに複雑で現実的なConventionプラグインを使用したマルチプロジェクトのビルドの構成の例はGradle Build Tool自体をビルドすることです。
[Cross project configuration](Cross project configuration)
DSL構文のallprojects{}やsubprojects{}を通じてサブプロジェクト間にまたがるプロジェクト構成を共有するcross project configration手法がありますが、これはおすすめできません。クロスプロジェクト構成ではサブプロジェクトにビルドロジックがインジェクトされることがあり、これが特定のサブプロジェクトのビルドファイルを見た時に明白ではないため、理解が難しくなります。長期的に見ると、クロスプロジェクト構成は往々にして条件つきロジックが増えて複雑化し、メンテナンスの重荷になります。クロスプロジェクト構成はプロジェクト間の設定時の結合をもたらし、随時構成のような最適化がきちんと機能しなくなる可能性があります。
協約プラグインを使ってモデル化した方が良いであろうクロス構成の一般的な使用例は2つあります。
- 一定のタイプのサブプロジェクトにプラグインを適用したりその他の構成を行う。クロス構成ではしばしば構成セクションで「サブプロジェクトのタイプがXであればYを構成する」と実行しますが、これは
X-conventionsプラグインをサブプロジェクトに直接適用したときと同等です。 - 特定のタイプのサブプロジェクトから情報を抽出する。この使用例はoutgoing configuration variantsを使用してモデル化できます。