コード例
Kotlin DSLを全章へ反映

ENGINEERING NOTEBOOK / 02 GRADLE HANDS-ON

小さく作り、
少しずつ育てる。

新しくGradleを使う人も、既存プロジェクトへ参加する人も、まず小さなGradleプロジェクトを一つ作ってみます。その経験を通して、既存の設定も自分で読めるようになることを目指します。

空のSampleAppから始め、やりたいことが増えたときに、必要な設定を一つずつ追加します。Eclipseを横に開き、第1章から順番に進めてください。

第1章:空のフォルダーから始める

Windows PowerShell / Eclipse 2026-06・Buildship / Gradle 9.6.0(起動JDK 25) / アプリ用JDK 11
前提:前作「Javaファイルの旅」を学習済み。基礎編は12章で完結。実務編・発展編は別教材です。
macOS・Linuxの切替はWrapperコマンドの参考表示です。準備とEclipse操作はWindowsを中心に説明します。

01

HANDS-ON / SAMPLEAPPを育てる

何もないフォルダーからGradleを始める

01今回やりたいこと

空のフォルダーに、これから作業を書き足していくGradleの最小構成を用意します。

02今、何が足りない?

まだWrapperがないので、最初のinitを動かすGradle本体が必要です。Gradleを動かすJDK 25と、作るプログラムをコンパイル・実行するJDK 11を準備します。Gradleは9.6.0のままです。Javaや起動の設定はまだ書きません。

03どこを変更する?

作業先は、これから作る空の SampleApp だけです。教材のHTMLを置いたフォルダーや、業務のプロジェクトを作業先にしないでください。

準備するもの今回の条件
Gradle起動用JDKJDK 25。Gradle 9.6.0をJava 11で起動しない。
アプリ用JDKJDK 11。コンパイル・JUnitテスト・runに使う。両JDKのjavaとjavacを確認する。
初回用Gradle公式のGradle 9.6.0のbinary ZIPを展開。既に9.6.0が使えるなら再導入不要。
端末Windows PowerShell。フォルダーへ移動してコマンドを実行する。
Eclipse2026-06とBuildship。取り込みは次章。

04PowerShellで用意する

1. JDKを確認。JAVA_HOMEが正しいJDK 25なら変更しません。次の枠をPowerShellで実行します。

Windows PowerShell / この枠はWindows用
$env:JAVA_HOME
Test-Path "$env:JAVA_HOME\bin\javac.exe"
& "$env:JAVA_HOME\bin\java.exe" -version
& "$env:JAVA_HOME\bin\javac.exe" -version

JAVA_HOMEが空、パスが違う、または25以外なら、次のパスを自分のJDK 25の場所へ置き換えます。bin の一つ上を指定し、上の確認をやり直してください。これは今開いているPowerShellだけの設定です。

Windows PowerShell / この枠はWindows用
$env:JAVA_HOME = 'C:\実際のインストール先\jdk-25'

アプリ用JDK 11も確認。次の仮パスを自分のJDK 11の場所へ置き換えます。JAVA_HOMEは25のままです。

Windows PowerShell / この枠はWindows用
$lessonJdk11 = 'C:\実際のインストール先\jdk-11'
Test-Path "$lessonJdk11\bin\javac.exe"
& "$lessonJdk11\bin\java.exe" -version
& "$lessonJdk11\bin\javac.exe" -version

両方のTest-PathがTrueで、Gradle用は25、アプリ用は11と表示されることを確認します。Eclipse本体を起動するJavaも別の役割です。Eclipse本体やGradleの起動JDKを11へ変更しません。

2. 初回のGradleを確認。PATHに登録済みなら gradle --version。未登録ならフルパスで実行できます。パスの引用符だけでなく、先頭の & も入力します。

Windows PowerShell / この枠はWindows用
$lessonGradle = 'C:\実際の展開先\gradle-9.6.0\bin\gradle.bat'
& $lessonGradle --version

--version はGradle自体の情報を表示するオプションで、Task名ではありません。コンパイルは行いません。表示されたGradleが9.6.0、Launcher JVMとDaemon JVMが25かを確認します。違う場合はJAVA_HOMEに加え、既存のorg.gradle.java.homeやDaemon JVM criteriaの指定も確認します。全PC共通のインストール先はありません。端末を開き直したら、この設定も確認し直します。

3. 空のフォルダーへ移動。次の親フォルダーは例です。自分の練習用フォルダーに置き換え、既にSampleAppがある場合は上書きせず別の空の親フォルダーを使います。

Windows PowerShell / この枠はWindows用
Set-Location 'C:\自分の練習用フォルダー'
New-Item -ItemType Directory -Name SampleApp
Set-Location SampleApp

4. 最小構成を生成。PATHでGradleを使える場合は次を実行します。Kotlin DSLが既定です。Groovyを選ぶ場合は、この時点で上部の切替を行ってください。

CLI / init.ktsPATHにGradleがある場合
gradle init --type basic --dsl kotlin --project-name SampleApp --use-defaults

フルパスを変数に入れた場合は、上のコマンドの代わりに次を実行します。両方を実行する必要はありません。

CLI / init.ktsPowerShell / フルパス指定を使った場合
& $lessonGradle init --type basic --dsl kotlin --project-name SampleApp --use-defaults

init はプロジェクトのひな形を作るTaskです。ここでは --type basic で最小構成を選び、DSL・名前・既定値の使用を指定しています。設定ファイルとWrapperが生成されることを、次の一覧と照合します。Javaのコンパイルはまだ行いません。

05何が変わった?

生成直後 / Gradle 9.6.0の実測
  • SampleApp/
    • gradle/
      • wrapper/
        • gradle-wrapper.jar
        • gradle-wrapper.properties
      • libs.versions.toml
    • gradlew
    • gradlew.bat
    • settings.gradle.kts
    • build.gradle.kts
    • gradle.properties
    • .gitignore
    • .gitattributes
ファイル今、分かればよい役割
gradlew.bat / gradlewWindows / macOS・LinuxのWrapper起動入口。以後はここから、このプロジェクトで指定されたGradleを起動する。
gradle/wrapper/指定バージョンと起動に必要な部品。未取得のGradleは初回にダウンロードされる。
settings.gradle.kts生成時に rootProject.name がSampleAppになっている。
build.gradle.kts生成直後はコメントだけ。これから必要な作業の設定を足す場所。
その他の生成ファイル9.6.0では gradle.properties、gradle/libs.versions.toml、Git用の2ファイルも生成された。今は変更しない。

gradle は導入済みのGradle本体を起動するコマンド。生成された gradlew.bat は、このプロジェクト指定のGradleを起動する入口です。以後はWrapperを使うため、本体の場所を毎回指定する必要はありません。

変更前は空のフォルダー、変更後は上の構成です。src はまだなく、Javaソースや子プロジェクトもありません。実行後に現れる .gradle/ はGradleの作業用データです。

06 / 確認できたら次へ

BUILD SUCCESSFULとWrapper・settings・buildファイルを確認したら、そのままのSampleAppを第2章へ持ち込みます。作り直しません。

この章の公式資料:Build Init / Gradleの導入 / Wrapper / Java互換表

02

HANDS-ON / SAMPLEAPPを育てる

作ったGradleプロジェクトをEclipseで開く

01今回やりたいこと

第1章で作ったSampleAppをEclipseから編集・実行できるようにします。

02今、何が足りない?

ファイルはありますが、まだEclipseのワークスペースには登録していません。GradleはEclipseの外でも使えるので、取り込みとGradle自体の成功を分けて確認します。

03どこを変更する?

教材用フォルダーの中身は変更しません。Eclipseへ既存の SampleApp の場所を指定します。新規Gradle Projectウィザードは使いません。

04Eclipseで操作する

  1. Eclipseで File → Import… → Gradle → Existing Gradle Project → Next。Welcome画面が出た場合は案内を進めます。Gradle項目がなければBuildshipの導入状態を確認します。
  2. Project root directoryには、第1章の SampleApp を選択します。src や gradle/wrapper ではありません。NextでImport Optionsへ進みます。
  3. Override workspace settings をオンにし、この教材の取り込みに使う設定を下の順に確認します。既定値は以前の操作やワークスペースによって異なります。
