この記事について
Gradleをより理解するために公式ドキュメントを読んでメモ代わりとして私なりに訳していきます。
読んでいるドキュメントのバージョンは7.3.3です。
この記事で訳している章はStructuring Individual Builds>Creating a Basic Multi-Project Buildとなります。
必要な章から読んでいるため、一連の記事は公式ドキュメントの章立て通りの順にはなっていません。
Structuring Individual Builds>Creating a Basic Multi-Project Build
Structuring and Building a Software Component with Gradle1
ある規模のソフトウェアをGradleでビルドする場合、2つの構造化の仕組みがあります。最初に、この章ではGradleマルチプロジェクトを使用したソフトウェアの構造化について説明します。このドキュメントでは、これを内部で構造化された単体のソフトウェアコンポーネントとして考えます。次に、ソフトウェアは個別のGradleビルドで表現されているソフトウェアコンポーネントの複合体であるソフトウェア製品として考えることが出来ます。これについての詳細な説明はstructuring software products with Gradleで行います。
Creating a multi-project build
Gradleのマルチプロジェクトビルドはルートプロジェクトと任意の数のサブプロジェクトで成り立ちます。
基本的なマルチプロジェクトビルドはひとつのルートプロジェクトと単体のサブプロジェクトを含みます。これがappと呼ばれる単体プロジェクトを含むマルチプロジェクトの構造です。
.
├── app
│ ...
│ └── build.gradle
└── settings.gradle
これが推奨されるGradleのプロジェクトの出発点です。build initプラグインも一つのルートプロジェクトに一つのサブプロジェクトの上記のようなスケルトンを生成します。
ルートプロジェクトはビルドファイルを持たず、サブプロジェクトを含めるための設定ファイルしか持っていないことに注意してください。
rootProject.name = 'basic-multiproject'
include 'app'
この場合、Gradleはappディレクトリにあるビルドファイルを検出します。
gradle projects
コマンドを実行することで、マルチプロジェクトビルドの構造を見ることができます。
> gradle -q projects
------------------------------------------------------------
Root project 'basic-multiproject'
------------------------------------------------------------
Root project 'basic-multiproject'
\--- Project ':app'
プロジェクトのタスク一覧を見るためにはgradle <project-path>:tasks
を実行します。この例ではgradle :app:tasks
と試してください。
appプロジェクトはJava applicationプラグインを適用してmainクラスを構成されたJavaアプリケーションだとしましょう。
plugins {
id 'application'
}
application {
mainClass = 'com.example.Hello'
}
package com.example;
public class Hello {
public static void main(String[] args) {
System.out.println("Hello, world!");
}
}
applicationプラグインからのrunタスクでアプリケーションを起動することができます。
> gradle -q run
Hello, world!
基本的なマルチプロジェクトビルドの作成はとてもシンプルです。
Adding subprojects
先ほど作ったプロジェクトにlibと呼ばれる他のサブプロジェクトを追加したいとしましょう。別のinclude
文をルートの設定ファイルに追加する必要があります。
rootProject.name = 'basic-multiproject'
include 'app'
include 'lib'
Gradleがlib/サブディレクトリにある新しいサブプロジェクトのビルドファイルを見に行くようになります。
.
├── app
│ ...
│ └── build.gradle
├── lib
│ ...
│ └── build.gradle
└── settings.gradle
次に、どのようにビルドロジックをサブプロジェクト間で共有するのか、どのようにあるプロジェクトが別プロジェクトに依存させるのかの見ていきましょう。
Naming recommendations
プロジェクトが成長していくにつれて、命名とその一貫性が重要になってきます。保守性を維持するため、下記のように推奨します。
- サブプロジェクトのデフォルト名を維持する:設定ファイルでプロジェクトのカスタム名を構成することができます。しかし、開発者がどのプロジェクトがどのフォルダーに属しているかを追跡するのは不必要な追加の労力です。
- すべてのプロジェクト名にはケバブケース形式を使用する:ケバブケース形式はすべての文字は小文字で記述し、単語の区切りは
-
を使用する形式です。これは多くの大型プロジェクトで事実上の標準となっており、Gradleはケバブケースの名前の省略をサポートしています。 - 設定ファイル内でルートプロジェクト名を定義します:
rootProject.name
はビルド全体に効果的に名前を割り当て、それはビルドスキャンのようなレポートで使用されます。ルートプロジェクト名が設定されていない場合、名前は格納されているフォルダ名となり不定となります。言い換えると、設定ファイルで指定されていれば、プロジェクトを任意のディレクトリにチェックアウトできます。
-
公式でも目次の見出しと記事タイトルが一致していないのは良くないと思う ↩