画面の項目今回はどうする?意味
Gradle distribution / Gradle WrapperGradle Wrapperを選ぶ。SampleAppのWrapperが指定する9.6.0を利用する。
Local installation directory選ばない・入力不要。展開済みGradle本体のフォルダーを使う選択肢。
Remote distribution location選ばない・入力不要。Gradleの配布ZIPのURLを指定する選択肢。
Specific Gradle version選ばない・入力不要。指定したGradleの版を取得して使う選択肢。Wrapper選択中にここへ9.6.0を重ねて入力しない。
Advanced Options / Gradle user home特別な運用指定がなければ空欄。キャッシュ等の保存場所。SampleAppの場所を入れる欄ではない。既定は通常ユーザーフォルダーの.gradle。
Java home今回は第1章で確認したJDK 25の場所を指定。Gradleを動かすJavaを指定する。アプリ用JDK 11を入れる欄ではない。常に入力必須ではなく、空欄なら継承・既定の選択が使われる。そのJavaが互換性のあるJDKかを確認する。
Program Arguments / JVM Arguments空欄のまま。Gradleへの引数・Java VMへの引数。今回の演習では追加しない。
Offline Modeオフ。オンにすると同期・実行時の依存取得を制限する。初回取得が必要な演習ではオフにする。
Build Scansオフ。ビルド情報の公開用機能。今回の手順では使わない。
Automatic Project Synchronization今回はオフ。設定変更時の自動同期。教材では保存後に手動Refreshして変化を観察する。
Show Console View / Show Executions Viewオン。実行結果と進捗を確認しやすくする。
  1. NextでPreview(表示される場合)を確認し、Finish。同期が終わるまで待ちます。
  2. Project ExplorerにSampleAppが現れ、settingsとbuildファイルが見えることを確認します。設定ファイルが編集画面で開かない場合は、右クリック → Open With → Text Editor を選びます。
  3. Window → Show View → Other… → Gradle → Gradle Tasks を開き、SampleAppの help をダブルクリック。結果はGradle Consoleで読みます。Task一覧が古ければ、プロジェクトを右クリック → Gradle → Refresh Gradle Project。

05何が変わった?

PowerShell / プロジェクトのルートで
.\gradlew.bat help
.\gradlew.bat tasks
.\gradlew.bat projects

help は使い方の案内を表示し、この場所でGradleが起動して設定を読めるかを確認します。tasks は主なTaskの一覧で「今頼める仕事」を、projects はプロジェクトの一覧で「どの構成を開いているか」を確認します。いずれもJavaをコンパイルする指示ではありません。

変更前変更後・観察すること
Eclipse未登録。buildファイルはコメントのみ。Eclipseへ取り込み。help・tasks・projectsが実行でき、projectsはSampleAppのみ(No sub-projects)。

まだJava Pluginを使っていないため、Java用のソースフォルダーやJRE System Libraryの表示がなくても異常ではありません。compileJava やJava用の build Taskはまだ登録されていません。

成功表示だけでJavaがビルドされたと判断しない

この最小構成で build と入力すると、9.6.0ではTask名の短縮として buildEnvironment が選ばれました。Javaのビルドではありません。この章ではhelp・tasks・projectsで確認し、JavaのTaskは次章で追加します。

06 / 確認できたら次へ

同じフォルダーをEclipseで開け、helpが成功し、projectsに子プロジェクトがなければ第3章へ。

この章の公式資料:BuildshipのImport・操作 / Import設定の公式実装 / 設定項目の公式実装 / Gradle選択の公式実装 / Taskとコマンド

03

HANDS-ON / SAMPLEAPPを育てる

Javaをコンパイルしたい

01今回やりたいこと

Gradleプロジェクトは作れた。でも、Javaをコンパイルするには?

02今、何が足りない?

まだJava用のTaskとJavaソースがありません。ここで初めてjava Pluginを追加します。

03どこを変更する?

SampleApp直下の build.gradle.kts にpluginsとToolchain 11を追加します。生成時のコメントは残しても構いません。新規ファイルは src/main/java/guide/Greeting.java です。

変更前変更後・観察すること
buildファイルはコメントだけ。srcは存在しない。pluginsへjavaを追加し、コンパイル用JDKを11に指定。Javaソースを1つ作る。
build.gradle.kts追加する設定 / コメント以外の全文
plugins {
    java
}

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(11)
    }
}

今回のプログラムはJava 11で動かすため、Toolchainでコンパイルに使うJDKを11に指定します。Gradleを動かすJDK 25は変えません。選ばれたJDKを詳しく確認するのは第9章です。

JDK 11が見つからないとき
PowerShell / プロジェクトのルートで
.\gradlew.bat -q javaToolchains

Language Versionが11、Is JDKがtrueの環境があるか確認します。なければ第1章のJDK 11のパスを再確認。必要なら個人用の %USERPROFILE%/.gradle/gradle.properties に次の行を追加します(ファイル未作成なら作成)。既存の設定は消さず、同じキーがあればその行を編集します。パスは自分の場所へ置換し、区切りに / を使います。

個人用gradle.properties / JDK 11が自動検出されない場合
org.gradle.java.installations.paths=C:/実際のインストール先/jdk-11

別のGradle user homeを指定している場合は、その直下のgradle.propertiesです。保存後はWrapperで --stop を実行して検出情報を更新し、javaToolchainsとGradle Refreshをやり直します。この設定はJDKの候補場所を教えるもので、Gradle起動用のJAVA_HOMEやBuildshipのJava homeとは別です。11と書くだけでJDKが自動取得されるわけではありません。

04Eclipseで操作する

Java Pluginには標準の約束(既定のフォルダー構成)があります。下の場所を用途に合わせて使えば、フォルダーを作るたびにbuildファイルへソースパスを書く必要はありません。標準以外の配置は sourceSets などで変更できます。

標準の場所用途
src/main/java本番のJavaソース(この章で作る)
src/main/resources本番のリソース
src/test/javaテスト用Javaソース(第8章で作る)
src/test/resourcesテスト用リソース
  1. build.gradle.kts を開き、上の設定を入力します。設定ファイルが編集画面で開かない場合は、右クリック → Open With → Text Editor を選びます。
  2. 保存(Ctrl+S)し、SampleAppを右クリック → Gradle → Refresh Gradle Project。同期が終わるまで待ちます。
  3. Properties → Java Build Path → Libraries のJRE System LibraryがJavaSE-11(またはJDK 11)、Java Compiler の準拠レベルが11か確認します。違う場合は第9章の確認手順へ。
  4. SampleAppを右クリック → New → Folder(なければOther… → General → Folder)。src/main/java を作成します。中間フォルダーをまとめて作れない場合はsrc、main、javaの順に作成します。
  5. もう一度Gradle Refresh。src/main/java がJavaのソースフォルダーとして認識されるか、Properties → Java Build Path → Source で確認します。手動のJAR登録や別のJava Project作成は不要です。
  6. そのソースフォルダーを右クリック → New → Class。Packageは guide、Nameは Greeting。作成された内容を次の全文に置き換え、保存します。
src/main/java/guide/Greeting.java / 全文
package guide;

public class Greeting {
    public static String message(String name) {
        return "Hello, " + name + "!";
    }

    public static void main(String[] args) {
        System.out.println(message("Gradle"));
    }
}

Eclipseの「Run As → Java Application」を使う前に、Gradleでコンパイルできるかを確認します。まだGradleから起動する設定はしていません。

05何が変わった?

最初の1行は、.\gradlew.bat(WrapperからGradleを起動)+ tasks(実行するTask名)+ --all(一覧を詳しくするオプション)に分かれます。以下は役割と結果を比べるため、教材で個別に実行します。

PowerShell / プロジェクトのルートで
.\gradlew.bat tasks --all
.\gradlew.bat compileJava
.\gradlew.bat classes
.\gradlew.bat jar
.\gradlew.bat build
コマンド何をする?確認すること
tasks --all利用できるTaskを、通常の一覧で省略されるものも含めて表示する。Java用のcompileJava・classes・jar・buildなどが増えている。
compileJavasrc/main/java のJavaソースをコンパイルし、.classへ変換する。build/classes/java/main/guide/Greeting.class
classescompileJavaとprocessResourcesを実行対象にし、メインのクラスとリソースを揃える。クラスの出力。リソースがあれば build/resources/main/ へのコピー。
jar必要なクラスとリソースを揃え、JARにまとめる。テストの実行は含まない。build/libs/SampleApp.jar
build成果物の組み立てと、テストなどの検証をまとめて実行する。BUILD SUCCESSFUL、JAR、テストの状態。今は test NO-SOURCE で、テスト未実行。

classes 自身がJavaを変換するのではなく、compileJava と processResources に依存して準備をまとめます。後者は src/main/resources のファイルを出力先へコピーするTaskです。今はリソースがないため processResources NO-SOURCE で問題ありません。

Gradle TasksビューはRefreshしてから見ます。Gradleを導入しても、Eclipseの通常ビルドは使います。ただし、Ctrl+B とGradleの build は同じ操作ではありません。

比較Eclipseの通常ビルドGradleのbuild
担当と目的Java Builder(JDT)が変更をコンパイルし、IDEのエラー表示に反映する。Gradleがビルド定義に従い、成果物作成と検証を進める。
出力先Eclipseのプロジェクト設定による。必ずbinとは限らない。Gradleの設定による。標準ではbuild/classesなど。
テスト・JAR通常のJava自動ビルドだけでは、Gradleのbuild一式は実行しない。Plugin・Taskの設定に従って作成・検証する。

IDEでエラーが消えても、Gradleのbuildが成功したことにはなりません。ここではGradleの出力を確認します。設定画面の使い分けは第9章で扱います。

06 / 確認できたら次へ

Toolchain 11を残してcompileJavaが成功し、Greeting.classとSampleApp.jarがあれば第4章へ。今のファイルをそのまま使います。

この章の公式資料:Java Plugin / BuildshipのImport・操作 / EclipseのJava Builder

04

HANDS-ON / SAMPLEAPPを育てる

Javaのmainを実行したい

01今回やりたいこと

Javaをコンパイルできるようになった。では、mainをGradleから実行するには?

02今、何が足りない?

java Pluginだけではrun Taskがありません。起動するクラスの指定も必要です。

03どこを変更する?

build.gradle.kts の plugins 内のjavaをapplicationへ置換し、applicationブロックを追加します。第3章のToolchain 11は残します。Greeting.javaは変更しません。

build.gradle.kts変更前
plugins {
    java
}

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(11)
    }
}
build.gradle.kts変更後 / コメント以外の全文
plugins {
    application
}

application {
    mainClass = "guide.Greeting"
}

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(11)
    }
}

application PluginはJavaの機能を含みます。javaとapplicationの両方を並べて書く必要はありません。mainClass はパッケージを含むクラス名です。

04Eclipseで操作する

  1. Eclipseでpluginsを置換し、Toolchain 11を残したままapplicationブロックを追加。
  2. 保存(Ctrl+S)し、SampleAppを右クリック → Gradle → Refresh Gradle Project。同期が終わるまで待ちます。
  3. Gradle Tasksのapplicationグループから run を実行。端末でも、SampleAppのルートで次を実行します。
PowerShell / プロジェクトのルートで
.\gradlew.bat run
.\gradlew.bat build

05何が変わった?

変更前変更後・観察すること
runは未登録。JavaのコンパイルやJAR作成ができる。run は必要なコンパイル等を経て、mainClassのmainを起動するTask。コンソールの Hello, Gradle! を確認する。build は成果物を作り、検証するTask。成功表示・JAR・テストの状態を確認する。アプリのmainは起動しない。

今回のrunもToolchainで選んだJDK 11を使います。Eclipseの Run As → Java Application は別の実行構成なので、第9章の手順でJDK 11を選んでください。applicationでは配布用のTaskも追加されます。通常のJARは依存をすべて内蔵する実行JARではないため、java -jar で必ず起動できるとは考えません。

配布用ファイルも見てみる
PowerShell / プロジェクトのルートで
.\gradlew.bat installDist

build/install/SampleApp/ に起動スクリプトとJARが揃います。Windowsは build/install/SampleApp/bin/SampleApp.bat、macOS・Linuxは同じ場所の SampleApp を実行します。Java実行環境は必要です。配布スクリプトはGradleのToolchainを自動で引き継ぎません。起動時は別の端末でアプリ用JAVA_HOMEをJDK 11へ設定してください。Gradle用の端末はJDK 25のままにします。

06 / 確認できたら次へ

runの挨拶と、buildの成功を別々に確認できたら第5章へ。

この章の公式資料:Application Plugin

05

HANDS-ON / SAMPLEAPPを育てる

build.gradleを読めるようになる

01今回やりたいこと

自分で追加したpluginsとapplicationを読み、成果物の名前を変える設定を見つけます。

02今、何が足りない?

今はSampleApp.jarという名前です。版を付けるためのversionはまだ指定していません。

03どこを変更する?

build.gradle.kts の末尾へversionを1行追加します。settings.gradle.kts のSampleAppという名前は変更しません。

build.gradle.kts追加する1行
version = "1.0"

BUILD FILE READER / 今ある設定を選ぶ

できる仕事を決める

第3章はjava、第4章でapplicationへ置換しました。

build.gradle.kts該当部分
plugins { application }

04Eclipseで操作する

  1. Eclipseでbuildファイルのpluginsとapplicationの範囲を確認します。波括弧の外へversionを追加して保存します。
  2. 保存(Ctrl+S)し、SampleAppを右クリック → Gradle → Refresh Gradle Project。同期が終わるまで待ちます。
  3. Gradle Tasksで jar を実行するか、下のコマンドを使います。
PowerShell / プロジェクトのルートで
.\gradlew.bat jar

versionを保存しただけでは、既存のJARの名前は変わりません。jar をもう一度実行し、新しい版を名前に含むJARを作ります。

05何が変わった?

変更前変更後・観察すること
build/libs/SampleApp.jarbuild/libs/SampleApp-1.0.jar が生成される。古いJARが残る場合は名前を区別する。
目的変更する場所
このプロジェクトの名前settings.gradle.kts のrootProject.name
使うPlugin・mainの場所・成果物の版build.gradle.kts のplugins・application・version
第5章終了時点のbuildファイル全文
build.gradle.ktsこの章の終了時点 / 全文
plugins {
    application
}

application {
    mainClass = "guide.Greeting"
}

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(11)
    }
}

version = "1.0"
06 / 確認できたら次へ

versionを変える場所と、設定ファイル2種類の役割を区別できたら第6章へ。versionは1.0のまま進めます。

この章の公式資料:Kotlin DSL / Groovy DSL

06

HANDS-ON / SAMPLEAPPを育てる

Taskのつながりを理解する

01今回やりたいこと

buildを頼むと何が対象になるのか、実際に作ったSampleAppで確認します。

02今、何が足りない?

compileJava・jar・runは試しましたが、buildがまとめる作業の関係はまだ見ていません。

03どこを変更する?

設定ファイルは変更しません。第5章の内容を保ち、指定するTaskだけを変えて調べます。

  • 白系:処理するコンパイル・コピー・JAR作成・テスト
  • 薄緑:まとめる必要なTaskを実行対象にする
  • 濃緑:build作成と検証をまとめる入口
Java Pluginの主な依存関係 / 矢印は「先に必要なTaskから、依存するTaskへ」
Java Pluginの主要Task依存関係compileJavaとprocessResourcesからclassesへ。classesからjarとcompileTestJavaへ。jarからassembleへ。compileTestJavaとprocessTestResourcesからtestClasses、test、checkへ。assembleとcheckからbuildへ。独立したTask同士の実行順序は示していません。compileJavaprocessResourcesclassesjarcompileTestJavaprocessTestResourcestestClassestestassemblecheckbuild

主要な依存関係に絞り、その他のTask・依存は省略しています。矢印は実行順序の一覧ではなく、独立したTask同士の順序は固定ではありません。applicationでは配布物のTaskも加わります。

このTaskは何をしている?

Task役割
compileJavaメインのJavaソースをコンパイルする。
processResourcesメインのリソースを出力先へコピーする。
classescompileJava・processResourcesをまとめ、メインのクラスとリソースを揃える。
jarメインのクラスとリソースをJARにまとめる。
assemblejarなど、成果物を組み立てるTaskをまとめる。
compileTestJavaテスト用Javaソースをコンパイルする。
processTestResourcesテスト用リソースを出力先へコピーする。
testClassescompileTestJava・processTestResourcesをまとめ、テストのクラスとリソースを揃える。
testテストを実行する。
checktestなどの検証Taskをまとめる。
buildassembleとcheckをまとめ、作成と検証を実行対象にする。

薄緑の4つと濃緑のbuildは、いずれも「まとめるTask」です。通常は自分でコンパイル等をせず、依存するTaskを実行対象にします。濃緑は全体の入口を強調したもので、別種のTaskという意味ではありません。

04EclipseとPowerShellで確認する

EclipseのGradle Tasksでbuild・assemble・check・cleanを探します。Task一覧は端末の tasks --all、testの説明と利用できるオプションは help --task test で確認できます。次はSampleAppのルートで、同じbuildを3つの方法で比べます。

PowerShell / SampleAppのルートで
# 通常のビルド
.\gradlew.bat build

# 実行計画に含まれるTaskを確認
.\gradlew.bat build --dry-run --console=plain

# Taskごとの実行状況を詳しく確認
.\gradlew.bat build --console=verbose
Wrapperに渡す指定何をする?・何を見る?
buildビルド・テスト等を実際に実行対象にする。成功・失敗と末尾の集計を確認。
build --dry-run --console=plainTaskの処理を行わず、実行計画を装飾のないテキストで表示。Task名を図と照合。
build --console=verbose実際にビルドし、Task名と実行状況を詳しく表示。UP-TO-DATEやNO-SOURCEも確認。

通常のbuildでは、端末やコンソール表示の設定によってTask名が省略される場合があります。表示されないことは「Taskが動いていない」という意味ではありません。最後のverboseコマンドをもう一度実行し、入力・出力が変わらないTaskの UP-TO-DATE を確認しましょう。この章にはテストソースがないので、testは NO-SOURCE です。

dry-runの :compileJava SKIPPED は、実行計画の確認のためTaskの処理を行っていないという意味です。コンパイルやテストが成功した証拠ではありません。先頭の : はこのプロジェクトのTaskパスです。applicationの配布用Taskなど、図で省略した名前も表示されます。観察した並びを、独立したTask同士の固定的な実行順序とは考えません。

TASK LAB / 概念シミュレーター

このシミュレーターはGradleを実行しません。ソースとテストが揃った状態の代表的なTaskに絞った模式例です。実際のTask数・表示順序・実行結果は環境や設定で変わり、この並びはすべてのTask間の厳密な実行順序を保証しません。実際にはUP-TO-DATEやNO-SOURCEもあり、手元のSampleAppは第8章までtestがNO-SOURCEです。

キャッシュと表示は別の話です。Reusing configuration cache. / Configuration cache entry reused. は、ビルド設定の結果を再利用したという意味です。UP-TO-DATE はTaskの入力・出力の状態から処理を省略できる状態、--console はログの表示方法です。設定を再利用しても必要なTaskは実行されます。末尾が 3 executed なら3個のTaskの処理が実際に行われています。

Gradle 9.6.0で確認した表示(実測ログの抜粋)

第6章のApplication Plugin・Java 11・テストソースなしの状態で、Kotlin/Groovy両DSLを確認しました。以下はbuild後に build --console=verbose を実行したログから、色・進捗表示と一部の行を省いたものです。この順序は今回の観察結果です。

両DSLで確認した実測抜粋 / 2026年10月12日
Reusing configuration cache.
…(中略)
> Task :compileJava UP-TO-DATE
> Task :classes UP-TO-DATE
> Task :compileTestJava NO-SOURCE
…(中略)
> Task :test NO-SOURCE
…(中略)
5 actionable tasks: 5 up-to-date
Configuration cache entry reused.

検証端末の通常buildではTask名が表示され、rich表示では省略されました。dry-runは14個のTaskをSKIPPEDで表示しましたが、末尾のactionable tasksの集計は全Task数ではありません。また、Javaソースだけを変更した別の実測では、設定キャッシュを再利用しながら 1 executed, 4 up-to-date となり、compileJavaが実行されました。件数や並びは手元の結果と同じとは限りません。

05何が変わった?

Taskが存在することと、処理するソースがあることは別です。第8章まではテストソースがないため、通常のbuildを実行してもtestは NO-SOURCE になります。次はdry-runではなく、verboseで実作業を頼んだ場合に読み取る表示例です。

表示例今回の処理をどう読む?
:test NO-SOURCE処理対象のテストがない。成功表示があっても、テストを実施した意味ではない。
:compileJava UP-TO-DATE入力・出力が前回から変わっておらず、コンパイルを省略した。
:compileJava FROM-CACHEビルドキャッシュが有効で一致する結果がある場合、再コンパイルせず結果を復元した。毎回出る表示ではない。

変更前後で設定は同じです。buildとtestでは対象のTaskが違い、buildにcleanは含まれません。clean は通常、このプロジェクトのbuild/を削除します(ソースは残ります)。生成物からやり直す必要があるときだけ clean build を使います。

06 / 確認できたら次へ

dry-runで実行計画、verboseで実行状況を確認できる。buildとrunの違い、buildにcleanが含まれないこと、今のtestがNO-SOURCEであることを説明できたら第7章へ。

この章の公式資料:Java Plugin / Taskとコマンド / Application Plugin / Taskの実行結果

07

HANDS-ON / SAMPLEAPPを育てる

外部ライブラリを使いたい

01今回やりたいこと

小文字のgradleを渡しても、先頭を大文字にして挨拶したい。Commons Lang 3.20.0のStringUtilsを使います(Java 8以上に対応するため、Java 11で利用できます)。

02今、何が足りない?

外部ライブラリの取得先と依存の指定がなく、Javaコードもそのライブラリをまだ呼んでいません。

03どこを変更する?

build.gradle.kts の既存のplugins・application・Toolchain 11・versionは残し、末尾に次を追加します。ここで初めてrepositoriesとdependenciesを使います。

build.gradle.kts第5章の設定の末尾へ追加
repositories {
    mavenCentral()
}

dependencies {
    implementation("org.apache.commons:commons-lang3:3.20.0")
}
repositories取得先dependencies部品・版・用途compile / runJavaから利用

04Eclipseで操作する

  1. Eclipseでbuildファイルへ上の2ブロックを追加。
  2. 保存(Ctrl+S)し、SampleAppを右クリック → Gradle → Refresh Gradle Project。同期が終わるまで待ちます。
  3. src/main/java/guide/Greeting.java を次の全文へ置き換えて保存。入力も Gradle から gradle へ変わることを確認します。
Greeting.java / 変更後の全文
package guide;

import org.apache.commons.lang3.StringUtils;

public class Greeting {
    public static String message(String name) {
        return "Hello, " + StringUtils.capitalize(name) + "!";
    }

    public static void main(String[] args) {
        System.out.println(message("gradle"));
    }
}
PowerShell / プロジェクトのルートで
.\gradlew.bat run
.\gradlew.bat dependencies --configuration runtimeClasspath
.\gradlew.bat dependencyInsight --dependency commons-lang3 --configuration runtimeClasspath

dependencies は依存の一覧、dependencyInsight は指定した依存の経路と版が選ばれた理由を表示します。--configuration runtimeClasspath で実行時の依存に絞り、後者は --dependency commons-lang3 で調査対象も絞ります。表示された版が3.20.0かを確認します。

05何が変わった?

変更前変更後・観察すること
小文字を渡すとそのまま小文字で返す。外部ライブラリなし。小文字のgradleから Hello, Gradle! を表示。Commons Lang 3.20.0が依存として解決される。

mavenCentral() は取得先、implementation は本番コードの実装で利用する依存です。座標は group:artifact:version。宣言だけでJavaの動きは変わりません。コードで実際に呼び出して初めて機能が変わります。

第7章終了時点のbuildファイル全文
build.gradle.ktsこの章の終了時点 / 全文
plugins {
    application
}

application {
    mainClass = "guide.Greeting"
}

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(11)
    }
}

version = "1.0"

repositories {
    mavenCentral()
}

dependencies {
    implementation("org.apache.commons:commons-lang3:3.20.0")
}
06 / 確認できたら次へ

小文字の入力で挨拶が変わり、依存一覧で3.20.0を確認できたら第8章へ。

この章の公式資料:依存関係 / 依存の調査

08

HANDS-ON / SAMPLEAPPを育てる

単体テストを実行したい

01今回やりたいこと

「gradleを渡すとHello, Gradle!が返る」を自動で確かめます。

02今、何が足りない?

test Taskはありますが、テストソースがないのでNO-SOURCEです。JUnitと実行設定もまだありません。JUnit 5.13.4はJava 8以上に対応し、今回のtestは既存のToolchainに従ってJDK 11で実行します。

03どこを変更する?

JUnitは複数の関連モジュールからできています。版を一つずつ指定すると手間がかかり、組み合わせが合わなくなることもあります。そこで、関連部品の推奨バージョンをまとめた BOM(Bill of Materials) を使います。「揃える」は、すべて同じ番号にする意味ではありません。

build.gradle.kts の既存の dependencies を次の形にします。Commons Langを残し、testImplementationの2行とtestRuntimeOnlyの1行を追加します。dependenciesブロックをもう一つ作る必要はありません。

build.gradle.kts変更後のdependencies全体 / 左線と背景色の3行が追加分
dependencies {
    implementation("org.apache.commons:commons-lang3:3.20.0")

    testImplementation(platform("org.junit:junit-bom:5.13.4"))
    testImplementation("org.junit.jupiter:junit-jupiter")
    testRuntimeOnly("org.junit.platform:junit-platform-launcher")
}

platform("org.junit:junit-bom:5.13.4") はBOMをバージョン管理情報として取り込み、そこにある指定を依存解決に使います。そのため、junit-jupiterとjunit-platform-launcherには個別の版を書かずに済みます。前者はテスト用の部品、後者は実行側の部品です。

対象はBOMに定義されたライブラリです。すべての依存の版を揃える機能ではなく、通常のplatformは絶対固定でもありません。他の依存指定との競合で最終的な選択が変わる場合があります。

次のtest設定は、dependenciesの閉じ括弧より後(ブロックの外)に置きます。useJUnitPlatform() はtestにJUnit Platformを使わせる指定です。

build.gradle.ktsdependenciesの閉じ括弧より後へ追加
tasks.test {
    useJUnitPlatform()
}

第3章の標準の約束により、src/test/java はGradle側でテスト用に設定済みです。Eclipseのソースフォルダー表示は別で、BuildshipのRefreshがGradleの構成を読み、IDEへ反映します。次のフォルダー作成後にもRefreshするのはこのためです。

04Eclipseで操作する

  1. Eclipseで上の設定を追加。保存(Ctrl+S)し、SampleAppを右クリック → Gradle → Refresh Gradle Project。同期が終わるまで待ちます。
  2. New → Folderで src/test/java を作り、Gradle Refresh。テスト用ソースとしての認識をJava Build Pathで確認します。
  3. src/test/java にPackage guide、Class GreetingTest を作り、下の内容へ置換して保存します。
  4. Gradle Tasksの test を実行。Eclipse独自のJUnit実行と混同せず、まずGradleの結果を見ます。
src/test/java/guide/GreetingTest.java / 全文
package guide;

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertEquals;

class GreetingTest {
    @Test
    void greetsWithCapital() {
        assertEquals("Hello, Gradle!", Greeting.message("gradle"));
    }
}
PowerShell / プロジェクトのルートで
.\gradlew.bat test
.\gradlew.bat test --tests "guide.GreetingTest.greetsWithCapital" --rerun-tasks

1行目の test はテストを実行します。2行目は --tests で指定したクラス・メソッドに絞り、--rerun-tasks で変更なしによる省略を避け、必要な先行Taskも含めてやり直します。結果は次のレポートで確認します。

05何が変わった?

変更前変更後・観察すること
test NO-SOURCE。テストは実行されていない。testが実行され、レポートは 1件・失敗0件。

build/reports/tests/test/index.html をブラウザで開きます。Eclipseでbuildフォルダーが見えなければ、OSのエクスプローラーからSampleAppを開いてください。XMLは build/test-results/test/ です。

失敗も一度体験:テストの期待値だけをHello, Wrong!へ変え、保存して再実行します。失敗のexpectedとactualを読み、Hello, Gradle!へ戻して再実行してください。UP-TO-DATEで省略される場合は上の--rerun-tasksを使います。

第8章終了時点のbuildファイル全文
build.gradle.ktsこの章の終了時点 / 全文
plugins {
    application
}

application {
    mainClass = "guide.Greeting"
}

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(11)
    }
}

version = "1.0"

repositories {
    mavenCentral()
}

dependencies {
    implementation("org.apache.commons:commons-lang3:3.20.0")
    testImplementation(platform("org.junit:junit-bom:5.13.4"))
    testImplementation("org.junit.jupiter:junit-jupiter")
    testRuntimeOnly("org.junit.platform:junit-platform-launcher")
}

tasks.test {
    useJUnitPlatform()
}
06 / 確認できたら次へ

1件失敗する理由を確認し、元に戻して1件・失敗0件になったら第9章へ。

この章の公式資料:Javaのテスト / JUnit 5.13.4 / Java Plugin / BOMとplatform

09

HANDS-ON / SAMPLEAPPを育てる

Javaのバージョンを指定したい

01今回やりたいこと

第3章で指定したToolchain 11が、コンパイル・テスト・runに使われているかを確認します。

02今、何が足りない?

Gradleの起動Javaとアプリ用Javaは別です。--versionに25と出ても、アプリを25でコンパイルしているとは限りません。今回は起動用25、アプリ用11という役割を実行ログで区別します。

03どこを変更する?

設定は追加しません。SampleAppの build.gradle.kts に第3章からの次のブロックがあることを確認します。二重に書かないでください。

build.gradle.kts第3章から設定済み / 追加不要
java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(11)
    }
}

04Eclipseで操作する

  1. ToolchainのlanguageVersionが11であることを確認。保存(Ctrl+S)し、SampleAppを右クリック → Gradle → Refresh Gradle Project。同期が終わるまで待ちます。
  2. 下のコマンドをSampleAppのルートで実行。Gradleの起動Javaと、コンパイル・テスト・runの使用Javaを別々に確認します。
  3. JDK 11が未検出なら第3章の補足へ戻ります。ログで11を使ったと確認できるまでは、成功表示だけで完了と判断しません。
PowerShell / プロジェクトのルートで
.\gradlew.bat --version
.\gradlew.bat -q javaToolchains
.\gradlew.bat compileJava --info --rerun-tasks
.\gradlew.bat test --info --rerun-tasks
.\gradlew.bat build
.\gradlew.bat run --info

javaToolchains は検出したJava環境の一覧です(-q は通常の進捗ログを抑制)。一覧にあるだけでは、選ばれた証拠にはなりません。--info で使用した実行ファイルを調べます。--rerun-tasks は変更なしによる省略を避け、今回のコンパイルやテストを観察するための指定です。

確認するもの今回の期待値ログ・確認場所
Gradle起動JDK 25--versionのLauncher JVMとDaemon JVM。BuildshipはJava home
compileJavaJDK 11のコンパイラーCompiling with toolchainの場所が第1章で確認したJDK 11の場所
testJDK 11で実行、1件・失敗0件Gradle Test Executorを起動するCommandのjava.exeのパスとテストレポート
runJDK 11で実行、Hello, Gradle!Starting process / Commandのjava.exeのパスと挨拶
Eclipse本体IDEの起動に適したJavaを維持eclipse.iniの-vm等。アプリ用11とは別
Eclipseのアプリ言語レベル11・実行JRE 11Java Compiler・JRE System Library・Java Applicationの実行構成

ログ表記は環境で変わります。testがUP-TO-DATEなどで省略された場合は、再実行してJavaプロセスの起動行を確認します。必要なら表示されたjava.exeをフルパスで -version 実行して11か照合してください。

生成した.classがJava 11向けか確かめる
Windows PowerShell / この枠はWindows用
& "$lessonJdk11\bin\javap.exe" -verbose .\build\classes\java\main\guide\Greeting.class | Select-String "major version"

第1章と同じPowerShellで実行し、major version: 55 を確認します。端末を開き直した場合はlessonJdk11を自分のJDK 11の場所に再設定します。classの形式だけでは、テストやrunの実行Javaまで分からないため、上のログも確認します。

05何が変わった?

変更前変更後・観察すること
Toolchain 11は設定済みだが、実際の使用Javaは未確認。Gradleは25、コンパイル・テスト・runは11とログで区別できる。

Project Propertiesでは、何を設定する?

  1. Window → Preferences → Java → Installed JREs → Add… → Standard VM で、JRE homeにJDK 11の場所を登録します。既存のJDK 25を削除したり、Eclipse本体の起動設定を変えたりしません。
  2. Gradle Refresh後、SampleAppの Properties → Java Build Path → Libraries でJRE System LibraryがJavaSE-11(またはJDK 11)、Java Compiler で準拠レベルが11か確認します。JavaSE-11の対応先は Preferences → Java → Installed JREs → Execution Environments で登録したJDK 11と照合します。
  3. 11にならないときは、保存済みのToolchain、GradleによるJDK 11の検出、Buildshipの同期結果を確認して再Refreshします。Java Build Pathだけを25から書き換えて解決したことにしません。
  4. Run → Run Configurations… → Java Application でGreetingの構成を選び、JRE → Alternate JRE に登録したJDK 11を指定してApply → Run。構成がなければJava Applicationで新規作成し、Project=SampleApp、Main class=guide.Greetingを指定します。
  5. GradleのImport / Properties → GradleのJava homeはJDK 25を維持します。EclipseのJava CompilerはIDE側のコンパイル設定であり、GradleのJDK 11のjavacそのものを呼ぶ設定ではありません。

Gradleのビルドに必要な設定は、基本的にGradle側へ。Eclipseだけの編集・表示設定は、Eclipse側へ。まずこの2つに分けて考えます。

設定したいこと基本的に変更する場所
外部ライブラリの追加build.gradle.kts の dependencies
アプリのコンパイル・test・run用Javabuild.gradle.kts のToolchain 11
Gradle本体の起動JavaJAVA_HOMEやBuildshipのJava home(今回はJDK 25)
フォーマッターの変更Eclipseの設定
エディター表示の変更Eclipseの設定

Eclipseの自動ビルドやエラー表示は引き続き使えますが、Gradleのbuildとは別です。Gradle側を変更したら保存し、Refresh Gradle Project でEclipseへ反映します。Java Build Path で内容を確認できますが、Gradle管理の項目をEclipse側だけで変えてもGradleのビルド定義には反映されません。

設定が食い違うときだけ:コンパイラー・同期・起動Java

EclipseのコンパイルはIDEのJava Compiler設定、Gradleのコンパイルはビルド定義を使います。一方が常に他方より優先される関係ではありません。Toolchainを指定してもEclipseのコンパイラー自体が選んだJDKのコンパイラーへ置き換わるわけではありません。

BuildshipはGradleから取得したソース・依存・言語レベル・JRE等の管理対象を同期します。反映範囲は版や構成によります。すべてのProject Propertiesを上書きするわけではなく、Eclipse固有の警告・編集設定もあります。

Gradleを動かすJavaとToolchainも別です。端末のJAVA_HOMEだけで決まるとは限らず、BuildshipのJava home、org.gradle.java.home、Daemon JVM criteria等も確認します。起動に使われたJavaは --version、コンパイル用JDKは compileJava --info で確かめます。

4つの操作を使い分ける

操作何をする?/何を見る?
Eclipse:Project → Build Automatically保存した変更をEclipseのビルダーで処理する。Javaのエラー表示やIDE側の出力を確認する。
Eclipse:Project → Clean…選んだプロジェクトのIDE側のビルド状態・生成物をリセットし、全体をビルドし直す準備をする。再ビルドは自動ビルド等の設定に従う。
Gradle → Refresh Gradle ProjectGradleの構成を読み、依存やソース等をEclipseへ同期する。Java Build Pathなどへの反映を確認する。
.\gradlew.bat clean buildGradleの出力を削除し、成果物作成と検証をやり直す。Gradle Console/端末とbuild/の結果を確認する。

EclipseのCleanとGradleのcleanは同じ処理ではありません。Refreshもbuild Taskを頼む操作とは異なります。Buildship・Eclipseの版や、追加ビルダー・同期時Task等の設定によって、付随する処理が動く場合はあります。

起動も区別:Run As → Java Application はIDEの実行設定・classpathを使います。Gradleの run はApplication PluginのTaskで、mainClassや実行時依存等の設定を使います。同じmainでも、JDK・引数・環境変数等が一致するとは限りません。

小さな確認演習:保存したときと、Gradleを実行したとき

今のSampleAppを使います。ライブラリやPluginは増やしません。

  1. Eclipseの Project → Build Automatically がオンか確認し、Java Build Path → Source でIDE側の出力先を確認します。
  2. Greeting.javaのmain内の文末のセミコロンを一時的に外して保存し、Problemsビューのエラーを観察します。すぐセミコロンを戻して保存し、ビルド終了後にエラーが消えることと、IDE側の出力先のGreeting.classを確認します。ここではGradleのTaskを手動実行していません。
  3. この章の compileJava --info --rerun-tasks をWrapperからもう一度実行します。今回はGradleがコンパイルします。ログのJDKと build/classes/java/main/guide/Greeting.class を確認します。
  4. 第3章で設定したToolchain 11を維持し、buildファイルを変更した場合は保存して Refresh Gradle Project で同期します。最後にtest・build・runの結果を確認し、Javaソースは元の状態で次章へ進みます。
第9章終了時点のbuildファイル全文
build.gradle.ktsこの章の終了時点 / 全文
plugins {
    application
}

application {
    mainClass = "guide.Greeting"
}

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(11)
    }
}

version = "1.0"

repositories {
    mavenCentral()
}

dependencies {
    implementation("org.apache.commons:commons-lang3:3.20.0")
    testImplementation(platform("org.junit:junit-bom:5.13.4"))
    testImplementation("org.junit.jupiter:junit-jupiter")
    testRuntimeOnly("org.junit.platform:junit-platform-launcher")
}

tasks.test {
    useJUnitPlatform()
}
06 / 確認できたら次へ

Gradle起動は25、コンパイル・test・runは11とログで確認し、テスト1件・失敗0件、buildとrunが成功したら第10章へ。

この章の公式資料:Toolchain / Java互換表 / BuildshipのImport・操作 / EclipseのJava Builder / Eclipseのビルド操作 / Buildshipの同期とclasspath

10

HANDS-ON / SAMPLEAPPを育てる

複数プロジェクトに分けたい

01今回やりたいこと

今の挨拶アプリを、起動するappと、名前を整えるcommonの2つへ分けます。

02今、何が足りない?

これまではSampleApp一つに全部ありました。ここで初めて、参加するプロジェクトと、その間の依存を定義します。

03どこを変更する?

元のSampleAppを比較用に残すため、練習用の隣のフォルダー SampleSystem にコピーを作ります。SampleApp自体は変更しません。

第1〜9章はSampleApp、第10章からはSampleSystemが作業先です。OSのエクスプローラーでSampleAppと同じ親フォルダーに空のSampleSystemを作り、まず次のファイルだけを同じ相対位置へコピーします。

SampleAppからSampleSystemへコピーするファイル / 選択中のDSLに連動
  • SampleApp/
    • gradlew
    • gradlew.bat
    • gradle/
      • wrapper/
        • gradle-wrapper.jar
        • gradle-wrapper.properties
    • settings.gradle.kts
    • build.gradle.kts
    • gradle.properties

コピーしないもの:.gradle/、build/、.project、.classpath、.settings/。ドットなしの gradle/wrapper/ はWrapperの部品、ドット付きの .gradle/ は作業用データです。

この演習では版をbuildファイルに直接書くため、生成済みの gradle/libs.versions.toml は使いません。.gitignore・.gitattributes も演習の実行には不要なのでコピーしません。src/ は次の手順でコピーします。

  1. SampleSystemに app と common フォルダーを作成。SampleAppの src/ を SampleSystem/app/src/ へコピーし、テストも維持します。
  2. SampleSystem直下の settings.gradle.kts を下の内容へ置換。build.gradle.kts は下のコメントだけに置換します。appとcommonにそれぞれ build.gradle.kts を新規作成します。
settings.gradle.ktsコピー側のsettingsを置換
rootProject.name = "SampleSystem"
include("app", "common")
build.gradle.ktsコピー側ルートのbuildを置換
// 共通の作業はまだ定義しない
app/build.gradle.ktsappの設定を新規作成
plugins { application }
version = "1.0"
repositories { mavenCentral() }
java { toolchain { languageVersion = JavaLanguageVersion.of(11) } }
application { mainClass = "guide.Greeting" }
dependencies {
    implementation(project(":common"))
    testImplementation(platform("org.junit:junit-bom:5.13.4"))
    testImplementation("org.junit.jupiter:junit-jupiter")
    testRuntimeOnly("org.junit.platform:junit-platform-launcher")
}
tasks.test { useJUnitPlatform() }
common/build.gradle.ktscommonの設定を新規作成
plugins { id("java-library") }
repositories { mavenCentral() }
java { toolchain { languageVersion = JavaLanguageVersion.of(11) } }
dependencies {
    implementation("org.apache.commons:commons-lang3:3.20.0")
}

appはapplication、commonはライブラリを作るjava-libraryです。Commons Langはcommonの内部実装へ移し、appはcommonに依存します。include は参加者の登録、project(":common") は利用関係の指定です。

04Eclipseで操作する

  1. 第2章と同じImport手順で SampleSystem を取り込みます。WrapperとGradle起動用JDK 25を指定。app/commonのToolchainは両方11です。Refresh後は両ProjectのJRE System Library・Java Compilerと、appのJava Application実行構成も第9章と同じく11か確認。以後この章の作業先はコピー側です。
  2. appのGreeting.javaを下の全文へ置換。コピーしたGreetingTest.javaは変更しません。
  3. commonに src/main/java を作成してRefresh。Package guide、Class NameFormatterを作成し、下の全文を保存します。
  4. SampleSystemをGradle Refresh。端末もSampleSystemのルートへ移動して実行します。
app/src/main/java/guide/Greeting.java / 置換
package guide;

public class Greeting {
    public static String message(String name) {
        return "Hello, " + NameFormatter.format(name) + "!";
    }
    public static void main(String[] args) {
        System.out.println(message("gradle"));
    }
}
common/src/main/java/guide/NameFormatter.java / 新規
package guide;

import org.apache.commons.lang3.StringUtils;

public class NameFormatter {
    public static String format(String name) {
        return StringUtils.capitalize(name);
    }
}
:app起動とテスト利用する:common名前を整える部品

先に作業場所をSampleSystemへ切り替える

Eclipseで開く対象も、端末の作業場所も SampleSystem です。下の親フォルダーを自分の配置に置き換えて実行し、表示された現在位置の末尾がSampleSystemか確認します。

SampleSystemへ移動 / パスを自分の配置に置き換える
Set-Location 'C:\自分の練習用フォルダー\SampleSystem'
Get-Location

次にSampleSystem直下の settings.gradle.kts を開き、rootProject.name がSampleSystem、include の対象がappとcommonであることを確認します。両フォルダーもSampleSystem直下にあることを確かめてから、構成を表示します。

PowerShell / プロジェクトのルートでSampleSystemのルートで実行。SampleAppではない
.\gradlew.bat projects

projects は、今開いているGradleビルドに含まれるプロジェクト構成を表示するTaskです。ルートがSampleSystemで、子プロジェクト :app と :common が両方あることを確認します。

projectsで見えた内容次の操作
ルートSampleSystem、子にapp・common正しい構成。次の :app:build へ進む。
Root project SampleApp / No sub-projects元のSampleAppで実行している。現在位置を確認し、SampleSystemへ移動する。
Root project SampleSystem / No sub-projectssettings.gradle.kts のinclude指定と保存状態、app・commonフォルダーの配置を確認する。

上の表は出力の要点です。実際のログの書式とは異なります。フォルダーが欠けている場合は、一覧ではなくエラーになることもあります。

PowerShell / プロジェクトのルートでSampleSystemのルートで実行。SampleAppではない
.\gradlew.bat :app:build --info --rerun-tasks
.\gradlew.bat :app:run --info
.\gradlew.bat :common:dependencies --configuration runtimeClasspath

:app:build は、:app=ルート配下の子プロジェクトapp、build=そのTask名をコロンでつないだTaskパスです。必要なcommon側のTaskも依存関係に応じて実行対象になります。:app:run はappの起動、:common:dependencies はcommonの依存調査です。結果は対象Projectのbuild/やコンソールで確認します。今回は--infoでapp/common両方のコンパイル用JDK 11、appのテストとrunのjava.exeがJDK 11か照合します。--rerun-tasksは観察のための再実行指定です。

05何が変わった?

変更前変更後・観察すること
SampleApp一つのプロジェクト。SampleSystemのルートとapp・commonを区別。appのテスト1件・失敗0件、同じ挨拶が表示される。
分割後 / 主要ファイル
  • SampleSystem/
    • settings.gradle.kts
    • build.gradle.kts
    • gradlew / gradlew.bat / gradle/wrapper/
    • app/
      • build.gradle.kts
      • src/…
    • common/
      • build.gradle.kts
      • src/…

Eclipseに複数のプロジェクト名が見えるのは、それぞれがGradleの参加プロジェクトとして取り込まれるためです。以前見た SampleApp と lib のような表示も、ルートと子プロジェクトの構成なら同じ理由です。表示順・階層はビュー設定で変わります。

ルートbuildの設定は自動ではapp・commonへ継承されません。appの成果物・レポートは app/build/ にあります。commonのAPIに外部型を公開するときの api の使い分けは発展的な確認事項です。

06 / 確認できたら次へ

settingsの参加者とappの依存を別々に説明でき、コピー側のapp/commonを11でコンパイルし、appのテストとrunが11で成功したら第11章へ。元のSampleAppは第9章の状態で残します。

この章の公式資料:複数Project / Java Library Plugin / BuildshipのImport・操作

11

HANDS-ON / SAMPLEAPPを育てる

既存プロジェクトを読み、問題を調べる

01今回やりたいこと

初めて参加するGradleプロジェクトで、実行する場所と変更するファイルを自分で探します。

02今、何が足りない?

知っている設定でも、置かれた場所や指定された版は案件ごとに異なります。まず構成を読むための順番を決めます。

03どこを変更する?

最初は何も書き換えません。練習では第10章のSampleSystemを受け取った案件と見立てます。業務案件ではREADMEとチームの手順を優先し、教材の版へ勝手に変更しません。

PROJECT EXPLORER / ファイルを選ぶ

SampleSystem/

起動の入口を確かめる

Windowsはgradlew.bat、macOS / Linuxはgradlewを使います。gradle/wrapper内のJARとpropertiesも必要です。

04Eclipseで操作する

  1. Import前にREADMEとWrapperの版を読み、settingsの場所からルートを決めます。信頼できるプロジェクトであることを確認してからGradleを実行します。
  2. settingsで参加者、各buildでPlugin・依存・Toolchainを確認します。sampleの知識だけで全構成を決めつけません。
  3. EclipseへImportし、Gradle TasksとGradle Consoleを確認。依存を変更するなら、対象ソースが属するbuildファイルを選びます。
  4. 実践問題:commonの内部で使うライブラリの版を変える依頼が来ました。変更前に、対象ファイル、使うWrapper、確認するTaskとレポートの場所をメモしてください。
PowerShell / プロジェクトのルートで
.\gradlew.bat --version
.\gradlew.bat projects
.\gradlew.bat :app:tasks --all
.\gradlew.bat :common:dependencies --configuration runtimeClasspath
調査問題の答え

対象はcommonのbuildファイル。ルートのWrapperを使い、依存解決を確認して :app:test・:app:build・:app:runを実行します。レポートはapp/build/reports/tests/test/index.html。ルートbuildへ追記して済ませません。

ERROR CLINIC / 最初の一手を選ぶ

まず、何を確認しますか?

ログは学習用の抜粋・模式例です。実際の文言は版や状況で変わります。

05何が変わった?

この演習では--versionに25と出るのが正常で、アプリの11は各buildのToolchainと実行ログで確認します。構成確認だけではファイルは変わりません。失敗を見つけたら、失敗Task・最初の原因・ファイルと行番号を読みます。IDEとGradleでコンパイル結果が違うときは、下の compileJava --info や build --info の詳細ログで使用JDK等を調べ、Java Build PathやGradleの依存一覧と照合します。

Javaの版が合わない:調査の手がかり

まず見る:Gradleの起動設定・--version

候補:Gradle起動用Javaの取り違え。Toolchain not foundなら別の問題で、アプリ用JDK 11の場所・検出を第3章で確認する。

PowerShell / プロジェクトのルートで
.\gradlew.bat --version
.\gradlew.bat -q javaToolchains
.\gradlew.bat :app:compileJava --info --rerun-tasks
Pluginが見つからない:調査の手がかり

まず見る:エラーに出たbuildファイルと行番号

候補:IDの誤記、外部Pluginの版がない、Pluginの取得先に接続できない。通常のrepositoriesとは別の指定。

Pluginの設定を読む時点で失敗するなら、help --stacktrace でコンパイルせずに問題を再現し、例外の詳細から原因と設定箇所を探します。

PowerShell / プロジェクトのルートで
.\gradlew.bat help --stacktrace
依存ライブラリを取得できない:調査の手がかり

まず見る:Could not find / Could not resolveと、その後の検索先・原因

候補:版や名前の誤り、取得先不足、接続・プロキシ・認証、オフラインでキャッシュ不足。

取得できない部品を調べるため、dependencies --configuration compileClasspath でコンパイル時の依存を確認し、dependencyInsight で対象の版と経路を追います。

PowerShell / プロジェクトのルートで
.\gradlew.bat dependencies --configuration compileClasspath
.\gradlew.bat dependencyInsight --dependency commons-lang3 --configuration runtimeClasspath
コンパイルエラー:調査の手がかり

まず見る:失敗したcompileJavaと、最初のファイル名・行番号

候補:構文の誤り、依存不足、用途違い、参照するJava APIとToolchainの不一致。

PowerShell / プロジェクトのルートで
.\gradlew.bat compileJava --info
.\gradlew.bat dependencies --configuration compileClasspath
テスト失敗:調査の手がかり

まず見る:build/reports/tests/test/index.html

候補:実装の不具合、誤った期待値、テスト前提の不足。

PowerShell / プロジェクトのルートで
.\gradlew.bat test --tests "guide.GreetingTest" --rerun-tasks
Taskが存在しない:調査の手がかり

まず見る:実行したディレクトリ・settings・対象Projectのplugins

候補:名前の誤記、Pluginが未適用、対象Projectが違う。

PowerShell / プロジェクトのルートで
.\gradlew.bat projects
.\gradlew.bat tasks --all
Eclipseだけ通る:調査の手がかり

まず見る:対象のbuildファイル・Java Build Path・双方の使用Java

候補:IDEだけのJAR登録、Gradle設定が未同期、Javaの版の違い。

PowerShell / プロジェクトのルートで
.\gradlew.bat --version
.\gradlew.bat dependencies --configuration compileClasspath
.\gradlew.bat build --info
設定の書き方が違う場合

libs.xxxやpluginsのaliasは別ファイルを参照する書き方です。既存の定義元を辿ってから変更します。参照先の集約や共通化の詳しい方法は発展編へ進めます。

06 / 確認できたら次へ

構成・実行コマンド・変更候補・確認結果を説明でき、診断演習で根拠を選べたら第12章へ。

この章の公式資料:Taskとコマンド / 依存の調査 / BuildshipのImport・操作 / Java互換表

12

HANDS-ON / SAMPLEAPPを育てる

総合演習:最小構成から自力で育てる

01今回やりたいこと

第1章からの操作を、手順の全文を写さずに再現します。小文字を整えて挨拶するアプリを完成させましょう。

02今、何が足りない?

これまでは案内に沿って進めました。今度は必要な設定と変更箇所を自分で選び、結果から成功を判定します。

03どこを変更する?

既存のSampleAppとSampleSystemは残します。新しい空の練習用親フォルダーに、再び SampleApp を作ります。同名が競合しないよう、Eclipseは File → Switch Workspace → Other… で演習用の別ワークスペースを使います。開いている編集は先に保存してください。

CHANGE REQUEST

小文字のgradleから、Hello, Gradle!を返す。

Commons Lang 3.20.0を使い、JUnit 5.13.4で検証。成果物はSampleApp-1.0.jarとします。Gradle 9.6.0はJDK 25で起動し、アプリのコンパイル・テスト・runはJDK 11を使います。

04Eclipseで操作する

  1. 最小構成を生成し、Wrapperと基本Taskを確認。
  2. Eclipseへ同じフォルダーをImport。
  3. java Plugin・Toolchain 11・Greeting.javaを追加し、compileJavaを成功させる。
  4. applicationへ置換し、mainClassを指定してrun。
  5. version、取得先、Commons Lang依存を追加。Javaで名前の先頭を大文字にする。
  6. JUnitとテストを追加。期待値を一度変えて失敗を調べ、正しい期待値に戻す。
  7. 第9章の方法でコンパイル・test・runがJDK 11を使うログと、classのmajor version 55を確認。Gradle本体はJDK 25のまま。

0 / 8 完了(このページを閉じるとリセット)

ヒント1:最初に足すものを絞る

第1章はbasicだけ。Javaは第3章、mainの起動は第4章です。最初のbuildファイルへ完成形を貼ると、何が増えたか観察できません。

ヒント2:変更する場所を思い出す

pluginsはjavaからapplicationへ置換。repositoriesとdependenciesは末尾へ追加。JUnitの依存は既存dependenciesの内側、test設定とToolchainはその外側です。

解答・解説 / 自分の結果と照合する

空のフォルダーから第1→2→3→4→5→7→8章の順で育てれば、第8章末の状態になります。完成形は以下です。Toolchain 11は第3章から含まれ、第9章でも同じ設定を確認します。

build.gradle.ktsこの章の終了時点 / 全文
plugins {
    application
}

application {
    mainClass = "guide.Greeting"
}

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(11)
    }
}

version = "1.0"

repositories {
    mavenCentral()
}

dependencies {
    implementation("org.apache.commons:commons-lang3:3.20.0")
    testImplementation(platform("org.junit:junit-bom:5.13.4"))
    testImplementation("org.junit.jupiter:junit-jupiter")
    testRuntimeOnly("org.junit.platform:junit-platform-launcher")
}

tasks.test {
    useJUnitPlatform()
}
Greeting.java / 解答
package guide;

import org.apache.commons.lang3.StringUtils;

public class Greeting {
    public static String message(String name) {
        return "Hello, " + StringUtils.capitalize(name) + "!";
    }

    public static void main(String[] args) {
        System.out.println(message("gradle"));
    }
}
GreetingTest.java / 解答
package guide;

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertEquals;

class GreetingTest {
    @Test
    void greetsWithCapital() {
        assertEquals("Hello, Gradle!", Greeting.message("gradle"));
    }
}
PowerShell / プロジェクトのルートで
.\gradlew.bat test --rerun-tasks
.\gradlew.bat build
.\gradlew.bat run

05何が変わった?

確認合格の目安
テストbuild/reports/tests/test/index.htmlで1件・失敗0件
ビルドBUILD SUCCESSFULとbuild/libs/SampleApp-1.0.jar
起動JDK 11のrunで小文字の入力からHello, Gradle!
Javaの確認Gradle起動25、コンパイル・test・runが11。Greeting.classのmajor versionは55
説明何をしたいから、どの設定を追加・置換したか言える
06 / 確認できたら次へ

案内を見ずに設定を選び、Gradleは25、コンパイル・テスト・実行は11と確認できれば、基礎編は完了です。次に既存案件を見たときは第11章の調査順を使ってください。

この章の公式資料:Build Init / Application Plugin / Javaのテスト

NEXT NOTEBOOK

次の教材

基礎編は第12章で完了です。次は、目的に合わせて別教材へ進めます。

公式資料と、この教材の条件

確認日:2026年10月11日。演習はGradle 9.6.0をJDK 25で起動し、アプリはJDK 11でコンパイル・テスト・実行します。Commons Lang 3.20.0 / JUnit 5.13.4を固定して検証します。公式資料のcurrentは更新されるため、使用版との違いに注意してください。

Java 11対応後の検証と未検証事項(2026年10月11日)

WindowsでGradle 9.6.0をJDK 25から起動し、HTML掲載のKotlin・Groovy両DSLの設定を新しい検証用SampleAppへ第3章から順に適用しました。第3章のcompileJava、第4〜7章のbuild・run、第8〜9章のJUnit・build・run、第10章のapp/commonのビルドを実行しています。第12章の解答も第8章と同じ設定です。

--versionのLauncher JVMとDaemon JVMは25、コンパイルのtoolchainはJDK 11、テストとrunのjava.exeもJDK 11の場所であることをログで確認しました。両DSL・両構成ともJUnitテスト1件・失敗0件、Hello, Gradle!の表示に成功し、main・test・commonの.classのmajor versionは55でした。Commons Lang 3.20.0とJUnit 5.13.4の版は維持しています。

第1〜2章の生成・Importの手順、第6章の図、既存UIの操作処理とデザインを維持しました。今回の変更ではbasic生成をやり直さず、既存の9.6.0のWrapperから新しい検証用コピーを作成しています。

EclipseのJava Compiler・実行JREの確認手順は公式資料と照合しましたが、Eclipse / BuildshipでのImport・Refresh・Java Application実行は実機操作で未検証です。macOS/Linuxでの実行、file://直接表示、端末全体の通信切断、実際の印刷・PDF出力も未検証です。検証ブラウザはfile://を許可していません。

ブラウザでは960・1366・1440・1920pxの表示、DSL・OS切替、目次、折りたたみ、設定リーダー、Taskシミュレーター、ファイル探索、Java診断、演習チェックを確認しました。外部取得を禁止したローカルHTTPで単体コピーを表示し、ConsoleのJavaScriptエラーは検出されませんでした。

本文・図・操作機能は単一HTMLに内蔵されています。公式資料の参照、Gradleやライブラリの初回取得には通信が必要です。

印刷時は補足と解答を展開し、終了後に戻します。コードは選択中のDSL・OSで印刷します。図とシミュレーターは学習用の概念例で、実際の実行ログではありません。