Gradle User Guide

Version 2.2-20140924021627+0000

Translated by
Hayashi Masatoshi [FAMILY Given]
Sekiya Kazuchika [FAMILY Given]
Sue Nobuhiro [FAMILY Given]
Mochida Shinya [FAMILY Given]

製作著作 © 2007-2012 Hans Dockter, Adam Murdoch
Copies of this document may be made for your own use and for distribution to others, provided thatyou do not charge any fee for such copies and further provided that each copy contains thisCopyright Notice, whether distributed in print or electronically.

このドキュメントは、個人利用目的および第三者に配布するためにコピーして使用できます。ただし、印刷するにせよ電目次
翻訳版について
1. はじめに1.1. このユーザーガイドについて
2. 概要
2.1. 特長
2.2. なぜGroovyなのか?
3. チュートリアル
3.1. 始めてみよう
4. Gradleのインストール
4.1. 必要環境
4.2. ダウンロード
4.3. 解凍4.4. 環境変数
4.5. 正しくインストールされたことをテストする
4.6. JVMオプション
5. トラブルシューティング
5.1. トラブルに対処する
5.2. ヘルプを求めるには
6. ビルドスクリプトの基本
6.1. プロジェクトとタスク
6.2. Hello world
6.3. タスク定義のショートカット
6.4. ビルドスクリプトはコードです
6.5. タスクの依存関係
6.6. 動的なタスク
6.7. 既存のタスクを操作する
6.8. 略記法
6.9. 拡張タスクプロパティ
6.10. Antタスクの使用
6.11. メソッドの使用
6.12. デフォルトタスク
6.13. DAGによる設定
6.14. 次のステップは？
7. Javaクイックスタート
7.1. Javaプラグイン
7.2. 基本的なJavaプロジェクト
7.3. マルチプロジェクトのJavaビルド
7.4. 次のステップは？
8. 依存関係管理の基本
8.1. 依存関係の管理とは
8.2. 依存関係の宣言
8.3. 依存関係のコンフィグレーション
8.4. 外部依存関係
8.5. リポジトリ
8.6. アーティファクトの公開
8.7. 次のステップは？

9. Groovyクイックスタート
9.1. 基本的なGroovyプロジェクト
9.2. まとめ
10. Webアプリケーションクイックスタート
10.1. WARファイルのビルド
10.2. Webアプリケーションの実行
10.3. まとめ
11. Gradleのコマンドラインを使う
11.1. 複数のタスクを実行する
11.2. タスクを除外してビルドする
11.3. エラー発生時にビルドを継続する
11.4. タスク名の省略
11.5. ビルドスクリプトを指定して実行する
11.6. ビルドに関する情報を取得する
11.7. 空実行
11.8. まとめ
12. GradleのGUIを使う
12.1. Task Tree（タスク・ツリー）
12.2. Favorites（お気に入り）
12.3. Command Line（コマンドライン）
12.4. Setup（セットアップ）
13. ビルドスクリプトの記述
13.1. Gradleビルド言語
13.2. プロジェクトAPI
13.3. スクリプトAPI
13.4. 変数の宣言
13.5. Groovyの基本
14. 色々なチュートリアル
14.1. ディレクトリの作成
14.2. Gradleプロパティとシステムプロパティ
14.3. 外部のビルドスクリプトをプロジェクトに取り込む
14.4. 任意のオブジェクトを組み立てる
14.5. 外部スクリプトで任意のオブジェクトを組み立てる
14.6. キャッシング
15. タスク詳解
15.1. タスクの定義
15.2. タスクを配置する
15.3. タスクの設定を変更する
15.4. タスクに依存関係を追加する
15.5. Ordering tasks
15.6. タスクに説明書きを追加する
15.7. タスクの置き換え
15.8. タスクをスキップする
15.9. 更新されていないタスクをスキップする
15.10. タスクルール
15.11. Finalizer tasks
15.12. まとめ
16. ファイルを取り扱う
16.1. ファイルを参照する
16.2. ファイルコレクション

16.3. ファイルツリー
16.4. アーカイブの内容をファイルツリーとして使う
16.5. 入力ファイルセットを指定する
16.6. ファイルをコピーする
16.7. Syncタスクを使う
16.8. アーカイブを作成する
17. GradleからAntを使う
17.1. ビルドでのAntタスクとタイプの利用
17.2. Antビルドのインポート
17.3. Antプロパティとリファレンス
17.4. API
18. ロギング
18.1. ログレベルの選択
18.2. ログメッセージを書く
18.3. 外部ツールやライブラリからのログについて
18.4. Gradleがロギングするものを変更する
19. Gradleデーモン
19.1. デーモン入門
19.2. デーモンの再利用と期限切れ
19.3. 使い方とトラブルシューティング
19.4. デーモンの設定
20. ビルド環境
20.1. gradle.propertiesを使用したビルド環境の構築
20.2. プロクシ経由のWebアクセス
21. Gradleのプラグインについて
21.1. Types of plugins
21.2. プラグインの適用
21.3. Applying plugins with the plugins DSL
21.4. Finding community plugins
21.5. プラグインがすること
21.6. 規約
21.7. プラグインをさらに詳しく知るには
22. 標準Gradleプラグイン
22.1. 言語プラグイン
22.2. 試験的な言語プラグイン
22.3. 統合プラグイン
22.4. 試験的な統合プラグイン
22.5. ソフトウェア開発プラグイン
22.6. 試験的なソフトウェア開発プラグイン
22.7. ベースプラグイン
22.8. サードパーティプラグイン
23. Javaプラグイン
23.1. 使用方法
23.2. ソースセット
23.3. タスク
23.4. プロジェクトレイアウト
23.5. 依存関係の管理
23.6. 規約プロパティ
23.7. ソースセットの利用
23.8. Javadoc

23.9. Clean
23.10. リソース
23.11. CompileJava
23.12. Incremental Java compilation
23.13. テスト
23.14. Jar
23.15. アップロード
24. Groovyプラグイン
24.1. 使用方法
24.2. タスク
24.3. プロジェクトレイアウト
24.4. 依存関係の管理
24.5. Groovyクラスパスの自動設定
24.6. 規約プロパティ
24.7. ソースセットプロパティ
24.8. GroovyCompile
25. Scalaプラグイン
25.1. 使用方法
25.2. タスク
25.3. プロジェクトレイアウト
25.4. 依存関係の管理
25.5. scalaClasspathの自動設定
25.6. 規約プロパティ
25.7. ソースセットプロパティ
25.8. Fast Scala Compiler
25.9. 別プロセスでコンパイルする
25.10. インクリメンタルコンパイル
25.11. Eclipse Integration
25.12. IntelliJ IDEA Integration
26. War プラグイン
26.1. 使用方法
26.2. タスク
26.3. プロジェクトレイアウト
26.4. 依存関係の管理
26.5. 規約プロパティ
26.6. War26.7. カスタマイズ
27. Earプラグイン
27.1. 使用方法
27.2. タスク
27.3. プロジェクトレイアウト
27.4. 依存関係の管理
27.5. 規約プロパティ
27.6. Ear27.7. カスタマイズ
27.8. カスタムのディスクリプタファイルを使う
28. Jetty プラグイン
28.1. 使用方法
28.2. タスク
28.3. プロジェクトレイアウト
28.4. 依存関係の管理

28.5. 規約プロパティ
29. Checkstyleプラグイン
29.1. 使用方法
29.2. タスク
29.3. プロジェクトレイアウト
29.4. 依存関係の管理
29.5. 設定
30. CodeNarcプラグイン
30.1. 使用方法
30.2. タスク30.3. プロジェクトレイアウト
30.4. 依存関係の管理
30.5. 設定
31. FindBugsプラグイン
31.1. 使用方法
31.2. タスク
31.3. 依存関係の管理
31.4. 設定
32. JDependプラグイン
32.1. 使用方法
32.2. タスク
32.3. 依存関係の管理
32.4. 設定
33. PMDプラグイン
33.1. 使用方法
33.2. タスク
33.3. 依存関係の管理
33.4. 設定
34. The JaCoCo Plugin
34.1. Getting Started
34.2. Configuring the JaCoCo Plugin
34.3. JaCoCo Report configuration
34.4. JaCoCo specific task configuration
34.5. Tasks
34.6. Dependency management
35. Sonarプラグイン
35.1. 使用方法
35.2. マルチプロジェクトビルドの解析
35.3. カスタムソースセットの解析
35.4. Java言語以外の解析
35.5. カスタムSonarプロパティの設定
35.6. コマンドラインでSonarの設定を行う
35.7. タスク
36. The Sonar Runner Plugin
36.1. Sonar Runner version and compatibility
36.2. Getting started
36.3. Configuring the Sonar Runner
36.4. Specifying the Sonar Runner version
36.5. Analyzing Multi-Project Builds

36.6. Analyzing Custom Source Sets
36.7. Analyzing languages other than Java
36.8. More on configuring Sonar properties
36.9. Setting Sonar Properties from the Command Line
36.10. Controlling the Sonar Runner process
36.11. Tasks
37. OSGiプラグイン
37.1. 使用方法
37.2. 暗黙的に適用されるプラグイン
37.3. タスク
37.4. 依存関係の管理
37.5. 規約オブジェクト
37.6.
38. Eclipse プラグイン
38.1. 使用方法
38.2. タスク
38.3. 設定
38.4. 生成されたファイルをカスタマイズする
39. IDEAプラグイン
39.1. 使用方法
39.2. タスク
39.3. 設定
39.4. 生成するファイルのカスタマイズ
39.5. その他の注意事項
40. ANTLRプラグイン
40.1. 使用方法
40.2. タスク
40.3. プロジェクトレイアウト
40.4. 依存関係管理
40.5. 規約プロパティ
40.6. ソースセットプロパティ
41. プロジェクトレポートプラグイン
41.1. 使用法
41.2. タスク
41.3. プロジェクトレイアウト
41.4. 依存関係
41.5. 規約プロパティ
42. 通知プラグイン
42.1. 使用方法
42.2. 設定
43. ビルド通知プラグイン
43.1. 使用方法
44. The Distribution Plugin
44.1. Usage
44.2. Tasks
44.3. Distribution contents
45. アプリケーション プラグイン
45.1. 使用方法
45.2. タスク

45.3. 規約プロパティ
45.4. ディストリビューションに他のリソースを含める
46. The Java Library Distribution Plugin
46.1. Usage
46.2. Tasks
46.3. Including other resources in the distribution
47. Build Init Plugin
47.1. Tasks
47.2. What to set up
47.3. Build init types
48. Wrapper Plugin
48.1. Usage
48.2. Tasks
49. The Build Dashboard Plugin
49.1. Usage
49.2. Tasks
49.3. Project layout
49.4. Dependency management
49.5. Configuration
50. The Java Gradle Plugin Development Plugin
50.1. Usage
51. 依存関係の管理
51.1. はじめに
51.2. 依存関係管理のベストプラクティス
51.3. 依存関係のコンフィギュレーション
51.4. 依存関係の定義方法
51.5. 依存関係を使った作業
51.6. リポジトリ
51.7. 依存関係解決の仕組み
51.8. 依存関係解決処理の微調整
51.9. 依存関係のキャッシュ51.10. 推移的依存関係を管理するための戦略
52. アーティファクトの公開
52.1. はじめに
52.2. アーティファクトとコンフィギュレーション
52.3. アーティファクトの宣言
52.4. アーティファクトの公開
52.5. プロジェクトライブラリについての追記事項
53. Mavenプラグイン
53.1. 使用方法
53.2. タスク
53.3. 依存関係管理
53.4. 規約プロパティ
53.5. 規約メソッド
53.6. Mavenリポジトリとの相互作用
54. 署名プラグイン
54.1. 使用方法
54.2. 署名者の資格情報
54.3. 署名対象を指定する

54.4. 署名を公開する
54.5. POMファイルに署名する
55. Building native binaries
55.1. Supported languages
55.2. Tool chain support
55.3. Tool chain installation
55.4. Component model
55.5. Building a library
55.6. Building an executable
55.7. Tasks
55.8. Finding out more about your project55.9. Language support
55.10. Configuring the compiler, assembler and linker
55.11. Windows Resources
55.12. Library Dependencies
55.13. Native Binary Variants
55.14. Tool chains55.15. Visual Studio IDE integration
55.16. CUnit support
56. ビルドのライフサイクル
56.1. ビルドフェーズ
56.2. 設定ファイル
56.3. マルチプロジェクトのビルド
56.4. 初期化
56.5. シングルプロジェクトの設定と実行
56.6. ライフサイクルからの通知に応答する
57. マルチプロジェクトのビルド
57.1. クロスプロジェクト設定
57.2. サブプロジェクトの設定
57.3. マルチプロジェクトのビルド実行ルール
57.4. 絶対パスによるタスクの実行
57.5. プロジェクトとタスクのパス
57.6. 依存関係 - なんの依存関係？
57.7. プロジェクト依存関係
57.8. Parallel project execution
57.9. 分離されたプロジェクト
57.10. マルチプロジェクトのビルドとテスティング
57.11. Multi Project and buildSrc
57.12. プロパティとメソッドの継承
57.13. まとめ
58. カスタムタスクの作成
58.1. タスククラスのパッケージング
58.2. 単純タスクの作成
58.3. スタンドアロンプロジェクト
58.4. Incremental tasks
59. カスタムプラグインの作成
59.1. プラグインのパッケージング
59.2. シンプルなプラグインの作成
59.3. ビルドから入力を得る
59.4. カスタムタスクやプラグインでファイルを扱う
59.5. スタンドアロンプロジェクト

59.6. 複数のドメインオブジェクトの管理
60. ビルドロジックの体系化
60.1. プロパティとメソッドの継承
60.2. 設定のインジェクション
60.3. buildSrcプロジェクトのソースをビルドする
60.4. 別のGradleビルドを、現在のビルドから呼び出して実行する
60.5. ビルドスクリプトで外部ライブラリを使うときの依存関係設定
60.6. Antオプショナルタスクの依存関係
60.7. まとめ
61. 初期化スクリプト
61.1. 基本的な使い方
61.2. 初期化スクリプトを使う
61.3. 初期化スクリプトを記述する
61.4. 初期化スクリプトの外部依存関係
61.5. Init script plugins
62. Gradleラッパー
62.1. 設定
62.2. Unixファイルパーミッション
63. Embedding Gradle
63.1. Introduction to the Tooling API
63.2. Tooling API and the Gradle Build Daemon
63.3. Quickstart
64. Comparing Builds
64.1. Definition of terms
64.2. Current Capabilities
64.3. Comparing Gradle Builds
65. Ivy Publishing (new)65.1. The “ivy-publish” Plugin
65.2. Publications
65.3. Repositories
65.4. Performing a publish
65.5. Generating the Ivy module descriptor file without publishing
65.6. Complete example
65.7. Future features
66. Maven Publishing (new)66.1. The “maven-publish” Plugin
66.2. Publications
66.3. Repositories
66.4. Performing a publish
66.5. Publishing to Maven Local
66.6. Generating the POM file without publishing
A. Gradleサンプル集
A.1. サンプル customBuildLanguage
A.2. サンプル customDistribution
A.3. サンプル customPlugin
A.4. サンプル java/multiproject
B. 陥りがちな罠
B.1. Groovyスクリプトの変数
B.2. 設定フェーズと実行フェーズ

C. 機能のライフサイクル
C.1. 状態
C.2. 後方互換性ポリシー
D. Gradle コマンドライン
D.1. デーモン コマンドラインオプション:
D.2. システムプロパティ
D.3. 環境変数
E. IDE対応の現状と、IDEによらない開発支援
E.1. IntelliJ
E.2. Eclipse
E.3. IDEサポートなしでGradleを使う用語集 / Glossary
例目次
6.1. 初めてのビルドスクリプト
6.2. ビルドスクリプトの実行
6.3. タスク定義のショートカット
6.4. GradleタスクでGroovyを使う
6.5. GradleタスクでGroovyを使う
6.6. タスク間の依存関係を宣言する
6.7. 遅延評価のdependsOn - タスクがまだ宣言されていない場合
6.8. 動的なタスク定義
6.9. APIからタスクにアクセスする - 依存関係の追加
6.10. APIからタスクにアクセスする - アクションの追加
6.11. ビルドスクリプトのプロパティとして既存のタスクにアクセスする
6.12. 拡張プロパティをタスクに追加する
6.13. AntBuilderを使ってant.loadfileターゲットを実行する
6.14. メソッドを抽出してビルドロジックを整理する
6.15. デフォルトタスクの定義
6.16. 選択したタスクによって異なる結果を得る
7.1. Javaプラグインの使用
7.2. Javaプロジェクトのビルド
7.3. Mavenリポジトリの追加
7.4. 依存関係の追加
7.5. MANIFEST.MFのカスタマイズ
7.6. テスト用システムプロパティの追加
7.7. JARファイルの公開
7.8. Eclipseプラグイン
7.9. Javaの例 - 完全なビルドファイル
7.10. マルチプロジェクトビルド - 階層レイアウト
7.11. マルチプロジェクトビルド - settings.gradleファイル
7.12. マルチプロジェクトビルド - 共通設定
7.13. マルチプロジェクトビルド - プロジェクト間の依存関係
7.14. マルチプロジェクトビルド - 配布ファイル
8.1. 依存関係の宣言
8.2. 外部依存関係の定義
8.3. 外部依存関係定義のショートカット形式

8.4. Mavenセントラルリポジトリの使用
8.5. リモートMavenリポジトリの使用
8.6. リモートIvyリポジトリの使用
8.7. ローカルのIvyディレクトリを使う
8.8. Ivyリポジトリに公開する
8.9. Mavenリポジトリへの公開
9.1. Groovyプラグイン
9.2. Dependency on Groovy
9.3. Groovy用のビルドファイル（全体）10.1. Warプラグイン
10.2. JettyプラグインによるWebアプリケーションの実行
11.1. 複数のタスクの実行
11.2. タスクの除外
11.3. タスク名の省略
11.4. キャメルケースのタスク名を省略
11.5. ビルドスクリプトを指定してビルドするプロジェクトを選択する
11.6. プロジェクトディレクトリを使ってプロジェクトを選択する
11.7. プロジェクトに関する情報を取得する
11.8. プロジェクトに説明を添付する
11.9. タスクに関する情報を取得する
11.10. タスクレポートの内容を変更する
11.11. タスクに関してもっと多くの情報を取得する
11.12. タスクについて詳細なヘルプ情報を取得する
11.13. 依存関係の情報を取得する
11.14. 依存関係のレポートをコンフィギュレーションでフィルタする
11.15. 個別の依存関係に対する解析情報を取得する
11.16. プロパティに関する情報
12.1. GUIの起動
13.1. Projectオブジェクトへのアクセス
13.2. ローカル変数を使用する
13.3. 拡張プロパティを使用する
13.4. Groovy JDKのメソッド
13.5. プロパティアクセサ
13.6. カッコなしのメソッド呼び出し
13.7. マップリテラル、リストリテラル
13.8. メソッドのクロージャ引数
13.9. クロージャのdelegate
14.1. mkdirでディレクトリを作成する
14.2. gradle.propertiesでプロパティを設定する
14.3. 外部のビルドスクリプトファイルでプロジェクトの設定を行う
14.4. 任意のオブジェクトを組み立てる
14.5. 外部スクリプトで任意のオブジェクトを組み立てる
15.1. タスクを定義する
15.2. タスクを定義する - タスク名に文字列を使用
15.3. その他のタスク定義方法
15.4. タスクにプロパティとしてアクセスする
15.5. tasksコレクションからタスクにアクセスする
15.6. パスを使ってタスクにアクセスする

15.7. copyタスクの作成
15.8. タスクの設定 - 様々な方法
15.9. タスクの設定 - クロージャの使用
15.10. クロージャを伴うタスク定義
15.11. 別プロジェクトのタスクとの依存関係を定義する
15.12. taskオブジェクトを使った依存関係定義
15.13. クロージャを使った依存関係定義
15.14. Adding a 'must run after' task ordering
15.15. Adding a 'should run after' task ordering
15.16. Task ordering does not imply task execution
15.17. A 'should run after' task ordering is ignored if it introduces an ordering cycle
15.18. タスクに説明書きを追加する
15.19. タスクの上書き
15.20. 述語でタスクをスキップ
15.21. StopExecutionExceptionでタスクをスキップ
15.22. タスクの有効化と無効化
15.23. 生成タスク
15.24. タスクの入力と出力を宣言
15.25. タスクルール
15.26. ルールベース・タスクの依存関係
15.27. Adding a task finalizer
15.28. Task finalizer for a failing task
16.1. ファイルを参照する
16.2. ファイルコレクションの作成
16.3. ファイルコレクションを使う
16.4. ファイルコレクションを実装する
16.5. ファイルツリーを作成する
16.6. ファイルツリーを使う
16.7. アーカイブをファイルツリーとして使う
16.8. ファイルセットを指定する
16.9. ファイルセットを指定する
16.10. Copyタスクでファイルをコピーする
16.11. Copyタスクのコピー元と宛先を指定する
16.12. コピーするファイルを選択する
16.13. copy()メソッドで更新チェックせずにファイルをコピーする
16.14. copy()メソッドで更新チェックを実施してファイルをコピーする
16.15. コピー時にファイルをリネームする
16.16. コピー時にファイルをフィルタリングする
16.17. 入れ子構造のコピー仕様
16.18. Syncタスクで依存関係をコピーする
16.19. ZIPアーカイブの作成
16.20. ZIPアーカイブの作成
16.21. アーカイブタスクの設定 - カスタムアーカイブ名
16.22. アーカイブタスクの設定 - appendix & classifier
17.1. Antタスクの利用
17.2. Antタスクにネストされたテキストを渡す
17.3. Antタスクにネストされた要素を渡す
17.4. Antタイプの利用

17.5. カスタムAntタスクの利用
17.6. カスタムAntタスクに対するクラスパスの宣言
17.7. カスタムAntタスクと依存関係管理を併用
17.8. Antビルドのインポート
17.9. Antターゲットに依存するタスク
17.10. Antターゲットにふるまいを追加
17.11. Ant target that depends on Gradle task
17.12. Renaming imported Ant targets
17.13. Antプロパティの設定
17.14. Antプロパティの取得
17.15. Antリファレンスの設定
17.16. Antリファレンスの取得
18.1. ログに標準出力を使う
18.2. 自分でログメッセージを書く
18.3. SLF4Jでログを出力する
18.4. 標準出力のキャプチャ設定
18.5. タスク実行時の標準出力キャプチャ設定
18.6. Gradleがロギングするものを変更する
20.1. HTTPプロクシの設定
20.2. HTTPSプロクシの設定
21.1. プラグインの適用
21.2. Applying a script plugin
21.3. Applying a binary plugin
21.4. Applying a binary plugin by type21.5. 型でプラグインを適用する
21.6. Applying a community plugin
21.7. プラグインにより追加されたタスク
21.8. プラグインのデフォルトを変更する
21.9. プラグインの規約オブジェクト
23.1. Javaプラグインの使用
23.2. Javaソースレイアウトのカスタマイズ
23.3. ソースセットへのアクセス
23.4. ソースセットのソースディレクトリの設定
23.5. ソースセットの定義
23.6. ソースセットの依存関係定義
23.7. ソースセットのコンパイル
23.8. ソースセットのJARを生成
23.9. ソースセットのJavadocを生成
23.10. ソースセットのテストを実行
23.11. Filtering tests in the build script
23.12. JUnit Categories
23.13. Grouping TestNG tests
23.14. Creating a unit test report for subprojects
23.15. MANIFEST.MFのカスタマイズ
23.16. manifestオブジェクトの作成
23.17. 特定のアーカイブ用にMANIFEST.MFを分離
23.18. 特定のアーカイブ用にMANIFEST.MFを分離
24.1. Groovyプラグインの使用

24.2. Groovyソースレイアウトのカスタマイズ
24.3. Groovyプラグインの設定
24.4. Groovyテスト用の依存関係設定
24.5. 同梱のGroovyを使用する依存関係設定
24.6. Groovyをファイル依存関係で設定する
25.1. Scalaプラグインを使う
25.2. Scalaソースレイアウトのカスタマイズ
25.3. 製品コードに使うScalaへの依存関係の宣言
25.4. テストコードに使うScalaへの依存関係の宣言
25.5. Fast Scala Compilerを有効にする
25.6. メモリ設定の調整
25.7. Zincベースのコンパイラを有効にする
26.1. Using the War plugin
26.2. Customization of war plugin
27.1. Earプラグインの利用
27.2. Earプラグインのカスタマイズ
28.1. Using the Jetty plugin
29.1. Checkstyleプラグインの使用
30.1. CodeNarcプラグインの使用
31.1. FindBugsプラグインの使用
32.1. JDependプラグインの使用
33.1. PMDプラグインの使用
34.1. Applying the JaCoCo plugin
34.2. Configuring JaCoCo plugin settings
34.3. Configuring test task
34.4. Configuring test task
34.5. Using application plugin to generate code coverage data
34.6. Coverage reports generated by applicationCodeCoverageReport
35.1. Sonarプラグインの適用
35.2. Sonar接続設定のコンフィグレーション
35.3. Sonarプロジェクト設定のコンフィグレーション
35.4. マルチプロジェクトビルドにおけるグローバルコンフィグレーション
35.5. マルチプロジェクトビルドにおける共通のプロジェクトコンフィグレーション
35.6. マルチプロジェクトビルドにおけるプロジェクト個別コンフィグレーション
35.7. 解析対象の言語のコンフィグレーション
35.8. プロパティ文法の利用
35.9. カスタムソースセットの解析
35.10. Java言語以外の解析
35.11. カスタムグローバルプロパティ設定
35.12. カスタムプロジェクトプロパティ設定
35.13. カスタムのコマンドラインプロパティを実装する
36.1. Applying the Sonar Runner plugin
36.2. Configuring Sonar connection settings
36.3. Configuring Sonar runner version
36.4. Global configuration settings
36.5. Shared configuration settings
36.6. Individual configuration settings
36.7. Skipping analysis of a project36.8. Analyzing custom source sets
36.9. Analyzing languages other than Java
36.10. setting custom Sonar Runner fork options
37.1. OSGiプラグインの利用
37.2. OSGiのMANIFEST.MFファイルの設定
38.1. Eclipseプラグインの使用方法
38.2. classpath の一部を上書き
38.3. project の一部を上書き
38.4. 依存関係のエクスポート
38.5. 依存関係のエクスポート
38.6. XML のカスタマイズ
38.7. XML のカスタマイズCustomizing the XML
39.1. IDEAプラグインを使う
39.2. モジュールの部分的な上書き
39.3. プロジェクトの部分的な上書き
39.4. Export Dependencies
39.5. XMLをカスタマイズする
40.1. ANTLRプラグインの利用
40.2. ANTLRバージョン宣言
42.1. 通知プラグインを使用する
42.2. 通知プラグインの設定
42.3. 通知プラグインを使用する
43.1. ビルド通知プラグインの利用
43.2. 初期化スクリプトからビルド通知プラグインを使う
44.1. Using the distribution plugin
44.2. Adding extra distributions
44.3. Configuring the main distribution
45.1. Using the application plugin
45.2. Configure the application main class
45.3. Configure default JVM settings
45.4. 他タスクの出力をアプリケーションのディストリビューションに含める
45.5. ディストリビューションのファイルを自動的に作成する
46.1. Using the Java library distribution plugin
46.2. Configure the distribution name46.3. Include files in the distribution
49.1. Using the Build Dashboard plugin
50.1. Using the Java Gradle Plugin Development plugin
51.1. コンフィギュレーションの定義
51.2. コンフィギュレーションへのアクセス
51.3. コンフィギュレーションの設定変更
51.4. モジュール依存関係
51.5. アーティファクトオンリー記法
51.6. 分類子付きの依存関係
51.7. あるコンフィグレーションの内部を列挙する
51.8. クライアントモジュール依存関係 - 推移的な依存関係
51.9. プロジェクト依存関係
51.10. ファイル依存関係
51.11. 生成されるファイルへの依存関係

51.12. Gradle API依存関係
51.13. Gradleに同梱されているGroovyへの依存関係
51.14. 推移的な依存関係の除外
51.15. 依存関係のオプション属性
51.16. 依存関係定義のコレクション、配列
51.17. 依存するコンフィギュレーションの指定
51.18. 依存するプロジェクトのコンフィギュレーション
51.19. Configuration.copy
51.20. 宣言した依存関係にアクセスする
51.21. Configuration.files
51.22. フィルター付きConfiguration.files
51.23. Configuration.copy
51.24. Configuration.copy vs. Configuration.files
51.25. Declaring a Maven and Ivy repository
51.26. Providing credentials to a Maven and Ivy repository
51.27. Mavenセントラルリポジトリを追加する
51.28. BintrayのJCenter Mavenリポジトリを追加する
51.29. Using Bintrays's JCenter with HTTP
51.30. Mavenのローカルキャッシュをリポジトリとして追加する
51.31. カスタムMavenリポジトリを追加する
51.32. JARファイル用の追加リポジトリを設定する
51.33. パスワード保護されたMavenリポジトリへのアクセス
51.34. フラットディレクトリ・リゾルバ
51.35. Ivyリポジトリ
51.36. Ivy repository with named layout
51.37. パターンレイアウトを指定したIvyリポジトリ
51.38. Maven互換レイアウトのIvyリポジトリ
51.39. Ivy repository with pattern layout
51.40. Ivy repository with multiple custom patterns
51.41. Ivy repository with Maven compatible layout
51.42. パスワードで保護されたIvyリポジトリ
51.43. リポジトリ定義へのアクセス
51.44. リポジトリの設定変更
51.45. カスタムリポジトリの定義
51.46. あるグループのライブラリ全てで一貫したバージョンを使用するよう強制する
51.47. 独自のバージョニング体制を実装する
51.48. バージョンのブラックリスト指定と差し替
51.49. 解決時に依存関係のグループ名や名前を変更する
51.50. Declaring module replacement
51.51. 動的解決モードを有効にする
51.52. 'Latest' version selector
51.53. Custom status scheme
51.54. Ivy component metadata rule51.55. Component selection rule51.56. Component selection rule with module target
51.57. Component selection rule with metadata
51.58. 動的バージョンのキャッシュ制御
51.59. 変更性モジュールのキャッシュ制御

52.1. アーカイブタスクを使ってアーティファクトを宣言する
52.2. アーティファクトをファイルで宣言する
52.3. アーティファクトのカスタマイズ
52.4. ファイルでアーティファクトを宣言するMapスタイルの文法
52.5. アップロードタスクの設定
53.1. Mavenプラグインの利用
53.2. スタンドアロンPOMの生成53.3. リモートMavenリポジトリへのファイルアップロード
53.4. SSH経由でのファイルアップロード
53.5. pomのカスタマイズ
53.6. ビルダースタイルでpomをカスタマイズする
53.7. 自動生成された内容を変更する
53.8. Mavenインストーラーのカスタマイズ
53.9. 複数POMの生成53.10. マッピングコンフィグレーションへのアクセス
54.1. 署名プラグインの使用
54.2. コンフィグレーションに署名する
54.3. コンフィグレーションの出力に署名する
54.4. タスクを署名する
54.5. タスクの出力に署名する
54.6. 条件付き署名
54.7. Signing a POM for deployment
55.1. Defining a library component
55.2. Defining executable components
55.3. The components report
55.4. The 'cpp' plugin
55.5. C++ source set
55.6. The 'c' plugin
55.7. C source set
55.8. The 'assembler' plugin
55.9. The 'objective-c' plugin
55.10. The 'objective-cpp' plugin
55.11. Settings that apply to all binaries
55.12. Settings that apply to all shared libraries
55.13. Settings that apply to all binaries produced for the 'main' executable component
55.14. Settings that apply only to shared libraries produced for the 'main' library component
55.15. The 'windows-resources' plugin
55.16. Configuring the location of Windows resource sources
55.17. Building a resource-only dll
55.18. Providing a library dependency to the source set
55.19. Providing a library dependency to the binary
55.20. Declaring project dependencies
55.21. Defining build types
55.22. Configuring debug binaries
55.23. Defining platforms
55.24. Defining flavors
55.25. Targeting a component at particular platforms
55.26. Building all possible variants

55.27. Defining tool chains55.28. Reconfigure tool arguments
55.29. Defining target platforms
55.30. Registering CUnit tests
55.31. Registering CUnit tests
55.32. Running CUnit tests
56.1. シングルプロジェクトのビルド
56.2. 階層構造のレイアウト
56.3. フラットなレイアウト
56.4. プロジェクト・ツリーの属性を変更する
56.5. プロジェクトツリーの属性を変更する
56.6. 特定プロパティを持つプロジェクトにタスクを追加する
56.7. 通知56.8. すべてのタスクにプロパティ値を設定する
56.9. タスク実行の開始時および終了時にロギングを行う
57.1. マルチプロジェクト・ツリー - warter & bluewhale プロジェクト
57.2. water(親プロジェクト)のビルドスクリプト
57.3. マルチプロジェクトツリー - water, bluewhaleそしてkrill
57.4. Waterプロジェクトのビルドスクリプト
57.5. サブプロジェクト共通の振る舞いとすべてのプロジェクト共通の振る舞いをそれぞれ定義する
57.6. プロジェクト個別の振る舞いを定義する
57.7. krillプロジェクトに個別の振る舞いを定義する
57.8. プロジェクトに振る舞いを追加する(プロジェクト名によるフィルタリング)
57.9. プロジェクトに振る舞いを追加する(プロパティによるフィルタリング)
57.10. サブプロジェクトからビルドを実行する
57.11. プロジェクトの評価と実行
57.12. プロジェクトの評価と実行
57.13. 絶対パスによるタスクの実行
57.14. 依存関係とビルド実行順序
57.15. 依存関係とビルド実行順序
57.16. 依存関係とビルド実行順序
57.17. 依存関係を宣言する
57.18. 依存関係を宣言する
57.19. プロジェクトにまたがるタスク間の依存関係
57.20. 評価順序の依存関係
57.21. 評価順序の依存関係 - evaluationDependsOn
57.22. 評価順序の依存関係
57.23. 依存関係 - 実生活の例 - クロスプロジェクト設定
57.24. プロジェクト依存関係
57.25. プロジェクト依存関係
57.26. 細かい依存関係の制御
57.27. シングルプロジェクトのビルドとテスト
57.28. シングルプロジェクトの部分ビルドとテスト
57.29. 依存プロジェクトのビルドとテスト
57.30. 依存されているプロジェクトのビルドとテスト
58.1. カスタムタスクの定義
58.2. hello worldタスク
58.3. カスタマイズ可能なhello worldタスク

58.4. カスタムタスクのビルド
58.5. カスタムタスク
58.6. カスタムタスクを別のプロジェクトで使う
58.7. カスタムタスクのテスト
58.8. Defining an incremental task action
58.9. Running the incremental task for the first time
58.10. Running the incremental task with unchanged inputs
58.11. Running the incremental task with updated input files
58.12. Running the incremental task with an input file removed
58.13. Running the incremental task with an output file removed
58.14. Running the incremental task with an input property changed
59.1. カスタムプラグイン
59.2. カスタムプラグインのextension
59.3. コンフィグレーションクロージャ付きのカスタムプラグイン
59.4. ファイルプロパティの遅延評価
59.5. カスタムプラグインに対するビルド
59.6. カスタムプラグインに対するワイヤリング
59.7. 別のプロジェクトでカスタムプラグインを使う
59.8. Applying a community plugin with the plugins DSL
59.9. カスタムプラグインのテスト
59.10. Using the Java Gradle Plugin Development plugin
59.11. ドメインオブジェクトの管理
60.1. プロパティとメソッドの継承を使う
60.2. プロパティとメソッドのインジェクション
60.3. カスタムbuildSrcビルドスクリプト
60.4. buildSrcルートプロジェクトにサブプロジェクトを追加する
60.5. 別のビルドを呼び出す
60.6. ビルドスクリプトのクラスパスを宣言する
60.7. 外部ライブラリをビルドスクリプトで使用する
60.8. Ant optional dependencies
61.1. プロジェクト評価前に初期化スクリプトで追加的な設定を行う
61.2. 初期化スクリプトの外部依存関係定義
61.3. 外部依存関係を持つ初期化スクリプト
61.4. Using plugins in init scripts
62.1. ラッパータスク
62.2. ラッパーにより生成されるファイル
65.1. Applying the “ivy-publish” plugin
65.2. Publishing a Java module to Ivy
65.3. Publishing additional artifact to Ivy
65.4. customizing the publication identity
65.5. Customizing the module descriptor file
65.6. Publishing multiple modules from a single project65.7. Declaring repositories to publish to
65.8. Choosing a particular publication to publish
65.9. Publishing all publications via the “publish” lifecycle task
65.10. Generating the Ivy module descriptor file
65.11. Publishing a Java module65.12. Example generated ivy.xml

66.1. Applying the 'maven-publish' plugin
66.2. Adding a MavenPublication for a Java component
66.3. Adding additional artifact to a MavenPublication
66.4. customizing the publication identity
66.5. Modifying the POM file
66.6. Publishing multiple modules from a single project
66.7. Declaring repositories to publish to
66.8. Publishing a project to a Maven repository
66.9. Publish a project to the Maven local repository
66.10. Generate a POM file without publishing
B.1. 変数のスコープ：ローカルスコープとスクリプトスコープ
B.2. 設定フェーズと実行フェーズの区別

翻訳版について本ドキュメントは、Gradleユーザーガイドを非公式に日本語に翻訳したものです。翻訳作業は
g i t h u b 上 の プ ロ ジ ェ ク ト
で行っていますので、誤訳、不自然な点など発見されましたらプロジェクトサイト上からご連絡ください。
なお、原文は添付の代替スタイルシート(original)を使用すれば表示されます。

1
はじめに

Gradleは、Java(JVM)環境におけるビルドシステムであり、従来のビルド技術を大きく躍進させるものです。Gradleがあらゆる目的に使用できる汎用ビルドツールです。GradleはAntと同じような目的で使うことができます。

その一方でMavenのような規約によるビルドフレームワークを提供します。その規約も、気に入らないところは変マルチプロジェクトを強力にサポートします。
強力な依存関係管理 (Apache Ivy ベース)を提供します。
Maven/Ivyリポジトリを完全にサポートします。
リモートリポジトリやpom.xml、ivy.xmlを使用しなくても推移的な依存関係を管理できます。

Antのタスクとプロジェクトがファーストクラス・オブジェクトとして組み込まれており、デフォルトで使用可能でGroovyでビルドスクリプトを記述します。
ビルドを記述する際、オブジェクト指向のリッチなドメインモデルを使用可能です。
2章概要でGradleの概要について記述しています。 チュートリアルも用意しているので楽しんでいってください(^^)

1.1. このユーザーガイドについて

このユーザーガイドは、Gradle同様、現在活発に更新されているところです。まだGradleについて必要な部分がすべてまた、記載内容には明確でない部分やGradleについて読者が知っている以上の知識を要求する部分があるかもしれませ
このガイドを改良していくため、力を貸してください。
ドキュメンテーションへ参加、貢献していただける方はGradleのウェブサイトをご参照ください。
Throughout the user guide, you will find some diagrams that represent dependency relationships
between Gradle tasks. These use something analogous to the UML dependency notation, which
renders an arrow from one task to the task that the first task depends on.

Page 23 of 436

2
概要
2.1. 特長
Gradleの特長は以下の通りです。
宣言的なビルドの記述と規約によるビルド
Gradleの核となっているのは、拡張性豊富なGroovyベースのDSLです。

それは、好きなように組み立てて記述できる、ビルド用の宣言型プログラミング言語とも言えるものであり、従来

そのプログラミング言語には、JavaやGroovy、OSGi、WebそしてScalaなどのプロジェクトを一般的な方法でビル
さらに、このプログラミング言語はとても拡張性豊富なものです。

新たな言語機能を追加したり、既存の言語機能を拡張したりすることで、簡潔でメンテナンス性の良い、分かりや
タスクグラフ用のプログラミング言語
Gradleの提供する宣言型プログラミング言語は、グラフ構造をもつ汎用のタスク群の上に構築されています。

皆さんのビルドシステムには様々なニーズがあると思いますが、Gradleは、それらに適合できる、究極的な柔軟性
ビルドの構造化

Gradleは柔軟性があり機能が豊富なので、ビルドを記述する際にプログラミングにおける一般的な設計の原則を適
深いAPI
ビルドが実行されるライフサイクル全体に、たくさんのフックを埋め込むことができます。

なので、非常に深い部分までGradleの設定や振る舞いをモニタリングしたりカスタマイズしたりすることが可能でビルドの分割

Gradleでは、ビルドの分割を強力にサポートしています。このことは、単純なシングルプロジェクトでもエンター
マルチプロジェクトのビルド

Gradleは突出したマルチプロジェクトのサポートが特長です。プロジェクト間の依存関係はGradleのファーストク

Gradleでは部分ビルドが可能です。一つのサブプロジェクトをビルドすれば、Gradleはそのプロジェクトに依存し依存関係を管理する多くの方法

外部ライブラリの解決には、チームごとにさまざまな方法があるものです。リモートのMavenやIvyのリポジトリを
他のビルドツールとの統合

Gradleでは、Antのタスクはファーストクラス・オブジェクトです。さらにおもしろいことに、Antのプロジェクト

Gradleは、既存のMaven/Ivyリポジトリのインフラ、依存関係の定義や解決といった機能を完全にサポートしてい
p

o

m

.

x

m

l

をGradleのスクリプトに変換するコンバーターも用意されています。実行時にその変換を行う機能も近いうちに提Page 24 of 436

容易に移行可能

Gradleは、どんな構造のプロジェクトにも適用できます。なので、今製品のビルドを行っているブランチがあるな
GroovyGradleのビルドスクリプトはXMLではなくGroovyで記述します。しかし、それは単純に動的言語のスクリプト機能
Gradleラッパー

Gradleラッパーを使うと、Gradleをインストールしていないマシンでビルドを実行できます。たとえば、CIサーバ

administration)というアプローチでもあり、企業向けと考えてもとても面白いものだといえます。使用させるGrad
フリーかつオープンソース
Gradleはオープンソースプロジェクトであり、ASLのもとで公開されています。

2.2. なぜGroovyなのか?
ビ

ル

ド

ス

ク

リ

プ

ト

を記述するということを考えたとき、XMLに対する内部DSL(動的言語ベース)のアドバンテージというのは途方もなく
ただ、動的な言語はいくつかあるのに、なぜGroovyなのでしょうか。
その答えは、Gradleが想定しているシチュエーション、環境にあります。

Gradleは本質的に言えば一般的な利用が可能な汎用のビルドツールですが、メインとしてフォーカスしているのはJav
そのようなプロジェクトの場合、チームのメンバーがJavaに習熟しているのは明らかでしょう。
私 た ち は 、 ビ ル ド は す べ て のチームメンバーに対してできるだけ分かりやすいものであるべきだと考えています。
それならGroovyでなくJavaを使えばいいのにと思われるかもしれません。それはもっともな疑問です。

ビルド用の言語にJavaを使えば、開発チームにとって最高に分かりやすく、学習曲線が最小限緩やかなビルドとなるでしかし、Javaはビルド用の言語として使うには表現力や機能に限界があるのです。

[2]

このような用途には、PythonやGroovy、Rubyのような言語の方が向いています。
私たちは、Java世界の住人にとって断然飛び抜けた分かりやすさを提供するGroovyを選択しました。

Groovyの文法は、型システム、パッケージ構造、その他諸々についてJavaをベースにしています。Groovyはその上にJavaの開発者であっても、PythonやRubyの知識を持っていたり、それらを楽しく学んでいるのなら上記の議論は当て
Gradleはビルドスクリプト・エンジンとしてJRubyやJythonを使えるよう適切にデザインされています。
私達にとって、目下のところはそれらの優先度は高くありませんが。

私たちは、そういった追加のビルドスクリプトエンジンを作っていただけるあらゆるコミュニティを喜んでサポートし[2]

http://www.defmacro.org/ramblings/lisp.htmlに、AntとXML、Java、Lispを比較している興味深い記事が載っています。

「もしJavaがこの文法を持っていたら」という前提で書かれている構文が、まさにGroovyの文法になっているのが面白

Page 25 of 436

3
チュートリアル3.1. 始めてみよう
次のチュートリアルはGradleの基本機能を紹介しているものです。Gradleを始める手助けになるでしょう。
4章Gradleのインストール
Gradleのインストール方法について
6章ビルドスクリプトの基本
ビルドスクリプトの基本要素、 プロジェクト と タスク の紹介
7章Javaクイックスタート
Javaプロジェクトにおける、Gradleの規約によるビルドのチュートリアル
8章依存関係管理の基本
Gradleの依存関係管理のチュートリアル
9章Groovyクイックスタート
Groovyプロジェクトにおける、Gradleの規約によるビルドのチュートリアル
10章Webアプリケーションクイックスタート
Webアプリケーションプロジェクトにおける、Gradleの規約によるビルドのチュートリアル

Page 26 of 436

4Gradleのインストール
4.1. 必要環境
Gradleを使用するには、バージョン6以上のJava

JDKもしくはJREが必要です(java-versionで 確 認 し て く だ さ い ) 。

GradleにはGroovyライブラリが同梱されているので、別途Groovyをインストールする必要はありません。すでにイン
Gradleは、システムのパス上にあるJDKを使用します。

パス上のJDKの代わりに、環境変数

J A V A _ H O M EにJDKをインストールしたディレクトリをセットして、使用したいJDKを指定することもできます。

4.2. ダウンロード
Gradleはウェブサイトからダウンロードできます。

4.3. 解凍
Gradleの配布物はZIPで圧縮されています。Gradleのフルパッケージには以下のものが含まれています。
Gradleのバイナリ
ユーザーガイド(HTMLとPDF)
DSLのリファレンスガイド
APIドキュメント(JavadocとGroovydoc)

ユーザーガイドから参照されているサンプルを含め、大量のサンプルが同梱されています。複雑なビルドのサンプ

Gradleバイナリのソースコード。これは参照専用のものです。Gradleをビルドするには、ソースを別途ダウンロー
Gradleのウェブサイトを参照してください。

4.4. 環境変数
GRADLE_HOME /binを環境変数PATHに追加してください。Gradleの実行に必要な環境変数の設定は、通常これだけです。

Page 27 of 436

4.5.
正しくインストールされたことをテストする
G r a d l e は 、 g r a d l e
コマンドで実行します。Gradleが正しくインストールされていることを確認するには、gradle-vと入力してください。Gradleのバージョンとローカルの実行環境(groovyやjvmのバージョンなど)が表示されます。表4.6. JVMオプション
Gradle実行時に引き渡すJVMオプションは、環境変数 GRADLE_OPTS と JAVA_OPTS
で設定します。両方一緒に使うこともできます。

JAVA_OPTSに設定したオプションは、慣習により多くのJavaアプリケーションで共有されるものです。
典型的な例で言えば、HTTPプロキシはJAVA_OPTSに設定し、使用メモリに関する設定は
GRADLE_OPTSにセットする、といった使い分けが考えられるでしょう。

これらの設定はgradleや

gradlewスクリプトの頭に記述することもできます。
Note that it's not currently possible to set JVM options for Gradle on the command line.

Page 28 of 436

5
トラブルシューティング
この章は現在執筆途中です。

Gradleを使っていると（他のソフトウェアでも同じですが）、問題に突き当たる可能性が常にあります。

ある機能をどうやって使えばいいのか分からなかったり、バグに遭遇したりといった場合もありますし、FAQに頭を抱

この章ではトラブルシューティングのためのアドバイスや、突き当たった問題に対して手助けを求める方法について記

5.1. トラブルに対処する

何かトラブルが起こったとき、まず試すことができるのは、最新版のGradleを使ってみることです。Gradleの新バージGradleデーモンを使っているなら、一時的にデーモンを停止してみてください（--no--daemon
オプションをつけて実行）。

デーモン使用時のトラブルシューティングについて、詳しくは19章

Gradleデーモン を参照してください。

5.2. ヘルプを求めるには
Gradleに関して手助けを求めたいときは、http://forums.gradle.orgに行ってみましょう。

Gradleフォーラムでは、Gradleのデベロッパーやコミュニティメンバーに問題を報告したり、質問したりすることがで何か問題が発生したら、フォーラムに質問や報告を投げるのが最も早く手助けを得られる方法です。
フォーラムでは、改善のための提案や新しいアイデアを投稿することもできます。

また、Gradleの開発チームが頻繁にニュースやリリースのアナウンスを投稿していますので、Gradle開発の最前線に触Page 29 of 436

6
ビルドスクリプトの基本
6.1. プロジェクトとタスク
Gradleの根本にあるのは、 プロジェクト と タスク という二つの基本的な概念です。
Gradleによるビルドは、一つ以上の プロジェクトから構成されます。プロジェクトとは、ビルドされるソフトウェアを構成するコンポーネントのことですが、正確な意
それぞれのプロジェクトは、一つ以上の タスクから構成されます。タスクとは、分割不能な何らかの作業単位を表す概念です。たとえば、クラスをコンパイルしたりでは、実際にプロジェクト上でいくつか簡単なタスクを定義してビルドしてみましょう。マルチプロジェクトでのビル

6.2. Hello world
Gradleのビルドは、gradleコマンドで実行します。gradleコマンドはカレントディレクトリのbuild.gradle
ファイルを参照してビルドを行います。[4]このファイルは、一般的には ビルドスクリプトと呼ばれます(後述しますが、正確には「ビルドの設定を行うスクリプト」です)。Gradleのプロジェクトとタスクは、
次のようなスクリプトを、build.gradleという名前で作成して試してみてください。
例6.1 初めてのビルドスクリプト
build.gradle
task hello {doLast {println 'Hello world!'}}

コンソールを開いてこのbuild.gradleのあるディレクトリに移動して、gradle

-q

hello

と打ち込んでください。ビルドスクリプトが実行され、以下のように出力されるはずです。
例6.2 ビルドスクリプトの実行
gradle -q hello の出力> gradle -q hello
Hello world!

-q
オプションって何?
このユーザーガイドでは、ほぼすべての例で-qPage 30 of 436

何が起こったのでしょう。ビルドスクリプトは、hello

をつけてコマンドを実行しています。このオプシ

18章ロギングというタスクを一つ定義していて、このタスクにアクションを一つ追加しています。
にもっと詳しく記載されています。
gradlehelloと実行することで、Gradleがこのhello
を 実 行 し 、 h e l l oに追加したアクションが実行されたのです。アクションはGroovyコードを含む単なるクロージャです。

Antのtargetに似ているなと思われたかもしれません。実際、GradleのtaskはAntでいえばtargetに相当するものです。
t a s k と い う 言 葉 が 、 t a r g e tという言葉よりも実態に合った表現だと考えたためです。しかし、残念ながら taskという用語はAntでもcopyやjavac

といったコマンドを示すものとして使われており、Gradleのtaskと競合してしまいます。このため、Antのtaskについ
ant task と明示的にいい、単にtaskとしたときはGradleのタスクのことを示すものとします。

6.3. タスク定義のショートカット
タスク定義は、実際にはもっと短く書けます。先ほどのhello
タスクも、次のように簡潔に書くことができます。
例6.3 タスク定義のショートカット
build.gradle
task hello << {println 'Hello world!'}

この例も先ほどと同様、実行するクロージャを一つだけもったhelloを定義するものです。このユーザーガイドではこちらの定義方法を使用します。

6.4. ビルドスクリプトはコードです
GradleのビルドスクリプトではGroovyの機能をすべて使うことができます。手始めに次の例をご覧ください。
例6.4 GradleタスクでGroovyを使う
build.gradle
task upper << {String someString = 'mY_nAmE'
println "Original: " + someString
println "Upper case: " + someString.toUpperCase()}

gradle -q upper の出力> gradle -q upper
Original: mY_nAmEUpper case: MY_NAME

さらにPage 31 of 436

例6.5 GradleタスクでGroovyを使う
build.gradle
task count << {4.times { print "$it " }}gradle -q count の出力> gradle -q count0 1 2 36.5. タスクの依存関係
ご想像の通り、タスク間の依存関係を宣言できます。
例6.6 タスク間の依存関係を宣言する
build.gradle
task hello << {println 'Hello world!'}
task intro(dependsOn: hello) << {println "I'm Gradle"}

gradle -q intro の出力> gradle -q intro
Hello world!
I'm Gradle

依存関係にタスクを追加するときは、そのタスクがその時点で宣言されていなくてもかまいません。
例6.7 遅延評価のdependsOn - タスクがまだ宣言されていない場合
build.gradle
task taskX(dependsOn: 'taskY') << {println 'taskX'}
task taskY << {println 'taskY'}

gradle -q taskX の出力> gradle -q taskX
taskY
taskX

taskXが taskY に依存していることが宣言されていますが、宣言した時点では taskY

Page 32 of 436

の定義文はありません。このことは、マルチプロジェクトのビルドで非常に重要になってきます。タスク間の依存関係「タスクに依存関係を追加する」でさらに詳しく述べられています。
なお、未定義のタスクを参照する場合、略記法(「略記法」
参照)は使えませんので注意してください。

6.6. 動的なタスク

Groovyが力を発揮するのは、タスクが実行するアクションを記述するときだけではありません。たとえば、次のよう
例6.8 動的なタスク定義
build.gradle
4.times { counter ->task "task$counter" << {println "I'm task number $counter"}}

gradle -q task1 の出力> gradle -q task1
I'm task number 1

6.7. 既存のタスクを操作する

タスクが公開しているAPIを使えば、既存のタスクにアクセスして定義内容を操作することができます。これはAntと異例6.9 APIからタスクにアクセスする - 依存関係の追加
build.gradle
4.times { counter ->task "task$counter" << {println "I'm task number $counter"}}task0.dependsOn task2, task3

gradle -q task0 の出力> gradle -q task0
I'm task number 2
I'm task number 3
I'm task number 0

また、既存のタスクにアクションを追加することもできます。

Page 33 of 436

例6.10 APIからタスクにアクセスする - アクションの追加
build.gradle
task hello << {println 'Hello Earth'}
hello.doFirst {println 'Hello Venus'}
hello.doLast {println 'Hello Mars'}
hello << {println 'Hello Jupiter'}

gradle -q hello の出力> gradle -q hello
Hello Venus
Hello Earth
Hello Mars
Hello Jupiterd o F i r s t や d o L a s t

は何回でも呼び出すことができ、既存のタスクが実行する一連のアクションの最初や最後に、新しいアクションを追加<<はdoLastの単なるエイリアスです。

6.8. 略記法
先ほどの例をみたとき、おやっと思われたかもしれません。 既存のタスクにアクセスするときは、便利な略記法を使うことができます。ただのプロパティとしてすべてのタスクにアクセ
例6.11 ビルドスクリプトのプロパティとして既存のタスクにアクセスする
build.gradle
task hello << {println 'Hello world!'}
hello.doLast {println "Greetings from the $hello.name task."}

gradle -q hello の出力> gradle -q hello
Hello world!
Greetings from the hello task.

この略記法は、コードをとても読みやすいものにします。特に、プラグインなどで外部から提供されるタスク(たとえcompile)にアクセスするときには威力を発揮します。

Page 34 of 436

6.9. 拡張タスクプロパティ
独自のプロパティをタスクに追加することができます。例えば、myPropertyというプロパティを追加するには、 ext.myProperty に初期値を設定してください。
その時点で、このプロパティを定義済みのプロパティと同じように読み書きできるようになります。
例6.12 拡張プロパティをタスクに追加する
build.gradle
task myTask {ext.myProperty = "myValue"}
task printTaskProperties << {println myTask.myProperty}

gradle -q printTaskProperties の出力> gradle -q printTaskProperties
myValue

拡張プロパティを追加できるのは、タスクだけではありません。詳細については、「拡張プロパティ」を参照してください。

6.10. Antタスクの使用

AntのタスクはGradleのファーストクラス・オブジェクトであり、デフォルトで使用できるようになっています。Gro
AntBuilder が組み込まれているのです。Antのタスクは、 build.xml

で使うよりGradleで使ったほうが便利で強力です。次の例を見てください。Antのタスクを実行する方法やAntのプロ

Page 35 of 436

例6.13 AntBuilderを使ってant.loadfileターゲットを実行する
build.gradle
task loadfile << {def files = file('../antLoadfileResources').listFiles().sort()
files.each { File file ->if (file.isFile()) {ant.loadfile(srcFile: file, property: file.name)println " *** $file.name ***"
println "${ant.properties[file.name]}"}}}gradle -q loadfile の出力> gradle -q loadfile*** agile.manifesto.txt ***Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan*** gradle.manifesto.txt ***Make the impossible possible, make the possible easy and make the easy elegant.
(inspired by Moshe Feldenkrais)

Antのタスクを使ってできることはもっとたくさんあります。17章GradleからAntを使うをご参照ください。

6.11. メソッドの使用

Gradleでは、段階的にビルドロジックを体系化していくことができます。最初の一歩として、上の例をメソッドの抽出

Page 36 of 436

例6.14 メソッドを抽出してビルドロジックを整理する
build.gradle
task checksum << {fileList('../antLoadfileResources').each {File file ->ant.checksum(file: file, property: "cs_$file.name")println "$file.name Checksum: ${ant.properties["cs_$file.name"]}"}}task loadfile << {fileList('../antLoadfileResources').each {File file ->ant.loadfile(srcFile: file, property: file.name)println "I'm fond of $file.name"}}File[] fileList(String dir) {file(dir).listFiles({file -> file.isFile() } as FileFilter).sort()}

gradle -q loadfile の出力> gradle -q loadfile
I'm fond of agile.manifesto.txt
I'm fond of gradle.manifesto.txt

後でマルチプロジェクトの各プロジェクトでメソッドを共有する方法について学びます。それでもビルドロジックが複60章ビルドロジックの体系化)

6.12. デフォルトタスク
例6.15 デフォルトタスクの定義
build.gradle
defaultTasks 'clean', 'run'task clean << {println 'Default Cleaning!'}
task run << {println 'Default Running!'}
task other << {println "I'm not a default task!"}

gradle -q の出力> gradle -q
Default Cleaning!
Default Running!

Page 37 of 436

これは、gradle

clean

run

と入力するのと同じです。マルチプロジェクトのビルドでは、すべてのサブプロジェクトが個別にデフォルトタスクを

6.13. DAGによる設定
詳しくは56章ビルドのライフサイクル

で説明しますが、Gradleのビルドはいくつかのフェーズに分かれて実行されます。Gradleはどのタスクを実行するのか
次の例では、distributionタスクを実行するかreleaseタスクを実行するかでversion
変数に違う値を割り当てています。
例6.16 選択したタスクによって異なる結果を得る
build.gradle
task distribution << {println "We build the zip with version=$version"}task release(dependsOn: 'distribution') << {println 'We release now'}
gradle.taskGraph.whenReady {taskGraph ->if (taskGraph.hasTask(release)) {version = '1.0'} else {version = '1.0-SNAPSHOT'}}

gradle -q distribution の出力> gradle -q distribution
We build the zip with version=1.0-SNAPSHOT

gradle -q release の出力> gradle -q releaseWe build the zip with version=1.0
We release now

ここで大事なことは、releaseタスクが実行予定にあるという事実を、releaseタスクが実行される前に利用できる点でプライマリ タスク、つまりgradleコマンドに引き渡されているタスクでなくてもかまいません。

6.14. 次のステップは？

この章で、私たちは初めてタスクというものに触れました。しかし、タスクについての話はこれで全部ではありません
15章タスク詳解を見てみてください。
そうでなければ、7章Javaクイックスタートと8章依存関係管理の基本に進み、チュートリアルを続けてください。

Page 38 of 436

[4] この動作はコマンドラインスイッチを使用して変更できます。付録D Gradle コマンドライン
を参照してください。

Page 39 of 436

7Javaクイックスタート
7.1. Javaプラグイン

ここまで見てきたように、Gradleは汎用のビルドツールです。ビルドスクリプトで実装したいと思うようなものはほぼ

多くのJavaプロジェクトは、基本的な部分では非常に似通っています。つまり、Javaソースファイルをコンパイルし、
プ

ラ

グ

イ

ン

によってこの問題を解決します。プラグインは、何らかの方法（よくあるのは設定済みの一連の有用なタスクの追加）
J a v a プ ラ グ イ ンです。このプラグインは、Javaソースコードのコンパイルやユニットテスト、JARファイルの作成などを行うタスクをJavaプラグインは規約ベースです。すなわち、このプラグインはプロジェクトのさまざまな点、例えばJavaソースファ

Javaプラグイン、依存関係の管理、マルチプロジェクトのビルドについては、後の章で多くの実例付きで詳しく扱いま7.2. 基本的なJavaプロジェクト
シンプルな例から見ていきましょう。Javaプラグインを使うためには、ビルドファイルに以下を加えます：
例7.1 Javaプラグインの使用
build.gradle
apply plugin: 'java'

ノ

ー

ト

:

本例のソースコードは、Gradleのバイナリ配布物またはソース配布物に含まれています。以下の場所をご参照くだsamples/java/quickstart

Javaプロジェクトの定義に必要なのはこれだけです。これでプロジェクトにJavaプラグインが適用され、多くのタスク
Gradleは、製品のソースコードがsrc/main/javaに、テストのソースコードがsrc/test/javaにあることを想定しています。さらに、src/main/resources

どんなタスクが利用可能？

の下にあるファイルはすべてリソースとしてJARに入れられ、また g r a d l e
src/test/resourcestasksを使えば、プロジェクトのタスクを一覧すること

Page 40 of 436

にあるファイルはテスト実行時に使われるクラスパスに入れられます。すべての出力ファイルはbuildディレクトリの下に作られ、最終的にbuild/libs
ディレクトリにJARファイルが作られます。

7.2.1. プロジェクトのビルド

Javaプラグインはかなり多くのタスクをプロジェクトに追加します。しかし、プロジェクトをビルドするのに必要なタ
buildタスクです。gradle

buildを実行すると、Gradleはコードをコンパイルしてテストし、メインクラスやリソースを含んだJARファイルを生成しま
例7.2 Javaプロジェクトのビルド
gradle build の出力> gradle build:compileJava:processResources:classes:jar:assemble:compileTestJava:processTestResources:testClasses:test:check:buildBUILD SUCCESSFUL
Total time: 1 secs

他にも便利なタスクがあります：
cleanbuildディレクトリを削除し、ビルドしたすべてのファイルを削除します。
assemble

コードをコンパイルしJARを生成しますが、ユニットテストは実行しません。他のプラグインはこのタスクにより多check
Compiles and tests your code. Other plugins add more checks to this task. For example, if
you use the checkstyle plugin, this task will also run Checkstyle against your source code.

コードをコンパイルし、テストします。他のプラグインはこのタスクにより多くの検査項目を追加します。例えば

7.2.2. External dependencies
Usually, a Java project will have some dependencies on external JAR files. To reference these JAR
files in the project, you need to tell Gradle where to find them. In Gradle, artifacts such as JAR
files, are located in a repository . A repository can be used for fetching the dependencies of a
project, or for publishing the artifacts of a project, or both. For this example, we will use thepublic Maven repository:

Page 41 of 436

Javaプロジェクトは外部のJARファイルに依存することが普通です。プロジェクトで使うこういったJARファイルを参照
リ

ポ

ジ

ト

リ

に置かれます。リポジトリは、プロジェクトが依存するものを取得したり、プロジェクトのアーティファクトを公開し
例7.3 Mavenリポジトリの追加
build.gradle
repositories {mavenCentral()}

依存関係をいくつか追加してみましょう。製品クラスはコンパイル時にcommonsコレクションに依存し、テストクラ例7.4 依存関係の追加
build.gradle
dependencies {compile group: 'commons-collections', name: 'commons-collections', version: '3.2'
testCompile group: 'junit', name: 'junit', version: '4.+'}

詳しい説明は51章依存関係の管理 をご覧ください。

7.2.3. プロジェクトのカスタマイズ

Javaプラグインは多くのプロパティをプロジェクトに追加します。こういったプロパティには普通、十分適切なデフォ
manifestにいくつか属性を追加しています。
例7.5 MANIFEST.MFのカスタマイズ
build.gradle
sourceCompatibility = 1.5
version = '1.0'
jar {manifest {attributes 'Implementation-Title': 'Gradle Quickstart','Implementation-Version': version}}

Javaプラグインが追加するタスクはごく普通のタスクで、ビルドファイルで宣言されるものとまったく同等のものです
Test型であるtest

どんなプロパティが利用可能？

タスクを設定して、テスト実行時のシステムプロパティを追加しています：

gradle例7.6 テスト用システムプロパティの追加

propertiesを使えば、プロジェクトのプロパティを一覧する

build.gradle
test {
systemProperties 'property': 'value'}

Page 42 of 436

7.2.4. JARファイルの公開

通常は、JARファイルをどこかに公開する必要があるでしょう。このため、GradleにJARファイルの公開先を教える必例7.7 JARファイルの公開
build.gradle
uploadArchives {repositories {flatDir {dirs 'repos'}}}

JARファイルを公開するには、gradle uploadArchivesを実行してください。

7.2.5. Eclipseプロジェクトの作成
.

p

r

o

j

e

c

t

のようなEclipse固有の設定ファイルを生成するには、別のプラグインをビルドファイルに追加する必要があります：
例7.8 Eclipseプラグイン
build.gradle
apply plugin: 'eclipse'

こ れ で g r a d l ee c l i p s e

コマンドを実行すればEclipseのプロジェクトファイルが生成されます。Eclipseタスクの詳細は38章
Eclipse プラグインをご覧ください。

7.2.6. まとめ
これまでの例の完全なビルドファイルを以下に示します：

Page 43 of 436

例7.9 Javaの例 - 完全なビルドファイル
build.gradle
apply plugin: 'java'
apply plugin: 'eclipse'
sourceCompatibility = 1.5
version = '1.0'
jar {manifest {attributes 'Implementation-Title': 'Gradle Quickstart','Implementation-Version': version}}
repositories {mavenCentral()}dependencies {compile group: 'commons-collections', name: 'commons-collections', version: '3.2'
testCompile group: 'junit', name: 'junit', version: '4.+'}
test {
systemProperties 'property': 'value'}
uploadArchives {repositories {flatDir {dirs 'repos'}}}

7.3. マルチプロジェクトのJavaビルド

さて、ここで典型的なマルチプロジェクトのビルドを見てみましょう。プロジェクトのレイアウトは以下の通りです：
例7.10 マルチプロジェクトビルド - 階層レイアウト
Build layout
multiproject/
api/
services/webservice/
shared/services/shared/

ノ

ー

ト

:

本例のソースコードは、Gradleのバイナリ配布物またはソース配布物に含まれています。以下の場所をご参照くだsamples/java/multiproject

Page 44 of 436

この例には三つのプロジェクトがあります。プロジェクトapi

は、このwebサービス用のJavaクライアントを提供するために顧客に出荷されるJARファイルを生成します。プロジェ
webserviceはXMLを返すwebアプリケーションです。プロジェクトsharedは、apiとwebserviceの両方で使われる共通コードです。

7.3.1. マルチプロジェクトビルドの定義
マルチプロジェクトのビルドを定義するためには、 settingsファイルを作成する必要があります。settingsファイルはソースツリーのルートディレクトリに置かれ、このビルドにどのプロ
s e t t i n g s . g r a d l e

でなければなりません。この例では、シンプルな階層レイアウトを使っています。対応するsettingsファイルは以下の例7.11 マルチプロジェクトビルド - settings.gradleファイル
settings.gradle
include "shared", "api", "services:webservice", "services:shared"

settingsファイルの詳細は57章マルチプロジェクトのビルドをご覧ください。

7.3.2. 共通設定
大抵のマルチプロジェクトビルドでは、すべてのプロジェクトに共通な設定があります。この例では、
設 定 の イ ン ジ ェ ク シ ョ ンと呼ばれる技法を使い、こういった共通設定をルートプロジェクトで定義します。ここでは、ルートプロジェクトはコs u b p r o j e c t s

メソッドはコンテナの全要素、すなわちこの実例の中の全プロジェクト、に対して反復しつつ指定された設定をインジ
例7.12 マルチプロジェクトビルド - 共通設定
build.gradle
subprojects {apply plugin: 'java'
apply plugin: 'eclipse-wtp'
repositories {mavenCentral()}dependencies {testCompile 'junit:junit:4.11'}
version = '1.0'
jar {manifest.attributes provider: 'gradle'}}

この例で、各サブプロジェクトにJavaプラグインが適用されていることに注意してください。
これは、前の節で述べたタスクや設定プロパティが各サブプロジェクトでも利用可能であることを意味しています。
Page 45 of 436

そんなわけで、ルートプロジェクトディレクトリからgradlebuildを実行することによって、すべてのプロジェクトをコンパイルし、テストし、JARを生成できるのです。
Also note that these plugins are only applied within the subprojects section, not at the rootlevel, so the root build will not expect to find Java source files in the root project, only in the
subprojects.

7.3.3. プロジェクト間の依存関係

同じビルド内のプロジェクト間の依存関係を追加することもできます。したがって例えば、一つのプロジェクトのJAR
apiのビルドファイルにshared
プロジェクトが作るJARへの依存関係を追加します。この依存関係のため、Gradleはshared
プロジェクトがapiプロジェクトより前にビルドされることを確実にします。
例7.13 マルチプロジェクトビルド - プロジェクト間の依存関係
api/build.gradle
dependencies {compile project(':shared')}

この機能を無効にする方法については「依存プロジェクトをビルドしないようにする」
を参照してください。

7.3.4. 配布物の作成
顧客に出荷する配布物も追加しておきましょう：
例7.14 マルチプロジェクトビルド - 配布ファイル
api/build.gradle
task dist(type: Zip) {dependsOn spiJar
from 'src/dist'into('libs') {from spiJar.archivePathfrom configurations.runtime}}
artifacts {archives dist}

7.4. 次のステップは？

この章では、Javaベースのプロジェクトをビルドするときに、一般的に必要になる作業のやり方を見てきました。この23章Javaプラグインで詳しく知ることができます。また、Gradleの配布物に含まれるsample/javaにはもっと多くのサンプルがあります。

Page 46 of 436

そうでない場合は、続けて8章依存関係管理の基本 に進んでください。

Page 47 of 436

8
依存関係管理の基本
本章では、Gradleにおける依存関係の管理について、基本的なところを紹介します。

8.1. 依存関係の管理とはおおざっぱに言って、依存関係の管理とは二つの部分に分けられます。まず、Gradleは、あなたのプロジェクトをビル
依 存 関 係 と 呼 び ま す 。

次に、Gradleはあなたのプロジェクトをビルドし、生成されたものをアップロードする必要があります。これらの出力
公開物 と呼びます。

ほとんどのプロジェクトは、完全に自己完結しているわけではありません。コンパイル、テスト、その他諸々のために
これらの入力ファイルは、プロジェクトの依存関係から読み込まれます。

Gradleにプロジェクトの依存関係を教えて、プロジェクトが依存しているファイルを見つけたり、ビルド時にそれらを依存ファイルは、リモートのMavenやIvyのリポジトリからダウンロードされるかもしれませんし、ローカルのディレ
Often, the dependencies of a project will themselves have dependencies. For example,
Hibernate core requires several other libraries to be present on the classpath with it runs. So,
when Gradle runs the tests for your project, it also needs to find these dependencies and makethem available. We call these transitive dependencies .

また、依存しているファイルが、それ自身の依存関係を持っていることが多々あります。例えば、Hibernateコアは、
推移的な依存関係 と呼びます。

ほとんどのプロジェクトは、ファイルを作成し、それらをプロジェクトの外部で使うということを主な目的としていま

例えば、もしあなたのプロジェクトがJavaライブラリを作成するものならば、あなたはjarを作成し、ときにはソースj

ファイルの公開は、プロジェクトの公開設定から読み込まれて行われます。Gradleは、この重要な仕事も引き受けてく「公開する」ということの正確な意味は、何をしたいのかによって異なります。ローカルディレクトリにファイルをコ
これらの処理を、 公開 と呼んでいます。

8.2. 依存関係の宣言

さて、では依存関係の宣言についていくつか見ていきましょう。ここに、ある基本的なビルドスクリプトがあります。

Page 48 of 436

例8.1 依存関係の宣言
build.gradle
apply plugin: 'java'
repositories {mavenCentral()}dependencies {compile group: 'org.hibernate', name: 'hibernate-core', version: '3.6.7.Final'
testCompile group: 'junit', name: 'junit', version: '4.+'}

一体、何が起きるでしょうか。このビルドスクリプトにはそれほど多くの情報はありません。まず、このプロジェクト
core

3.6.7を使用すると言っています。それはすなわち、実行時にHibernatecoreとその依存関係が必要になるということでもあります。

このスクリプトはまた、バージョン4.0以上のJUnitのどれかを、プロジェクトのテストをコンパイルするのに必要とす

8.3. 依存関係のコンフィグレーション
Gradleでは、依存関係は、 コンフィグレーション

によってグループ化されます。コンフィグレーションとは、単なる名前の付いた依存関係の集まりです。コンフィグレ
依

存

関

係

設

定

として参照されます。プロジェクトが外部に依存しているものを宣言するのに使われ、また後で見るように、プロジェ

Javaプラグインは、いくつかの標準コンフィグレーションを定義します。これらのコンフィグレーションは、Javaプラ
表23.5「Javaプラグイン - 依存関係のコンフィギュレーション」を参照してください。
compileプロジェクトのプロダクトコードをコンパイルするのに必要な依存関係
runtime

プロダクトのクラスを実行するときに必要になる依存関係。デフォルトで、コンパイル時の依存関係もここに含まtestCompile

プロジェクトのテストコードをコンパイルするのに必要な依存関係。デフォルトで、コンパイルされたプロダクト
testRuntime

テストを実行するのに必要な依存関係。デフォルトで、compile、runtime、testCompileの各依存関係もここに含

多くのプラグインが、このような標準コンフィグレーションを追加します。また、自分のビルドに使うためのカスタム「依存関係のコンフィギュレーション 」を参照してください。

8.4. 外部依存関係定義できる依存関係には、さまざまなタイプがあります。そのうちの一つが、 外部依存関係です。これは、今のビルドとは別に作られ、MavenセントラルリポジトリやIvyリポジトリ、ローカルファイルシステ

Page 49 of 436

外部依存関係を定義するには、それを依存関係のコンフィグレーションに追加します。
例8.2 外部依存関係の定義
build.gradle
dependencies {compile group: 'org.hibernate', name: 'hibernate-core', version: '3.6.7.Final'}

外部依存関係は、 group 属性、 name属性、そして version 属性を用いて定義します。
使用しているリポジトリの種類によっては、 group 属性と version
属性はオプショナルになるかもしれません。
The shortcut form for declaring external dependencies looks like “ group : name : version ”.
外部依存関係を定義するときは、ショートカット形式を使うこともできます。" group : name : version "という文字列を使う形式です。
例8.3 外部依存関係定義のショートカット形式
build.gradle
dependencies {compile 'org.hibernate:hibernate-core:3.6.7.Final'}

依存関係を定義して取り扱う方法について、詳しくは「依存関係の定義方法 」を見てください。

8.5. リポジトリ
Gradleは、どうやって外部依存関係を見つけるのでしょうか？

Gradleは、それらをリポジトリ

から探します。リポジトリの実体は、ただのファイルの集合です。それらのファイルは、、、そしてによって分類されています。Gradleは、MavenやIvyなど、様々なリポジトリ形式に対応できます。また、ローカルフ

デフォルトでは、Gradleはリポジトリを一切定義していません。外部依存関係を使うには、少なくとも一つのリポジト
選択肢の一つは、Mavenのセントラルリポジトリを使うことです。
例8.4 Mavenセントラルリポジトリの使用
build.gradle
repositories {mavenCentral()}

または、別のMavenリモートリポジトリを使います。

Page 50 of 436

例8.5 リモートMavenリポジトリの使用
build.gradle
repositories {maven {
url "http://repo.mycompany.com/maven2"}}

または、リモートのIvyリポジトリを使います。
例8.6 リモートIvyリポジトリの使用
build.gradle
repositories {ivy {url "http://repo.mycompany.com/repo"}}

さらに、ローカルファイルシステム上にリポジトリを持つこともできます。これは、Maven、Ivy双方のリポジトリ形
例8.7 ローカルのIvyディレクトリを使う
build.gradle
repositories {ivy {// URL can refer to a local directory
url "../local-repo"}}

一つのプロジェクトが、複数のリポジトリを持つことができます。Gradleは、それぞれのリポジトリを、指定された順
リポジトリを定義し、取り扱う方法について、詳しくは「リポジトリ 」を参照してください。

8.6. アーティファクトの公開
依存関係のコンフィグレーションは、ファイルを公開するのにも使用します。 [ 6 ]これらのファイルを、 公開アーティファクト 、大体は単に アーティファクト と呼びます。

プラグインが非常に適切にプロジェクトのアーティファクトを定義してくれるので、何を公開したいかGradleに教える
u p l o a d A r c h i v e s
タスクに結びつけることで行います。次のコードは、リモートのIvyリポジトリに公開する例です。

Page 51 of 436

例8.8 Ivyリポジトリに公開する
build.gradle
uploadArchives {repositories {ivy {credentials {username "username"password "pw"}url "http://repo.mycompany.com"}}}

これでgradle

uploadArchives

を走らせれば、Gradleがjarをビルドしてアップロードしてくれます。

さらに、ivy.xmlも生成されてアップロードされます。
Mavenリポジトリに公開することもできますが、その文法はすこし異なります [ 8 ] 。

また、Mavenリポジトリへ公開するには、Mavenプラグインを使う必要もあるので注意してください。この場合、Gr
pom.xmlも生成してアップロードします。
例8.9 Mavenリポジトリへの公開
build.gradle
apply plugin: 'maven'uploadArchives {repositories {mavenDeployer {repository(url: "file://localhost/tmp/myRepo/")}}}

アーティファクトの公開について、詳しくは52章アーティファクトの公開 をご参照ください。

8.7. 次のステップは？
依存関係解決については、51章依存関係の管理に全て詳細に載っています。そして、アーティファクトの公開については52章
アーティファクトの公開 に載っています。
本章で使ったDSLに興味があるのであれば、 Project.configurations{} やProject.repositories{}、Project.dependencies{}を見てください。
それ以外の場合は、チュートリアルから他のチュートリアルを進めてください。

[

6]
Page 52 of 436

[6]
私たちは、これは混乱の元になると考えています。そのため、GradleのDSLでは、段階的に二つに概念に分けていくつ[
私たちは、Mavenリポジトリからの取得とMavenリポジトリへの公開を一貫した文法で行えるよう作業しているところ
8]

Page 53 of 436

9Groovyクイックスタート
Groovyプロジェクトをビルドするのには、 Groovyプラグインを使います。このプラグインはJavaプラグインを拡張して、Groovyのコンパイル能力をプロジェクトに加えます。

プロジェクトはGroovyソースコード、Javaソースコード、またはこれらの両方を含むことができます。これ以外の点で7章Javaクイックスタートですでに見たJavaプロジェクトを同じです。

9.1. 基本的なGroovyプロジェクト
実例を見てみましょう。Groovyプラグインを使うためには、ビルドファイルに以下を記述を追加します：
例9.1 Groovyプラグイン
build.gradle
apply plugin: 'groovy'

ノ

ー

ト

:

本例のソースコードは、Gradleのバイナリ配布物またはソース配布物に含まれています。以下の場所をご参照くだsamples/groovy/quickstart

これにより、（もしまだなら）プロジェクトにはJavaプラグインも適用されます。Groovyプラグインはcompileタスクを拡張してsrc/main/groovy
ディレクトリにあるソースファイルも参照するようにし、またcompileTestタスクを拡張してsrc/test/groovy

ディレクトリにあるテスト用ソースファイルも参照するようにします。compileタスクはこれらのディレクトリに対しGroovy用のcompileタスクを使うには、GroovyのバージョンとGroovyライブラリを探してくる場所を宣言する必要が
c

o

m

p

i

l

e

コンフィギュレーションに依存関係を追加することによって行います。この例では、Groovy
2.2.0を使用します。

Page 54 of 436

例9.2 Dependency on Groovybuild.gradle
repositories {mavenCentral()}dependencies {compile 'org.codehaus.groovy:groovy-all:2.3.6'}

以下にビルドファイルの全体を示します：
例9.3 Groovy用のビルドファイル（全体）build.gradle
apply plugin: 'eclipse'
apply plugin: 'groovy'
repositories {mavenCentral()}dependencies {compile 'org.codehaus.groovy:groovy-all:2.3.6'
testCompile 'junit:junit:4.11'}

gradle buildを実行すれば、プロジェクトがコンパイル、テストされ、JARが生成されます。

9.2. まとめこの章では非常にシンプルなGroovyプロジェクトについて説明しました。通常、実プロジェクトではこの例よりもっでもある ので、Javaプロジェクトで可能なことなら何でもGroovyプロジェクトでも可能です。
2 4 章 G r o o v y プ ラ グ イ ン
では、Groovyプラグインをより詳しく説明しています。また、Gradle配布物のsamples/groovy
ディレクトリには、Groovyプロジェクトの実例が多く含まれています。

Page 55 of 436

10
Webアプリケーションクイックスタート
この章は執筆途中です。

この章ではGradleのWebアプリケーションサポートについて紹介します。

GradleはWebアプリケーション開発に対応する2つのプラグイン、WarプラグインとJettyプラグインを提供しています
WarプラグインはJavaプラグインを拡張して、プロジェクトでWARファイルのビルドができるようにします。

JettyプラグインはWarプラグインを拡張して、組み込みJettyコンテナにWebアプリケーションをデプロイできるように

10.1. WARファイルのビルド
WARファイルをビルドするために、プロジェクトにWarプラグインを適用します:
例10.1 Warプラグイン
build.gradle
apply plugin: 'war'

ノ

ー

ト

:

本例のソースコードは、Gradleのバイナリ配布物またはソース配布物に含まれています。以下の場所をご参照くだsamples/webApplication/quickstart

これにより、プロジェクトにはJavaプラグインも適用されます。

gradlebuildを実行すれば、プロジェクトがコンパイル、テストされ、WARが生成されます。 Gradleはsrc/main/webappにあるファイルからWARに含めるものを探します。
コンパイル済みクラスや実行時に必要となる依存ライブラリもWARに追加されます。

10.2.
Webアプリケーションの実行

GroovyWebアプリケーション

単一のプロジェクト内で複数のプラグインを組みGroovyベースのWebアプリケーションをビルドす
Webアプリケーションを実行するためには、プロジェクトにJettyプラグインを適用します:
その場合、適切なGroovyライブラリがWARファイ

Page 56 of 436

例10.2 JettyプラグインによるWebアプリケーションの実行
build.gradle
apply plugin: 'jetty'

これにより、プロジェクトにはWarプラグインも適用されます。

gradlejettyRunを実行すれば、組み込みJettyコンテナ上でWebアプリケーションが実行されます。 gradle jettyRunWar
を実行するとWARファイルが生成され、その後組み込みWebコンテナで実行されます。
TODO: URLの確認方法、ポートの設定、ソースファイルの編集と動的リロードの方法など

10.3. まとめWarプラグインについての詳細は26章War プラグイン、 Jettyプラグインの詳細については28章Jetty
プラグイン を参照してください。

Gradle配布物の samples/webApplication

ディレクトリにサンプルJavaプロジェクトがあります。

Page 57 of 436

11Gradleのコマンドラインを使う

本章では、Gradleのコマンドラインについて基本的な部分を紹介します。これまで動かしてきたように、Gradleのビル
gradleコマンドで実行します。

11.1. 複数のタスクを実行する

一回のビルドで、複数のタスクを実行することができます。ビルドを実行するときに、タスクを並べて指定してくださ
gradlecompiletest というコマンドを実行すれば、 compile タスクと test

タスクが実行されます。Gradleはタスクを列挙された順に実行するほか、それらが依存しているタスクも実行します。
この例では、四つのタスクが定義されており、 dist と test はどちらも compile
タスクに依存しています。このビルドスクリプトを呼び出してgradle

dist

test

と実行しても、実行された二つのタスクから依存されているcompile
タスクは一度だけしか実行されません。
図11.1 Task間の依存関係

Page 58 of 436

例11.1 複数のタスクの実行
build.gradle
task compile << {println 'compiling source'}task compileTest(dependsOn: compile) << {println 'compiling unit tests'}
task test(dependsOn: [compile, compileTest]) << {println 'running unit tests'}
task dist(dependsOn: [compile, test]) << {println 'building the distribution'}

gradle dist test の出力> gradle dist test:compile
compiling source:compileTest
compiling unit tests:test
running unit tests:distbuilding the distribution
BUILD SUCCESSFUL
Total time: 1 secs

タスクが一度だけ実行されるということは、gradle

test

testと打ち込んでもgradle

testと打ち込んでも、実行される処理は全く同じだということです。

11.2. タスクを除外してビルドする-

x

オプションでタスクの名前を指定することで、そのタスクを除外してビルドを実行することができます。先ほどのサンPage 59 of 436

例11.2 タスクの除外
gradle dist -x test の出力> gradle dist -x test:compile
compiling source:distbuilding the distribution
BUILD SUCCESSFUL
Total time: 1 secs

distタスクはtestに依存しているのですが、この例ではtest
タスクは実行されていないことが分かります。また、testタスクが依存しているタスク、たとえばcompileTest
タスクもやはり実行されていません。しかし、testタスクが依存しているタスクのうち、test
以外からも依存されているタスク、つまりcompileタスクは実行されているのです。

11.3. エラー発生時にビルドを継続する

デフォルトでは、タスクが失敗するとすぐにGradleは実行を中止してビルドを失敗させます。これはビルドの完了は早一回のビルド実行でできるだけ多くのエラーを発見するには、--continue
オプションを使用します。
- - c o n t i n u e

オプションをつけてビルドすると、エラー発生時に即ビルドが停止されるのではなく、失敗せずに完了したタスクに依全 て 実 行 さ れ る よ う に な り ま す 。
また、ビルド中に発生したエラーはビルド終了時に全てレポートされます。
タスクが失敗した場合、依存関係上の後続タスクは安全に実行できないため行われません。

例えば、テストの際、コードのコンパイルでエラーが発生するとテストは実施されません。テストタスクはコンパイル

11.4. タスク名の省略

タスク名をコマンドラインで指定するとき、タスク名をすべて入力する必要はありません。タスク名を一つに決定できgradle dと入力すればdistを実行できます。

Page 60 of 436

例11.3 タスク名の省略
gradle di の出力> gradle di:compile
compiling source:compileTest
compiling unit tests:test
running unit tests:distbuilding the distribution
BUILD SUCCESSFUL
Total time: 1 secs

キャメルケースで分割されたそれぞれの単語を省略することもできます。たとえば、compileTestというタスクだと、 gradle

compTest と入力したり、 gradlecTと入力したりすることで実行できます。
例11.4 キャメルケースのタスク名を省略
gradle cT の出力> gradle cT:compile
compiling source:compileTest
compiling unit tests
BUILD SUCCESSFUL
Total time: 1 secs

-xオプションで除外タスクを指定するときにも、同じようにタスク名を省略できます。

11.5. ビルドスクリプトを指定して実行する
g

r

a

d

l

e

コマンドは、デフォルトではカレントディレクトリにあるビルドスクリプトを探して実行しますが、-bオプションを使えば別のビルドスクリプトを指定することもできます。次の例を見てください。
なお、-bを使うと、settings.gradleファイルは使用されなくなります。

Page 61 of 436

例11.5 ビルドスクリプトを指定してビルドするプロジェクトを選択する
subdir/myproject.gradle
task hello << {println "using build file '$buildFile.name' in '$buildFile.parentFile.name'."}gradle -q -b subdir/myproject.gradle hello の出力> gradle -q -b subdir/myproject.gradle hellousing build file 'myproject.gradle' in 'subdir'.

別 の 方 法 と し て 、 - p
オプションを指定して、使用するプロジェクトディレクトリを変更することもできます。
マルチプロジェクトの場合は、-bオプションでなく-pオプションを使用するべきです。
例11.6 プロジェクトディレクトリを使ってプロジェクトを選択する
gradle -q -p subdir hello の出力> gradle -q -p subdir hellousing build file 'build.gradle' in 'subdir'.

11.6. ビルドに関する情報を取得する

ビルドに関する様々な情報を表示するために、組み込みのタスクがいくつか用意されています。自分の作ったビルドがこの組み込みタスクに加えて、プロジェクトレポートプラグインというプラグインを使うこともできます。このプラグインは、これらの情報をレポートに保存するタスクをプロジェク

11.6.1. プロジェクトの一覧
g r a d l e

p r o j e c t s

を実行すると、指定したプロジェクトのサブプロジェクトを一覧できます。プロジェクトの一覧は階層構造で表示され例11.7 プロジェクトに関する情報を取得する
gradle -q projects の出力> gradle -q projects-----------------------------------------------------------Root project-----------------------------------------------------------Root project 'projectReports'+--- Project ':api' - The shared API for the application\--- Project ':webapp' - The Web application implementation
To see a list of the tasks of a project, run gradle <project-path>:tasks
For example, try running gradle :api:tasks

このレポートは、プロジェクトに説明書きが添付されている場合、その説明も表示されます。プロジェクトの説明は、Page 62 of 436

例11.8 プロジェクトに説明を添付する
build.gradle
description = 'The shared API for the application'

11.6.2. タスクの一覧
g r a d l et a s k sを実行すると、プロジェクトに設定されているメインタスクの一覧とデフォルトタスクを表示します。さらに、タスク
例11.9 タスクに関する情報を取得する
gradle -q tasks の出力> gradle -q tasks-----------------------------------------------------------All tasks runnable from root project-----------------------------------------------------------Default tasks: dists
Build tasks----------clean - Deletes the build directory (build)dists - Builds the distribution
libs - Builds the JAR
Build Setup tasks----------------init - Initializes a new Gradle build. [incubating]wrapper - Generates Gradle wrapper files. [incubating]

Help tasks---------components - Displays the components produced by root project 'projectReports'.
dependencies - Displays all dependencies declared in root project 'projectReports'.
dependencyInsight - Displays the insight into a specific dependency in root project 'projectRepo
help - Displays a help message.
projects - Displays the sub-projects of root project 'projectReports'.
properties - Displays the properties of root project 'projectReports'.
tasks - Displays the tasks runnable from root project 'projectReports' (some of the displayed ta
To see all tasks and more detail, run with --all.

デフォルトでは、このレポートは何らかのタスクグループに属しているタスクしか表示されません。タスクの
g

r

o

u

p

プロパティを設定することでタスクにグループを割り当てることができます。また、このレポートでタスクに関する説
descriptionプロパティに説明書きを設定してください。

Page 63 of 436

例11.10 タスクレポートの内容を変更する
build.gradle
dists {
description = 'Builds the distribution'group = 'build'
}

-

-

a

l

l

オプションを追加すると、タスクリストについてもっと多くの情報を取得できます。プロジェクトにあるすべてのメイ

Page 64 of 436

例11.11 タスクに関してもっと多くの情報を取得する
gradle -q tasks --all の出力> gradle -q tasks --all-----------------------------------------------------------All tasks runnable from root project-----------------------------------------------------------Default tasks: dists
Build tasks----------clean - Deletes the build directory (build)
api:clean - Deletes the build directory (build)webapp:clean - Deletes the build directory (build)dists - Builds the distribution [api:libs, webapp:libs]
docs - Builds the documentation
api:libs - Builds the JAR
api:compile - Compiles the source files
webapp:libs - Builds the JAR [api:libs]
webapp:compile - Compiles the source files
Build Setup tasks----------------init - Initializes a new Gradle build. [incubating]wrapper - Generates Gradle wrapper files. [incubating]

Help tasks---------components - Displays the components produced by root project 'projectReports'.
api:components - Displays the components produced by project ':api'.
webapp:components - Displays the components produced by project ':webapp'.
dependencies - Displays all dependencies declared in root project 'projectReports'.
api:dependencies - Displays all dependencies declared in project ':api'.
webapp:dependencies - Displays all dependencies declared in project ':webapp'.
dependencyInsight - Displays the insight into a specific dependency in root project 'projectRepo
api:dependencyInsight - Displays the insight into a specific dependency in project ':api'.
webapp:dependencyInsight - Displays the insight into a specific dependency in project ':webapp'.
help - Displays a help message.
api:help - Displays a help message.
webapp:help - Displays a help message.
projects - Displays the sub-projects of root project 'projectReports'.
api:projects - Displays the sub-projects of project ':api'.
webapp:projects - Displays the sub-projects of project ':webapp'.
properties - Displays the properties of root project 'projectReports'.
api:properties - Displays the properties of project ':api'.
webapp:properties - Displays the properties of project ':webapp'.
tasks - Displays the tasks runnable from root project 'projectReports' (some of the displayed ta
api:tasks - Displays the tasks runnable from project ':api'.
webapp:tasks - Displays the tasks runnable from project ':webapp'.

11.6.3. タスクの使い方を詳しく表示する
gradlehelp--tasksomeTaskを実行すると、ある特定のタスク、マルチプロジェクトの場合は指定した名前にマッチする全てのタスクについての詳表示される情報の例は以下の通りです。

Page 65 of 436

例11.12 タスクについて詳細なヘルプ情報を取得する
gradle -q help --task libs の出力> gradle -q help --task libs
Detailed task information for libs
Paths
:api:libs:webapp:libs
Type
Task (org.gradle.api.Task)
Description
Builds the JAR

上記の通り、表示される情報にはタスクのフルパス、使用可能なコマンドラインオプション、またタスクの説明が含ま

11.6.4. プロジェクトの依存関係一覧
gradledependencies

はプロジェクトの依存関係をコンフィギュレーションごとに一覧表示します。プロジェクトに直接設定されている依存例11.13 依存関係の情報を取得する
gradle -q dependencies api:dependencies webapp:dependencies の出力> gradle -q dependencies api:dependencies webapp:dependencies-----------------------------------------------------------Root project-----------------------------------------------------------No configurations-----------------------------------------------------------Project :api - The shared API for the application-----------------------------------------------------------compile\--- org.codehaus.groovy:groovy-all:2.3.6
testCompile\--- junit:junit:4.11\--- org.hamcrest:hamcrest-core:1.3-----------------------------------------------------------Project :webapp - The Web application implementation-----------------------------------------------------------compile+--- project :api|\--- org.codehaus.groovy:groovy-all:2.3.6\--- commons-io:commons-io:1.2
testCompile
No dependencies

Page 66 of 436

依存関係のレポートは巨大になることもあるので、レポート内容を特定のコンフィギュレーションのみに限定できれば
これは、オプションの--configurationを指定することで実現できます。
例11.14 依存関係のレポートをコンフィギュレーションでフィルタする
gradle -q api:dependencies --configuration testCompile の出力> gradle -q api:dependencies --configuration testCompile-----------------------------------------------------------Project :api - The shared API for the application-----------------------------------------------------------testCompile\--- junit:junit:4.11\--- org.hamcrest:hamcrest-core:1.3

11.6.5. 個別の依存関係に対する解析情報を取得する
gradledependencyInsightを実行すると、個別の、または複数の依存関係を指定して、それぞれに対する解析情報を取得することができます。以
例11.15 個別の依存関係に対する解析情報を取得する
gradle -q webapp:dependencyInsight --dependency groovy --configuration compileの出力> gradle -q webapp:dependencyInsight --dependency groovy --configuration compileorg.codehaus.groovy:groovy-all:2.3.6\--- project :api\--- compile

dependencyInsightは、依存関係がどのように解決されているか調査するときにとても便利なタスクです。ある依存関
詳細については、DependencyInsightReportTaskを参照してください。
組み込みのdependencyInsightタスクは、Helpグループに属しています。
このタスクは、依存関係およびコンフィグレーションを指定しないと使用できません。
レポートが出力される際は、指定されたコンフィグレーションの指定された依存関係を探しに行きます。

Java関連のプラグインが適用されていれば、dependencyInsightタスクは既にcompileコンフィグレーションに対して
また、調査対象の依存関係を「--dependency」オプションで指定しなければなりません。

さらに、デフォルトのコンフィグレーションが気に入らないときは「--configuration」オプションで明示的にコンフィ
詳しくはDependencyInsightReportTaskを参照してください。

11.6.6. プロジェクトのプロパティ一覧
g r a d l e

p r o p e r t i e s

はプロジェクトのプロパティを一覧表示します。出力例の一部を以下に示します。

Page 67 of 436

例11.16 プロパティに関する情報
gradle -q api:properties の出力> gradle -q api:properties-----------------------------------------------------------Project :api - The shared API for the application-----------------------------------------------------------allprojects: [project ':api']
ant: org.gradle.api.internal.project.DefaultAntBuilder@12345
antBuilderFactory: org.gradle.api.internal.project.DefaultAntBuilderFactory@12345
artifacts: org.gradle.api.internal.artifacts.dsl.DefaultArtifactHandler_Decorated@12345
asDynamicObject: org.gradle.api.internal.ExtensibleDynamicObject@12345
baseClassLoaderScope: org.gradle.api.internal.initialization.DefaultClassLoaderScope@12345
buildDir: /home/user/gradle/samples/userguide/tutorial/projectReports/api/build
buildFile: /home/user/gradle/samples/userguide/tutorial/projectReports/api/build.gradle

11.6.7. ビルドのプロファイリング
コマンドラインオプションで--profile
をつけてビルドを実行すると、ビルドに要した時間のうち有用と思われるいくつかの情報を計測して、結果をbuild/reports/profile
ディレクトリを出力します。レポート名には、ビルドを行った時刻が付加されます。

このレポートでは、ビルド時間に関する概要のほか、設定フェーズとタスク実行に要した時間がタスクごとに表示されなお、 buildSrc ディレクトリを使っている場合、 buildSrc/build に buildSrcのレポートが別途出力されます。

Page 68 of 436

11.7. 空実行

コマンドラインにタスク名を並べて実行したときに、どのタスクがどの順番で実行されるのか知りたくなることがあり-m オプションをつけて実行してください。たとえば、 gradle

-m

clean

compileと実行すれば、cleanタスクとcompileタスクの実行にあたって実際に実行されるすべてのタスクが実行順に表示されま
tasksタスクの補足にもなります。

11.8. まとめこの章では、コマンドラインで使えるGradleの機能をいくつか見てきました。gradle
コマンドについては付録D Gradle コマンドラインにも記載してあります。

Page 69 of 436

12GradleのGUIを使う

伝統的なコマンドラインインターフェースに加え、Gradleはグラフィカルユーザーインターフェースも提供しています--guiオプションを使って起動できます。
例12.1 GUIの起動
gradle --gui

このコマンドは、GUIをクローズするまでブロックされることに注意してください。*nixでは、バックグラウンドタス
gradle --gui&)で実行した方がいいかもしれません。

このコマンドをgradleプロジェクトの作業ディレクトリで実行すると、タスクのツリーが表示されることが分かります

Page 70 of 436

図12.1 GUI Task Tree

このコマンドは、自分のgradleプロジェクトのディレクトリで実行した方がいいでしょう。そうすれば、UI設定がプロ
UIには上部に4つのタブがあり、下部には出力を表示するウィンドウがあります。

12.1. Task Tree（タスク・ツリー）
T

a

s

k

Treeは、すべてのプロジェクトとタスクの階層構造を表示します。タスクをダブルクリックすると、そのタスクが実行

また、フィルターも用意されているので、一般的でないタスクは非表示にすることができます。フィルターを有効にすフィルター編集画面では、どのタスクとプロジェクトを表示するかを設定します。非表示に設定されたタスクは赤色で
注意:

新しく作成されたタスクは、デフォルトでは表示に設定されます（デフォルトで非表示に設定されるのではなく）。
タスクツリーのコンテキストメニューでは、以下の機能も使うことができます。
Page 71 of 436

依存関係を無視したタスクの実行する。依存プロジェクトを再ビルドしません（-aオプションと同じ）。
タスクをお気に入りに追加する（Favoritesを参照してください）。
選択したタスクを隠す。タスクをフィルターに追加します。
build.gradleファイルの編集。注意:

この機能を使うには、1.6以上のバージョンのJavaが必要です。また、OS上で.gradleファイルの関連づけを設定し12.2. Favorites（お気に入り）

Favoriteタブでは、よく実行するコマンドをお気に入りとして保存できます。保存するコマンドは複雑なもの（Gradl

お気に入りは、好きなように並び替えることができます。また、お気に入りをディスクにエクスポートしたり、そこかお気に入りを追加、編集するとき、"Always Show Live Output"というオプションがあるはずです。
これは、'Only Show Output When Errors
Occur'（エラー発生時のみ出力を表示する）設定を有効にしているときのみ適用されるオプションです。
このオプションを有効にすると、その設定を上書きし常に出力が表示されるようになります。

12.3. Command Line（コマンドライン）
Command

Lineタブでは、ひとつのgradleコマンドを直接実行できます。いつも'gradle'のあとに入力しているコマンドを入力する

12.4. Setup（セットアップ）
Setupタブは、一般的な設定を行うところです。

Page 72 of 436

図12.2 GUI Setup

Current Directory

gradleプロジェクトのルートディレクトリを設定します（典型的には、build.gradleが置かれているディレクトリにStack Trace Output
ここでは、エラーが発生したとき、どれだけの情報をスタックトレースに書き出すかを設定します。注意:
スタックトレースレベルをCommand
LineタブやFavoritesタブで指定している場合、ここで設定したスタックトレースレベルは上書きされます。
Only Show Output When Errors Occur
有効にすると、ビルドに失敗しない限り出力が表示されないようになります。
Use Custom Gradle Executor - 高度な機能

gradleコマンドの実行方法を変更できます。これは、自分のプロジェクトが、バッチファイルやシェルスクリプト

Page 73 of 436

13
ビルドスクリプトの記述
本章では、ビルドスクリプトの記述についてもう少し詳しく見ていきます。

13.1. Gradleビルド言語
Gradleは、ビルドシステムを記述するための ドメイン特化言語 (DSL)を提供します。

このビルド用言語は、Groovyをベースに、ビルドシステムの記述を簡単にするための機能をいくつか追加したもので
A build script can contain any Groovy language element. [9] Gradle assumes that each build
script is encoded using UTF-8.

13.2. プロジェクトAPI
例えば、 7章Javaクイックスタート のチュートリアルで使用した apply()

メソッド、このメソッドはどこから来たのでしょうか。まず、前述のようにビルドスクリプトはGradleのプロジェクト
ビルドに含まれるプロジェクトそれぞれに対し、Project型のインスタンスが一つ作られ、ビルドスクリプトと関連づけられます。ビルドが実行されると、このプロジェクト・
ビルドスクリプトで呼び出されたメソッドのうち、そのスクリプトで定義されていない ものはProject
オブジェクトに委譲されます。

ビルドスクリプトのリファレンス

ビルドスクリプトでのプロパティアクセスも、そのスクリプトでビルドスクリプトは、GradleのAPIを呼び出してい定義されていない プロパティについてはProject
Project
オブジェクトに委譲されます。

インターフェースが、GradleのAPIを呼び出すとき
Project

プロジェクトオブジェクトのname

インターフェースのドキュメントを見ることからプロパティにアクセスして試してみましょう。
例13.1 Projectオブジェクトへのアクセス
build.gradle
println nameprintln project.namegradle -q check の出力> gradle -q checkprojectApi
projectApi

Page 74 of 436

ど ち ら の p r i n t l n

も出力結果は同じです。最初のprintlnは、ビルドスクリプトで定義されていないプロパティへのアクセスを、暗黙のう
project プロパティを使って、 name にアクセスしています。 project

プロパティには、ビルドスクリプトのどこからでもアクセスできます。プロジェクトオブジェクトのプロパティやメソ
projectプロパティからアクセスすることになるでしょう。

13.2.1. 標準のプロジェクトプロパティ

プロジェクトオブジェクトは標準でいくつかのプロパティを提供しており、ビルドスクリプトでこれらのプロパティに
表13.1 プロジェクトプロパティ
プロパティ名型

デフォルト値

project

Project

Projectインスタンス

nameString

プロジェクトディレクトリの名前

path

String

プロジェクトの絶対パス

description

String

プロジェクトの説明

projectDirFile

ビルドスクリプトのあるディレクトリ

buildDir

File

projectDir/build

group

ObjectversionObjectant

AntBuilder

AntBuilderインスタンス

13.3. スクリプトAPI
ビルドスクリプトが実行されるときは、スクリプトはScriptを実装したクラスにコンパイルされます。つまり、ビルドスクリプトではScript
インターフェースで宣言されているプロパティとメソッドを全て使うことができるということです。

13.4. 変数の宣言
ビルドスクリプトでは、二つの方法で変数を宣言できます。ローカル変数と拡張プロパティです。

13.4.1. ローカル変数
ロ ー カ ル 変 数 は 、 d e f

キーワードで宣言する変数です。変数のスコープは、変数が宣言されている場所に制限されます。なお、ローカル変数

Page 75 of 436

例13.2 ローカル変数を使用する
build.gradle
def dest = "dest"task copy(type: Copy) {from "source"
into dest}

13.4.2. 拡張プロパティ

Gradleのドメインモデルを構成する全ての拡張オブジェクトには、ユーザー定義のプロパティ、拡張プロパティを新た拡張プロパティを追加できるオブジェクトには、projects、tasks、source
setsを始め、様々なオブジェクトがあります。
拡張プロパティをセットしたり読み込んだりするには、対象オブジェクトのext
プロパティを使用して下さい。また、ext
ブロックを使って複数のプロパティを一気に追加することもできます。

Page 76 of 436

例13.3 拡張プロパティを使用する
build.gradle
apply plugin: "java"
ext {springVersion = "3.1.0.RELEASE"
emailNotification = "build@master.org"}
sourceSets.all { ext.purpose = null }sourceSets {main {
purpose = "production"}
test {
purpose = "test"}
plugin {purpose = "production"}}task printProperties << {println springVersion
println emailNotification
sourceSets.matching { it.purpose == "production" }.each { println it.name }}gradle -q printProperties の出力> gradle -q printProperties
3.1.0.RELEASE
build@master.org
mainplugin

この例では、extブロックで二つの拡張プロパティをprojectオブジェクトに追加しています。
さらに、ext.purposeにnullをセットすることで（null
でも構いません）、全てのソースセットにpurposeという拡張プロパティを追加しています。

一度プロパティが追加されれば、定義済みのプロパティと同じように読み込んだり書き込んだりすることができるよう
For further details on extra properties and their API, see the ExtraPropertiesExtension classin the API documentation.

13.5. Groovyの基本

GroovyにはDSLを作るための機能が豊富に用意されていて、Gradleもその長所を活用しています。Gradleビルド言語

Page 77 of 436

13.5.1. Groovy JDKGroovyは、たくさんの便利なメソッドをJavaの標準クラスに追加しています。たとえば、Iterable
に

は

e

a

c

h

というメソッドが追加されていて、要素を走査するときに次のように書くことができます。
例13.4 Groovy JDKのメソッド
build.gradle// Iterable gets an each() method
configurations.runtime.each { File f -> println f }詳細はhttp://groovy.codehaus.org/groovy-jdk/をご参照ください。

13.5.2. プロパティのアクセサ
Groovyは、プロパティ参照を自動的にゲッター/セッターメソッドの呼び出しに変換してくれます。
例13.5 プロパティアクセサ
build.gradle// Using a getter method
println project.buildDirprintln getProject().getBuildDir()// Using a setter method
project.buildDir = 'target'
getProject().setBuildDir('target')13.5.3. メソッド呼び出し時のカッコを省略できる
Groovyではメソッド呼び出しのカッコは省略できます。
例13.6 カッコなしのメソッド呼び出し
build.gradle
test.systemProperty 'some.prop', 'value'
test.systemProperty('some.prop', 'value')

13.5.4. リストリテラル、マップリテラル
Groovyでは、ListやMapのインスタンスを作るときにショートカット記法が使えます。
For instance, the “apply” method (where you typically apply plugins) actually takes a map
parameter. However, when you have a line like “apply plugin:'java'”, you aren't actuallyusing a map literal, you're actually using “named parameters”, which have almost exactly thesame syntax as a map literal (without the wrapping brackets). That named parameter list getsconverted to a map when the method is called, but it doesn't start out as a map.

Page 78 of 436

例13.7 マップリテラル、リストリテラル
build.gradle// List literal
test.includes = ['org/gradle/api/**', 'org/gradle/internal/**']
List<String> list = new ArrayList<String>()list.add('org/gradle/api/**')
list.add('org/gradle/internal/**')
test.includes = list// Map literal.
Map<String, String> map = [key1:'value1', key2: 'value2']// Groovy will coerce named arguments// into a single map argument
apply plugin: 'java'

13.5.5. メソッド引数の最後にクロージャを使う
GradleのDSLでは、クロージャ(詳細はこちら)を多用します。Groovyでは、メソッドの最後の引数がクロージャになっている場合、そのメソッドをクロージャをつ
例13.8 メソッドのクロージャ引数
build.gradle
repositories {println "in a closure"}repositories() { println "in a closure" }repositories({ println "in a closure" })13.5.6. クロージャのdelegateオブジェクト
すべてのクロージャは、delegate
オブジェクトを持っています。クロージャ内では、(クロージャ引数やローカル変数以外の)変数やメソッドは
delegateオブジェクトから検索されます。Gradleの 設定用クロージャ では、delegate
オブジェクトに設定対象のオブジェクトがセットされています。
例13.9 クロージャのdelegatebuild.gradle
dependencies {
assert delegate == project.dependencies
testCompile('junit:junit:4.11')
delegate.testCompile('junit:junit:4.11')}[9] Any language element except for statement labels.

Page 79 of 436

14
色々なチュートリアル
14.1. ディレクトリの作成
複数のタスクが、ある一つのディレクトリが存在していることを前提としている、ということがよくあります。
それらのタスク全てでmkdirを呼ぶことももちろんできますが、それではやはり冗長です。
この場合、次のように、ディレクトリを必要とするタスクにdependsOn関係を追加するのが良い方法です。
例14.1 mkdirでディレクトリを作成する
build.gradle
def classesDir = new File('build/classes')task resources << {classesDir.mkdirs()// do something}task compile(dependsOn: 'resources') << {if (classesDir.isDirectory()) {println 'The class directory exists. I can operate'}// do something}

gradle -q compile の出力> gradle -q compile
The class directory exists. I can operate

14.2. Gradleプロパティとシステムプロパティ
Gradleでは、さまざまな方法でビルドにプロパティ値を渡すことができます。

-D

オプションを使えばGradleを実行しているJVMにシステムプロパティを渡すことができます。
gradleコマンドは-Dオプションをjavaコマンドへの-Dオプションと同じように処理します。
propertiesファイルを記述することで、projectオブジェクトに直接プロパティを追加することもできます。

このプロパティファイルgradle.propertiesはGradleのホームディレクトリ (デフォルトでは USER_HOME /.gradl)かプロジェクトディレクトリに作成します。
マルチプロジェクトの場合、gradle.properteisはすべてのサブプロジェクトディレクトリに置くことができます。
g r a d l e . p r o p e r t i e s

Page 80 of 436

に記述されたプロパティはprojectオブジェクトからアクセスすることができます。
なお、ホームディレクトリのgradle.propertiesは、プロジェクトディレクトリのgradle.propertiesの定義を上書きし、優先的に使用されます。
projectオブジェクトに追加するプロパティは、コマンドラインオプションの-P
オプションで直接設定することもできます。
Gradle can also set project properties when it sees specially-named system properties orenvironment variables. This feature is very useful when you don't have admin rights to acontinuous integration server and you need to set property values that should not be easily
visible, typically for security reasons. In that situation, you can't use the -P option, and you can'tchange the system-level configuration files. The correct strategy is to change the configurationof your continuous integration build job, adding an environment variable setting that matches an
expected pattern. This won't be visible to normal users on the system. [10]projectオブジェクトに追加するプロパティは、コマンドラインオプションの-P

オプションで設定することもできます。また、さらにエキゾチックな使い方に備えて、環境変数やシステムプロパティ
直接取り込む機能もあります。たとえば、管理権限のないマシン上のCIサーバーで継続的なビルドを行う場合について考え-P

オプションは使えません。このときは、プロジェクトの管理者のみアクセスできるようなCIサーバー上のページで環境[11] ここで設定する環境変数名にはあるパターンがあり、ORG_GRADLE_PROJECT_ propertyName =somevalueという環境変数を設定した場合propertyNameというプロパティがプロジェクトに設定されます。また、システムプロパティでも同様のメカニズムを実装しています
org.gradle.project.propertyName となっていること以外は環境変数の場合と同じです。
If the environment variable name looks like ORG_GRADLE_PROJECT_ prop =somevalue, thenGradle will set a prop property on your project object, with the value of somevalue. Gradle also

supports this for system properties, but with a different naming pattern, which looks like org.gradle.project.
.
You can also set system properties in the gradle.properties file. If a property name in such afile has the prefix “systemProp.”, like “systemProp.propName”, then the property and its
value will be set as a system property, without the prefix. In a multi project build, “systemProp.

” properties set in any project except the root will be ignored. That is, only the root project's gradle.properti
file will be checked for properties that begin with the “systemProp.” prefix.
gradle.propertiesファイルでもシステムプロパティを設定することができます。
ファイル内でプレフィックスにsystemPropをつけてプロパティを設定することで、プレフィックス部分をのぞいたプロパティ名でシステムプロパティに追加されPage 81 of 436

例14.2 gradle.propertiesでプロパティを設定する
gradle.properties
gradlePropertiesProp=gradlePropertiesValuesysProp=shouldBeOverWrittenBySysProp
envProjectProp=shouldBeOverWrittenByEnvProp
systemProp.system=systemValuebuild.gradle
task printProps << {println commandLineProjectProp
println gradlePropertiesProp
println systemProjectProp
println envProjectProp
println System.properties['system']}

gradle -q -PcommandLineProjectProp=commandLineProjectPropValue -Dorg.gradle.project.systの出力> gradle -q -PcommandLineProjectProp=commandLineProjectPropValue -Dorg.gradle.project.systemProj
commandLineProjectPropValue
gradlePropertiesValuesystemPropertyValue
envPropertyValuesystemValue

14.2.1. プロジェクトプロパティの確認

プロジェクトに設定されたプロパティは、ビルドスクリプト内では単にプロパティ名でアクセスできます。この場合、hasProperty('propertyName')がtrueやfalseを返すので、それでプロパティの存在を確認できます。

14.3.
外部のビルドスクリプトをプロジェクトに取り込む

外部のビルドスクリプトを取り込んでプロジェクトを設定することができます。取り込む外部スクリプト内では、Gra

Page 82 of 436

例14.3 外部のビルドスクリプトファイルでプロジェクトの設定を行う
build.gradle
apply from: 'other.gradle'

other.gradle
println "configuring $project"task hello << {println 'hello from other script'}

gradle -q hello の出力> gradle -q helloconfiguring root project 'configureProjectUsingScript'
hello from other script

14.4. 任意のオブジェクトを組み立てる
次のような非常に読みやすい方法で、あらゆるオブジェクトを設定することができます。
例14.4 任意のオブジェクトを組み立てる
build.gradle
task configure << {def pos = configure(new java.text.FieldPosition(10)) {beginIndex = 1
endIndex = 5}
println pos.beginIndex
println pos.endIndex}

gradle -q configure の出力> gradle -q configure
1
5

14.5.
外部スクリプトで任意のオブジェクトを組み立てる
外部スクリプトを使って、任意のオブジェクトを組み立てることもできます。

Page 83 of 436

例14.5 外部スクリプトで任意のオブジェクトを組み立てる
build.gradle
task configure << {def pos = new java.text.FieldPosition(10)// Apply the script
apply from: 'other.gradle', to: posprintln pos.beginIndex
println pos.endIndex}

other.gradle

gradle -q configure の出力> gradle -q configure
15

14.6. キャッシング

応答速度を上げるため、Gradleはコンパイル済みのスクリプトをデフォルトですべてキャッシュします。キャッシュ対
.

g

r

a

d

l

e

ディレクトリをプロジェクトディレクトリに作成します。そこにコンパイル済みのスクリプトが保存され、次回のビル--recompile-scripts

オプションをつけてGradleを実行すれば、キャッシュはすべて破棄され、再度コンパイル、保存されます。これにより[11] Teamcityや Bamboo といったCIサーバーがこの機能を持っています。

Page 84 of 436

15
タスク詳解
「 6 章 ビ ル ド ス ク リ プ ト の 基 本」の入門的なチュートリアルでは、簡単なタスクの作り方や、後からタスクにアクションを追加する方法について学び
さらに、タスク間の依存関係を定義する方法についても学びました。
単純なタスクについてはこんなところですが、Gradleはタスクという概念をもっと進化させています。
拡張タスク 、つまり自身のプロパティやメソッドを持ったタスクを使うことができるのです。
これは、今まで使われてきたAntのターゲットとは全く異なる概念です。
拡張タスクは、Gradleがデフォルトで用意しているものもありますし、自分自身で新たに作成することもできます。

15.1. タスクの定義「 6 章 ビ ル ド ス ク リ プ ト の 基 本」で、キーワードを使ったタスク定義を紹介しましたが、タスクの定義方法は他にも少しあります。ときには、それら
例15.1 タスクを定義する
build.gradletask(hello) << {println "hello"}task(copy, type: Copy) {from(file('srcDir'))
into(buildDir)}

タスク名に文字列を使うこともできます。
例15.2 タスクを定義する - タスク名に文字列を使用
build.gradletask('hello') <<{println "hello"}task('copy', type: Copy) {from(file('srcDir'))
into(buildDir)}

Page 85 of 436

他にもいくつかシンタックスが用意されています。もしかすると、これらのシンタックスの方が好みに合うという人も例15.3 その他のタスク定義方法
build.gradle
tasks.create(name: 'hello') << {println "hello"}tasks.create(name: 'copy', type: Copy) {from(file('srcDir'))
into(buildDir)}

この例では、 tasks コレクションにタスクを追加しています。 create()
メソッドのバリエーションについてはTaskContainerをご参照ください。

15.2. タスクを配置する

ビルドファイルから、定義済みのタスクを探して取得したい、というケースがよくあります。例えば、既存のタスクの例15.4 タスクにプロパティとしてアクセスする
build.gradle
task helloprintln hello.nameprintln project.hello.nametasksコレクションからタスクを持ってくることもできます。
例15.5 tasksコレクションからタスクにアクセスする
build.gradle
task helloprintln tasks.hello.nameprintln tasks['hello'].nametasks.getByPath()を使えば、あらゆるプロジェクトのタスクにアクセスできます。getByPath()にはタスク名のほか、タスクの相対パスや絶対パスを渡すことが可能です。

Page 86 of 436

例15.6 パスを使ってタスクにアクセスする
build.gradle
project(':projectA') {task hello}task helloprintln tasks.getByPath('hello').path
println tasks.getByPath(':hello').path
println tasks.getByPath('projectA:hello').path
println tasks.getByPath(':projectA:hello').path

gradle -q hello の出力> gradle -q hello:hello:hello:projectA:hello:projectA:hello

そのほかの方法については、TaskContainerをご参照ください。

15.3. タスクの設定を変更する
例として、Gradleに用意されている Copy タスクを見てみましょう。 Copy
タスクを自分のビルドで作成するには、ビルドスクリプトで次のように宣言します。
例15.7 copyタスクの作成
build.gradle
task myCopy(type: Copy)

作成されたコピータスクには、デフォルトでは何の動作も設定されていません。
タスクは、タスクのAPI( Copy 参照)を使って設定することができます。
次のいくつかの例は、どれも同じ設定を行うものです。
Just to be clear, realize that the name of this task is “ myCopy”, but it is of type “Copy”. You
can have multiple tasks of the same type , but with different names. You'll find this gives you a lotof power to implement cross-cutting concerns across all tasks of a particular type.
例15.8 タスクの設定 - 様々な方法
build.gradle
Copy myCopy = task(myCopy, type: Copy)
myCopy.from 'resources'
myCopy.into 'target'
myCopy.include('**/*.txt', '**/*.xml', '**/*.properties')

Page 87 of 436

これは、普段私たちがJavaオブジェクトを設定するのと同じ方法で設定する方法です。この方法では、設定処理を呼び
myCopy)を何度も書く必要があります。これは冗長だし、あまり可読性もよくありません。

タスクの設定には別の方法があります。この方法でも同様にコンテキストは保持されますし、おそらく最も可読性の高例15.9 タスクの設定 - クロージャの使用
build.gradle
task myCopy(type: Copy)
myCopy {from 'resources'
into 'target'
include('**/*.txt', '**/*.xml', '**/*.properties')}

この方法は、 あらゆる タスクで使用できます。3行目のコードは、tasks.getByName()の単なるショートカットです。大事なことは、getByName()
メソッドにクロージャを渡すと、そのクロージャがタスクが実行されるときではなく、 設定
されるときに適用されるという点です。
また、タスクを定義するときに、同時に設定クロージャを使うこともできます。
例15.10 クロージャを伴うタスク定義
build.gradle
task copy(type: Copy) {from 'resources'
into 'target'
include('**/*.txt', '**/*.xml', '**/*.properties')}

15.4.
タスクに依存関係を追加する

Don't forget about
the build phases
A

task

has

both

タスクの依存関係を定義する方法はいくつかあります。

configuration and actions.

「タスクの依存関係」

When using the <<, you aresimply using a shortcut to
では、タスク名を使って依存関係を定義する方法を紹介しました。タスク名を使うと、同じプロジェクトのタスク、まdefine an action. CodeprojectA:taskX から projectB:taskYへの依存関係を定義しています。

defined in the configuration
section of your task will get
executed

duringtheconfiguration phase of thebuild regardless of what task
wastargeted.

See

ビルドのライフサイクル

56章
for

more details about the build
lifecycle.

Page 88 of 436

例15.11 別プロジェクトのタスクとの依存関係を定義する
build.gradle
project('projectA') {task taskX(dependsOn: ':projectB:taskY') << {println 'taskX'}}
project('projectB') {task taskY << {println 'taskY'}}

gradle -q taskX の出力> gradle -q taskX
taskY
taskX

タスク名を使う代わりに、次の例のように、Task
オブジェクトを使って依存関係を定義することも出来ます。
例15.12 taskオブジェクトを使った依存関係定義
build.gradle
task taskX << {println 'taskX'}
task taskY << {println 'taskY'}
taskX.dependsOn taskY

gradle -q taskX の出力> gradle -q taskX
taskY
taskX

より上級ユーザー向けの方法として、クロージャを使って依存関係を定義することが出来ます。評価フェーズ時に、そPage 89 of 436

例15.13 クロージャを使った依存関係定義
build.gradle
task taskX << {println 'taskX'}
taskX.dependsOn {tasks.findAll { task -> task.name.startsWith('lib') }}task lib1 << {println 'lib1'}
task lib2 << {println 'lib2'}
task notALib << {println 'notALib'}

gradle -q taskX の出力> gradle -q taskX
lib1
lib2
taskX

さらにタスクの依存関係に関する情報を得るには、Task APIを参照してください。

15.5. Ordering tasks
Task ordering is an incubating feature. Please be aware that this feature may change inlater Gradle versions.

In some cases it is useful to control the order in which 2 tasks will execute, without introducing
an explicit dependency between those tasks. The primary difference between a task orderingand a task dependency is that an ordering rule does not influence which tasks will be executed,
only the order in which they will be executed.
Task ordering can be useful in a number of scenarios:
Enforce sequential ordering of tasks: eg. 'build' never runs before 'clean'.
Run build validations early in the build: eg. validate I have the correct credentials before
starting the work for a release build.
Get feedback faster by running quick verification tasks before long verification tasks: eg. unit
tests should run before integration tests.
A task that aggregates the results of all tasks of a particular type: eg. test report task

Page 90 of 436

combines the outputs of all executed test tasks.
There are two ordering rules available: “ must run after ” and “ should run after ”.
When you use the “must run after” ordering rule you specify that taskB must always run after taskA, whenever both taskA and taskB will be run. This is expressed as taskB.mustRunAfter(taskA). The “should run after” ordering rule is similar but less strict as it will be ignored in two
situations. Firstly if using that rule introduces an ordering cycle. Secondly when using parallel
execution and all dependencies of a task have been satisfied apart from the “should run after”
task, then this task will be run regardless of whether its “should run after” dependencies havebeen run or not. You should use “should run after” where the ordering is helpful but notstrictly required.
With these rules present it is still possible to execute taskA without taskB and vice-versa.
例15.14 Adding a 'must run after' task orderingbuild.gradle
task taskX << {println 'taskX'}
task taskY << {println 'taskY'}
taskY.mustRunAfter taskX

gradle -q taskY taskX の出力> gradle -q taskY taskX
taskX
taskY

例15.15 Adding a 'should run after' task orderingbuild.gradle
task taskX << {println 'taskX'}
task taskY << {println 'taskY'}
taskY.shouldRunAfter taskX

gradle -q taskY taskX の出力> gradle -q taskY taskX
taskX
taskY

In the examples above, it is still possible to execute taskY without causing taskX to run:Page 91 of 436

例15.16 Task ordering does not imply task execution
gradle -q taskY の出力> gradle -q taskY
taskY

To specify a “must run after” or “should run after” ordering between 2 tasks, you use theTask.mustRunAfter() and Task.shouldRunAfter() methods. These methods accept a task
instance, a task name or any other input accepted by Task.dependsOn().
Note that “B.mustRunAfter(A)” or “B.shouldRunAfter(A)” does not imply any
execution dependency between the tasks:
It is possible to execute tasks A and B independently. The ordering rule only has an effectwhen both tasks are scheduled for execution.
When run with --continue, it is possible for B to execute in the event that A fails.
As mentioned before, the “should run after” ordering rule will be ignored if it introduces anordering cycle:
例15.17 A 'should run after' task ordering is ignored if it introduces an ordering cycle
build.gradle
task taskX << {println 'taskX'}
task taskY << {println 'taskY'}
task taskZ << {println 'taskZ'}
taskX.dependsOn taskY
taskY.dependsOn taskZ
taskZ.shouldRunAfter taskX

gradle -q taskX の出力> gradle -q taskX
taskZ
taskY
taskX

15.6. タスクに説明書きを追加する定義したタスクに、説明書きを追加できます。追加した説明は、たとえばgradletasksを実行したときなどに表示されます。

Page 92 of 436

例15.18 タスクに説明書きを追加する
build.gradle
task copy(type: Copy) {description 'Copies the resource directory to the target directory.'
from 'resources'
into 'target'
include('**/*.txt', '**/*.xml', '**/*.properties')}

15.7. タスクの置き換えときには、タスクを置き換えたくなることがあります。例えば、Javaプラグインによって追加されたタスクを、別のタ例15.19 タスクの上書き
build.gradle
task copy(type: Copy)
task copy(overwrite: true) << {println('I am the new one.')}gradle -q copy の出力> gradle -q copy
I am the new one.

こ こ で は 、 C o p y
タイプのタスクを、シンプルな別のタスクに置き換えています。タスクを作成するときに、overwrite

プロパティをtrueにセットしなければなりません。そうしないと、Gradleは例外を投げ、すでに同名のタスクが定義済

15.8. タスクをスキップする
Gradleは、タスクの実行をスキップする方法を複数用意しています。

15.8.1. 述語を使う
o

n

l

y

I

f

(

)

メソッドを使って、タスクに述語を付けることができます。タスクは、付加された述語がtrueと評価されたときのみ実

Page 93 of 436

例15.20 述語でタスクをスキップ
build.gradle
task hello << {println 'hello world'}
hello.onlyIf { !project.hasProperty('skipHello') }gradle hello -PskipHello の出力> gradle hello -PskipHello:hello SKIPPEDBUILD SUCCESSFUL
Total time: 1 secs

15.8.2. StopExecutionExceptionを使う
タスクスキップのルールが述語で表現できない場合、StopExecutionExceptionを使うことができます。この例外がタスクのアクションから投げられたら、実行中のアクション、およびそのタスクの例15.21 StopExecutionExceptionでタスクをスキップ
build.gradle
task compile << {println 'We are doing the compile.'}
compile.doFirst {// Here you would put arbitrary conditions in real life.
// But this is used in an integration test so we want defined behavior.
if (true) { throw new StopExecutionException() }}task myTask(dependsOn: 'compile') << {println 'I am not affected'}

gradle -q myTask の出力> gradle -q myTask
I am not affected

この機能は、Gradleが標準提供しているタスクが絡んでいるときに役に立ちます。このようなビルドインのタスクを、
条件付き で実行させることができるのです。 [13]15.8.3. タスクの有効化と無効化
す べ て の タ ス ク は 、 e n a b l e d

フラグを持っており、デフォルトではtrueに設定されています。このフラグをfalseにすると、そのタスクのすべてのア

Page 94 of 436

例15.22 タスクの有効化と無効化
build.gradle
task disableMe << {println 'This should not be printed if the task is disabled.'}
disableMe.enabled = false

gradle disableMe の出力> gradle disableMe:disableMe SKIPPEDBUILD SUCCESSFUL
Total time: 1 secs

15.9. 更新されていないタスクをスキップする

JavaプラグインのようなGradleが提供しているタスクを使ったとき、Gradleが未更新(UP-TO-DATE)のタスクをスキッ

15.9.1. タスクの入力物と出力物を宣言する

一つ例を見てみましょう。ここでは、定義したタスクが、XMLのソースファイルを元にいくつかのファイルを出力してPage 95 of 436

例15.23 生成タスク
build.gradle
task transform {ext.srcFile = file('mountains.xml')
ext.destDir = new File(buildDir, 'generated')doLast {println "Transforming source file."
destDir.mkdirs()
def mountains = new XmlParser().parse(srcFile)
mountains.mountain.each { mountain ->def name = mountain.name[0].text()
def height = mountain.height[0].text()
def destFile = new File(destDir, "${name}.txt")
destFile.text = "$name -> ${height}\n"}}}gradle transform の出力> gradle transform:transform
Transforming source file.

gradle transform の出力> gradle transform:transform
Transforming source file.

タスクを2回目に実行したとき、なにも変更されていないにもかかわらず、タスクの実行がスキップされなかったことすべてのタスクにはinputsプロパティとoutputs

プロパティがあります。これが入力と出力を宣言するために使うプロパティです。次の例では、先ほどの例を修正し、Page 96 of 436

例15.24 タスクの入力と出力を宣言
build.gradle
task transform {ext.srcFile = file('mountains.xml')
ext.destDir = new File(buildDir, 'generated')
inputs.file srcFile
outputs.dir destDir
doLast {println "Transforming source file."
destDir.mkdirs()
def mountains = new XmlParser().parse(srcFile)
mountains.mountain.each { mountain ->def name = mountain.name[0].text()
def height = mountain.height[0].text()
def destFile = new File(destDir, "${name}.txt")
destFile.text = "$name -> ${height}\n"}}}gradle transform の出力> gradle transform:transform
Transforming source file.

gradle transform の出力> gradle transform:transform UP-TO-DATE

これで、GradleはタスクがUP-TO-DATEなのかどうかを決定するため、どのファイルをチェックするべきか知ることがタスクのinputsプロパティはTaskInputs型、outputsプロパティはTaskOutputs型です。
A task with no defined outputs will never be considered up-to-date. For scenarios where theoutputs

of

a

task

are

not

files,

or

for

more

complexscenarios,

theTaskOutputs.upToDateWhen() method allows you to calculate programmatically if the tasks
outputs should be considered up to date.
A task with only outputs defined will be considered up-to-date if those outputs are unchanged
since the previous build.

15.9.2. どのように動作するのか？

タスクが初回に実行されるとき、実行前にGradleは入力物のスナップショットをとります。このスナップショットには
この後は、タスクが実行される前に毎回、入力物と出力物のスナップショットを新しく作成します。

もし、新しいスナップショットが、前回のスナップショットと同じなら、Gradleは出力がUP-TO-DATEだと見なし、タ

スナップショットが異なっていれば、Gradleはタスクを実行し、次回実行されるときのためにスナップショットを保存
Note that if a task has an output directory specified, any files added to that directory since thelast time it was executed are ignored and will NOT cause the task to be out of date. This is soPage 97 of 436

unrelated tasks may share an output directory without interfering with each other. If this is not
the behaviour you want for some reason, consider using TaskOutputs.upToDateWhen()

15.10. タスクルール

ときには、広範囲、または無限大な範囲のパラメータに応じた動作を行うタスクを定義したくなることがあります。こ
例15.25 タスクルール
build.gradle
tasks.addRule("Pattern: ping<ID>") { String taskName ->if (taskName.startsWith("ping")) {task(taskName) << {println "Pinging: " + (taskName - 'ping')}}}

gradle -q pingServer1 の出力> gradle -q pingServer1
Pinging: Server1

文字列が引数に渡されていますが、これはルールの説明として使用されます。例えば、gradle tasksを実行したときなどに表示されます。

ルールは、ただコマンドラインからのタスク呼び出しにのみ使えるものではありません。dependsOnによる依存関係
例15.26 ルールベース・タスクの依存関係
build.gradle
tasks.addRule("Pattern: ping<ID>") { String taskName ->if (taskName.startsWith("ping")) {task(taskName) << {println "Pinging: " + (taskName - 'ping')}}}
task groupPing {dependsOn pingServer1, pingServer2}

gradle -q groupPing の出力> gradle -q groupPing
Pinging: Server1
Pinging: Server2

If you run “gradle -q tasks” you won't find a task named “pingServer1” or “pingServer2”, but this script is executing logic based on the request to run those tasks.

Page 98 of 436

15.11. Finalizer tasks
Finalizers tasks are an incubating feature (see 「試験的 」).

Finalizer tasks are automatically added to the task graph when the finalized task is scheduled torun.
例15.27 Adding a task finalizer
build.gradle
task taskX << {println 'taskX'}
task taskY << {println 'taskY'}
taskX.finalizedBy taskY

gradle -q taskX の出力> gradle -q taskX
taskX
taskY

Finalizer tasks will be executed even if the finalized task fails.
例15.28 Task finalizer for a failing taskbuild.gradle
task taskX << {println 'taskX'
throw new RuntimeException()}task taskY << {println 'taskY'}
taskX.finalizedBy taskY

gradle -q taskX の出力> gradle -q taskX
taskX
taskY

On the other hand, finalizer tasks are not executed if the finalized task didn't do any work, forexample if it is considered up to date or if a dependent task fails.
Finalizer tasks are useful in situations where the build creates a resource that has to be cleaned
up regardless of the build failing or succeeding. An example of such a resource is a web

Page 99 of 436

container that is started before an integration test task and which should be always shut down,even if some of the tests fail.
To specify a finalizer task you use the Task.finalizedBy() method. This method accepts atask instance, a task name, or any other input accepted by Task.dependsOn().

15.12. まとめ
以前にAntを使ったことがあれば、Copyのような拡張タスクは、Antのターゲットとタスクの間をとったようなものに見えるでしょう。

Antのタスクとターゲットは実際には異なるエンティティですが、Gradleはこれらの記法を1つのエンティティにまと単純なGradleのタスクはAntのターゲットのようなものだし、拡張タスクはAntタスクの性質を含んでいます。
すべてのGradleタスクは、同じのAPIを共有していて、タスク間の依存関係を定義することができます。
このため、GradleのタスクはAntタスクに比べて、より設定しやすいものになっているでしょう。
Gradleのタスクは、型システムをフル活用しており、より表現力豊かで、メンテナンス性もよくなっています。

[
なぜimport文も完全修飾名も使用せずStopExecutionExceptionにアクセスできているのか不思議に思われたかもしれ
1
3]
付録E IDE対応の現状と、IDEによらない開発支援参照)。

Page 100 of 436

16
ファイルを取り扱うファイルの取り扱いは、ほとんどのビルドで発生する作業です。なので、それを補助するため、Gradleはいくつかの概16.1. ファイルを参照する
P r o j e c t . f i l e ( )メソッドで、プロジェクトディレクトリからの相対参照でファイルを取得できます。
例16.1 ファイルを参照する
build.gradle// Using a relative path
File configFile = file('src/config.xml')// Using an absolute pathconfigFile = file(configFile.absolutePath)// Using a File object with a relative pathconfigFile = file(new File('src/config.xml'))

f

i

l

e

(

)

メソッドには、あらゆるオブジェクトを渡すことができます。渡したオブジェクトは、絶対参照のFileに変換されます。大抵はStringかFileのインスタンスを渡すことになるでしょう。渡されたオブジェクトのtoString()が呼ばれ、その返値がファイルパスとして使われます。もしそのパスが絶対パスだった場合、そのパスで
F

i

l

e

インスタンスが構築されます。そうでなければ、プロジェクトディレクリのパスを先頭に追加してからFileインスタンスが構築されます。また、file()メソッドはfile:/some/path.xmlのようなURLにも対応しています。
このメソッドを使って、ユーザーが指定した値を簡単に絶対参照のFile
インスタンスに変換できます。 これは、new File(somePath)を使うよりもよい方法でしょう。file()

メソッドは、常にプロジェクトディレクリからの相対参照で解決されるからです。ワーキングディレクトリはGradleを

Page 101 of 436

16.2. ファイルコレクション
ファイルコレクション は、単なるファイルの集合です。これは、 FileCollection
インターフェースで表現されます。Gradle

APIに含まれる多くのオブジェクトがこのインターフェースを実装しています。例えば、依存関係のコンフィグレーシ
もこのFileCollectionインターフェースを実装しています。
FileCollection を取得する方法の一つは、 Project.files()
メソッドを使うことです。このメソッドには任意の数のオブジェクトを渡すことができ、渡したオブジェクトはFileオブジェクトの集合に変換されます。これらのオブジェクトは、「ファイルを参照する」

で 述 べ た f i l e ( )メソッドと同じように、プロジェクトディレクトリからの相対参照で解決されます。

また、コレクション、イテレーブル、マップ、配列を渡すこともできます。これらは、フラット化されてから、各要素
Fileインスタンスに変換されます。
例16.2 ファイルコレクションの作成
build.gradle
FileCollection collection = files('src/file1.txt',
new File('src/file2.txt'),['src/file3.txt', 'src/file4.txt'])

ファイルコレクションはイテレーブルです。さらに、as演算子で様々な型に変換することができます。

また、二つのファイルコレクションを+演 算 子 で 合 成 し た り 、 演算子でファイルコレクションから別のファイルコレクションの要素を取り除いたりすることができます。
次の例は、ファイルコレクションでどのようなことができるかを示すものです。
例16.3 ファイルコレクションを使う
build.gradle// Iterate over the files in the collection
collection.each {File file ->println file.name}// Convert the collection to various types
Set set = collection.files
Set set2 = collection as Set
List list = collection as List
String path = collection.asPath
File file = collection.singleFile
File file2 = collection as File// Add and subtract collections
def union = collection + files('src/file3.txt')
def different = collection - files('src/file3.txt')

files()メソッドには、クロージャやCallableのインスタンスを渡すこともできます。

Page 102 of 436

これはそのファイルコレクションの内容が要求されたときに実行され、返値がFile
インスタンスの集合に変換されます。返値はfiles()に渡すことができるオブジェクトならなんでも構いません。これは、FileCollection
インタフェースを簡単に「実装する」方法とも言えます。
例16.4 ファイルコレクションを実装する
build.gradle
task list << {File srcDir// Create a file collection using a closure
collection = files { srcDir.listFiles() }srcDir = file('src')
println "Contents of $srcDir.name"collection.collect { relativePath(it) }.sort().each { println it }srcDir = file('src2')
println "Contents of $srcDir.name"collection.collect { relativePath(it) }.sort().each { println it }}gradle -q list の出力> gradle -q list
Contents of src
src/dir1
src/file1.txt
Contents of src2
src2/dir1
src2/dir2

他にもいくつかfiles()メソッドに渡せる型があります。
FileCollection
フラット化されてから、その内容がファイルコレクションに追加される。
Task
タスクの出力ファイルがファイルコレクションに追加される。
TaskOutputs
TaskOutputsの出力ファイルがファイルコレクションに追加される。
留意すべき重要な点は、ファイルコレクションの内容は、必要になったときに遅延評価されるということです。
これはつまり、例えば未来にタスクなどによって作られるであろうファイル群を表すFileCollection
を作ることもできる、ということを意味します。

Page 103 of 436

16.3. ファイルツリー

ファイルツリーは、階層構造を持つファイルの集合です。例えば、ディレクトリツリーやZIPの中身を表すことができ
FileTreeインターフェースによって表現されます。FileTreeインターフェースはFileCollection
インターフェースを継承しています。なので、FileTreeはFileCollectionと全く同じ方法で取り扱うことができます。
いくつかのGradleオブジェクトはFileTreeを実装しています。例えば、ソースセットなどです。
FileTree インスタンスを取得する方法の一つは、 Project.fileTree()メ ソ ッ ド を 使 用 す る こ と で す 。
このメソッドは、ベースディレクトリとAntスタイルのinclude/excludeパターンを指定してFileTreeを構築します。
例16.5 ファイルツリーを作成する
build.gradle// Create a file tree with a base directory
FileTree tree = fileTree(dir: 'src/main')// Add include and exclude patterns to the tree
tree.include '**/*.java'
tree.exclude '**/Abstract*'// Create a tree using pathtree = fileTree('src').include('**/*.java')// Create a tree using closure
tree = fileTree('src') {include '**/*.java'}// Create a tree using a map
tree = fileTree(dir: 'src', include: '**/*.java')
tree = fileTree(dir: 'src', includes: ['**/*.java', '**/*.xml'])tree = fileTree(dir: 'src', include: '**/*.java', exclude: '**/*test*/**')

ファイルツリーは、ファイルコレクションと同じ方法で使うことができます。さらに、ツリー構造を辿ったり、Antス

Page 104 of 436

例16.6 ファイルツリーを使う
build.gradle// Iterate over the contents of a tree
tree.each {File file ->println file}// Filter a tree
FileTree filtered = tree.matching {include 'org/gradle/api/**'}// Add trees together
FileTree sum = tree + fileTree(dir: 'src/test')// Visit the elements of the tree
tree.visit {element ->println "$element.relativePath => $element.file"}

16.4.
アーカイブの内容をファイルツリーとして使う
ZIPやTARファイルなどのアーカイブを、ファイルツリーとして使うことができます。そのためのメソッドが、
Project.zipTree()やProject.tarTree()です。これらのメソッドは、FileTree

インスタンスを返すもので、返されたインスタンスは、他のファイルツリーやファイルコレクションと同様に扱うこと
例えば、内容をコピーすることでアーカイブを解凍したり、別のアーカイブとマージしたりできます。
例16.7 アーカイブをファイルツリーとして使う
build.gradle// Create a ZIP file tree using path
FileTree zip = zipTree('someFile.zip')// Create a TAR file tree using path
FileTree tar = tarTree('someFile.tar')//tar tree attempts to guess the compression based on the file extension//however if you must specify the compression explicitly you can:FileTree someTar = tarTree(resources.gzip('someTar.ext'))

Page 105 of 436

16.5. 入力ファイルセットを指定する
多くのGradleオブジェクトが入力ファイルセットを格納できるプロパティを持っています。例えば、JavaCompileタスクにはsource
プロパティがあり、コンパイルするべきソースファイルの集合をそこに定義します。
このプロパティの値には、files()でサポートされている、上記の全ての型が使用可能です。
つまり、 File 、 String 、コレクション、 FileCollection、クロージャでさえセット可能ということです。次の例を見てください。
例16.8 ファイルセットを指定する
build.gradle// Use a File object to specify the source directorycompile {source = file('src/main/java')}// Use a String path to specify the source directorycompile {source = 'src/main/java'}// Use a collection to specify multiple source directories
compile {source = ['src/main/java', '../shared/java']}// Use a FileCollection (or FileTree in this case) to specify the source files
compile {source = fileTree(dir: 'src/main/java').matching { include 'org/gradle/api/**' }}// Using a closure to specify the source files.
compile {source = {// Use the contents of each zip file in the src dirfile('src').listFiles().findAll {it.name.endsWith('.zip')}.collect { zipTree(it) }}}大抵、そのプロパティと同名のメソッドも定義されていて、そのメソッドでファイルセットを追加できるようになって
files()でサポートされている全ての型を渡すことができます。

Page 106 of 436

例16.9 ファイルセットを指定する
build.gradle
compile {// Add some source directories use String paths
source 'src/main/java', 'src/main/groovy'// Add a source directory using a File object
source file('../shared/java')// Add some source directories using a closuresource { file('src/test/').listFiles() }}16.6. ファイルをコピーする
C

o

p

y

タスクを使ってファイルをコピーできます。このタスクはとても柔軟で、コピーしたファイルの内容をフィルターにか
C

o

p

y

タスクを使うには、コピーすべきソースファイルと、コピー先のディレクトリを指定しなければなりません。また、コ
Copy仕様 を使って行います。Copy仕様は、CopySpecインターフェースで表現されており、Copy
タスクはこのインターフェースを実装したものです。ソースファイルの指定には、
CopySpec.from()メソッドを使います。コピー先ディレクトリの指定には、CopySpec.into()
メソッドを使います。
例16.10 Copyタスクでファイルをコピーする
build.gradle
task copyTask(type: Copy) {from 'src/main/webapp'into 'build/explodedWar'}from()メソッドが受け付ける型は、files()メソッドと同じです。ディレクトリパスに解決されるような引数を渡した場合、そのディレクトリ以下の全て（ただしもし、引数に渡したパスにファイルがない場合、その引数は無視されます。

引数にタスクを渡した場合、そのタスクの出力ファイル(タスクが作成するファイル)がコピーされ、そのタスクは自動
into()メソッドは、file()と同じ型を引数に取ります。以下にもう一つ例を挙げます。

Page 107 of 436

例16.11 Copyタスクのコピー元と宛先を指定する
build.gradle
task anotherCopyTask(type: Copy) {// Copy everything under src/main/webapp
from 'src/main/webapp'// Copy a single filefrom 'src/staging/index.html'// Copy the output of a task
from copyTask// Copy the output of a task using Task outputs explicitly.
from copyTaskWithPatterns.outputs// Copy the contents of a Zip filefrom zipTree('src/main/assets.zip')// Determine the destination directory later
into { getDestDir() }}Antスタイルのinclude/excludeパターンかクロージャを用いて、コピーするファイルを選択することができます。
例16.12 コピーするファイルを選択する
build.gradle
task copyTaskWithPatterns(type: Copy) {from 'src/main/webapp'into 'build/explodedWar'
include '**/*.html'
include '**/*.jsp'
exclude { details -> details.file.name.endsWith('.html') &&details.file.text.contains('staging') }}ま た 、 P r o j e c t . c o p y ( )メソッドでファイルをコピーすることもできます。これはタスクの場合と大体同じように動作しますが、いくつかの大copy()メソッドはインクリメンタルには実施されません(「更新されていないタスクをスキップする」参照)。
例16.13 copy()メソッドで更新チェックせずにファイルをコピーする
build.gradle
task copyMethod << {copy {
from 'src/main/webapp'into 'build/explodedWar'
include '**/*.html'
include '**/*.jsp'}}

次に、タスクがコピー元として使われる場合(from()メソッドの引数になる場合)でも、copy()
メソッドはタスクの依存関係を考慮しません。copy()はあくまでメソッドであってタスクではないからです。

よって、copy()メソッドをタスクアクションの中で呼び出す場合は、正しく動作させるために明示的に全ての入力と出Page 108 of 436

例16.14 copy()メソッドで更新チェックを実施してファイルをコピーする
build.gradle
task copyMethodWithExplicitDependencies{// up-to-date check for inputs, plus add copyTask as dependency
inputs.file copyTask
outputs.dir 'some-dir' // up-to-date check for outputs
doLast{copy {// Copy the output of copyTask
from copyTask
into 'some-dir'}}}

で き る だ け C o p y

タスクのほうを使用するようにしてください。そうすれば、余計な手間をかけずにインクリメンタルビルドやタスク依
一方、copy()メソッドは、あるタスクの実装の 一部としてファイルコピーを組み込むことができます。

つまり、copy()メソッドはカスタムタスク(58章

カ ス タ ム タ ス ク の 作 成参照)の機能でファイルコピーが必要になった場合に使用されることを想定しています。

そのカスタムタスクでは、ファイルコピーの実際の仕様に基づいて適切に入力と出力が宣言されていなければなりませ16.6.1. ファイルをリネームする
例16.15 コピー時にファイルをリネームする
build.gradle
task rename(type: Copy) {from 'src/main/webapp'into 'build/explodedWar'// Use a closure to map the file namerename { String fileName ->fileName.replace('-staging-', '')}// Use a regular expression to map the file namerename '(.+)-staging-(.+)', '$1$2'
rename(/(.+)-staging-(.+)/, '$1$2')}

Page 109 of 436

16.6.2. ファイルをフィルタリングする
例16.16 コピー時にファイルをフィルタリングする
build.gradle
import org.apache.tools.ant.filters.FixCrLfFilter
import org.apache.tools.ant.filters.ReplaceTokens
task filter(type: Copy) {from 'src/main/webapp'into 'build/explodedWar'// Substitute property tokens in files
expand(copyright: '2009', version: '2.3.1')
expand(project.properties)// Use some of the filters provided by Ant
filter(FixCrLfFilter)
filter(ReplaceTokens, tokens: [copyright: '2009', version: '2.3.1'])// Use a closure to filter each line
filter { String line ->"[$line]"}}A “token” in a source file that both the “expand” and “filter” operations look for, isformatted like “@tokenName@” for a token named “tokenName”.

16.6.3. CopySpecクラスを使う

コピー仕様は階層構造を構成でき、宛先パス、include/excludeパターン、コピー動作、ファイル名のマッピング、フ例16.17 入れ子構造のコピー仕様
build.gradle
task nestedSpecs(type: Copy) {into 'build/explodedWar'
exclude '**/*staging*'from('src/dist') {include '**/*.html'}
into('libs') {from configurations.runtime}}

16.7. Syncタスクを使う
S y n c は C o p y

タスクを継承したタスクです。このタスクは、宛先ディレクトリにファイルをコピーし、その後、コピーしたファイル
次の例では、build/libsにある実行時依存関係のコピーをメンテナンスしています。

Page 110 of 436

例16.18 Syncタスクで依存関係をコピーする
build.gradle
task libs(type: Sync) {from configurations.runtime
into "$buildDir/libs"}

16.8. アーカイブを作成する

一つのプロジェクトで、JARファイルを好きなだけ作成することができます。WAR、ZIP、TARなどのアーカイブをプ
アーカイブは、 Zip、 Tar、 Jar、 War、 Earなどのアーカイブタスクを使って作成します。
これらは全て同じ使い方なので、ここではZIPファイルの作成方法を見てみましょう。
例16.19 ZIPアーカイブの作成
build.gradle
apply plugin: 'java'
task zip(type: Zip) {from 'src/dist'into('libs') {from configurations.runtime}}

アーカイブタスクは、全てCopy
タスクと全く同じように動作します。これらのタスクは、Copyタスク同様、
CopySpecインターフェースを実装しています。Copy
タスクと同じようにfrom()

なぜJavaプラグインを使うのです

Javaプラグインは、アーカイブタスクに多くのデフメソッドで入力ファイルを指定し、必須ではありませんがinto()

メソッドで最終的にアーカイブが出力される場所を指定します。ファイルのフィルタリング、リネーム、その他コピー

16.8.1. アーカイブのネーミング
The format of projectName - version . type is used for generated archive file names. For
example:
作成されるアーカイブの名前は、デフォルトでは projectName - version . type です。例えば、

Page 111 of 436

例16.20 ZIPアーカイブの作成
build.gradle
apply plugin: 'java'
version = 1.0
task myZip(type: Zip) {from 'somedir'}
println myZip.archiveName
println relativePath(myZip.destinationDir)
println relativePath(myZip.archivePath)

gradle -q myZip の出力> gradle -q myZip
zipProject-1.0.zip
build/distributions
build/distributions/zipProject-1.0.zip

ここでは、myZipという名前の Zip アーカイブタスクが、 zipProject-1.-.zipというZIPファイルを作成しています。大事なことは、アーカイブタスクの名前と、そのタスクで作成したアーカイブ
a r c h i v e s B a s e N a m e
プロパティで変更できます。そのアーカイブ名も、後からいつでも変更可能です。
アーカイブタスクにセットできるプロパティはたくさんあります。それらを下の表16.1「アーカイブタスク-

ネーミングプロパティ」にリストしました。例えば、アーカイブの名前を変更したい場合は次のようにします。
例16.21 アーカイブタスクの設定 - カスタムアーカイブ名
build.gradle
apply plugin: 'java'
version = 1.0
task myZip(type: Zip) {from 'somedir'baseName = 'customName'}
println myZip.archiveName

gradle -q myZip の出力> gradle -q myZip
customName-1.0.zip

アーカイブ名をさらにカスタマイズすることもできます。

Page 112 of 436

例16.22 アーカイブタスクの設定 - appendix & classifierbuild.gradle
apply plugin: 'java'archivesBaseName = 'gradle'
version = 1.0
task myZip(type: Zip) {appendix = 'wrapper'classifier = 'src'
from 'somedir'}
println myZip.archiveName

gradle -q myZip の出力> gradle -q myZip
gradle-wrapper-1.0-src.zip

表16.1 アーカイブタスク - ネーミングプロパティ
プロパティ名型

デフォルト値

archiveName

StringbaseName-appendix-version-classifier.extension
プロパティが空だった場合、それに伴う-も追加されない。

archivePathFiledestinationDir/archiveName

destinationDir

File

アーカイブの種類に依存する。JAR、WARの場合はproject.buildDir/librar。ZIP、TARの場合はproject.buildDir/distributions。

baseName

Stringproject.nameappendix

Stringnull

versionStringproject.version

classifier

Stringnull

extension

Stringアーカイブの種類に依存する。TARファイルの場合、圧縮方法にも依存する。zip, jar, war, tar, tgz or tbz2.

16.8.2. 複数のアーカイブで中身を共有する
Project.copySpec()メソッドを使ってアーカイブ間で中身を共有できます。

アーカイブを別のプロジェクトで使えるようにするために、そのアーカイブを公開したくなることがよくあります。こ52章アーティファクトの公開 に記載されています。

Page 113 of 436

17
GradleからAntを使う
Gradleは優れたAntとの統合機能を提供しています。
Gradleビルドの中で、個別のAntタスクや、Antビルド全体を利用することができます。

実際、AntのXMLフォーマットを利用するよりも、Gradleビルドの中でAntタスクを使う方がはるかに簡単でより強力
Gradleを単に強力なAntスクリプティングツールとして使ってもよいくらいです。
Antは二つのレイヤーに分割できます。

第一のレイヤーはAnt言語で、build.xmlの文法やターゲットの取り扱い、およびmacrodefのような特別な構成要素などを提供します。
別の言い方では、Antタスクとタイプを除くすべてのものです。
Gradleはこの言語を理解し、GradleプロジェクトにAntのbuild.xml
を直接インポートすることを可能にしています。
そのため、AntビルドのターゲットをGradleのタスクであるかのように利用することができます。
Antの第二のレイヤーは、javacやcopy、jarといった豊富なAntタスクやタイプの資産です。
このレイヤーに対してはGroovyのすばらしいAntBuilderが利用できるため、Gradleはシンプルな統合機能を提供するのみです。
最後に、ビルドスクリプトはGroovyスクリプトなので、いつでもAntビルドを外部プロセスとして実行できます。
ビルドスクリプトは"antcleancompile".execute()のような実行文を含んでいてもかまいません。 [15]GradleのAnt統合機能を、AntからGradleへのビルド移行パスとして利用することもできます。
例えば、既存のAntビルドをインポートするところから始めてもよいでしょう。
それから、依存関係の宣言をAntスクリプトから新しいビルドファイルへ移動していきます。
最後に、タスクを新しいビルドファイルへ移動するか、Gradleプラグインで置き換えます。
このプロセスは一部分づつ段階的に実施でき、プロセス全体を通してGradleによるビルドを利用できます。

17.1. ビルドでのAntタスクとタイプの利用
ビルドスクリプトではGradleによってプロパティantが提供されます。
インスタンスへの参照です。

これはAntBuilder
このAntBuilder

はビルドスクリプトからAntタスクやタイプ、プロパティへのアクセスに利用します。 Antのbuild.xml
フォーマットからGroovyへのマッピングは非常に簡単です。 以下で説明します。
Antタスクを実行するには、 AntBuilder インスタンスのメソッドを呼び出します。
Antタスク名がメソッド名になります。 例えば、Antのechoタスクを実行する場合は、ant.echo()
メソッドを呼び出します。

Antタスクの属性は、メソッドにMap型のパラメータとして渡します。

以下はechoタスクを実行するサンプルです。

Page 114 of 436

GroovyコードとAntタスクのマークアップを混在できることに注意してください。
これは非常に強力です。
例17.1 Antタスクの利用
build.gradle
task hello << {String greeting = 'hello from Ant'
ant.echo(message: greeting)}gradle hello の出力> gradle hello:hello[ant:echo] hello from Ant
BUILD SUCCESSFUL
Total time: 1 secs

Antタスクのメソッド呼び出しのパラメータとして渡してやることで、ネストされたテキストをAntタスクに渡すことがこの例では、echoタスクに対するメッセージをネストされたテキストとして渡しています。
例17.2 Antタスクにネストされたテキストを渡す
build.gradle
task hello << {ant.echo('hello from Ant')}

gradle hello の出力> gradle hello:hello[ant:echo] hello from Ant
BUILD SUCCESSFUL
Total time: 1 secs

Antタスクにネストされた要素を渡す場合はクロージャの内部に記述します。
ネストされた要素はタスクと同じように、指定したい要素名と同じメソッドを呼び出すことで指定できます。

Page 115 of 436

例17.3 Antタスクにネストされた要素を渡す
build.gradle
task zip << {ant.zip(destfile: 'archive.zip') {fileset(dir: 'src') {include(name: '**.xml')
exclude(name: '**.java')}}}

Antタスクにアクセスするのと同じ方法、すなわちタイプ名をメソッド名として利用することでAntタイプにアクセスでメソッド呼び出しの戻り値はAntデータ型なので、ビルドスクリプトの中で直接利用できます。
次の例では、Antのpathオブジェクトを生成し、その内容をすべてイテレートしています。
例17.4 Antタイプの利用
build.gradle
task list << {def path = ant.path {fileset(dir: 'libs', includes: '*.jar')}path.list().each {println it}}

AntBuilderに関する詳細は「GroovyinAction」の8.4節、ないしはGroovy

Wikiを参照してください。

17.1.1. ビルドでカスタムAntタスクを使う
ビルドでカスタムタスクを有効にするためには、 build.xmlファイルと同じくAntタスクのtaskdef（大抵はこちらの方が簡単です）かtypedefを利用します。
これにより組み込みのAntタスクと同様にカスタムAntタスクが参照できるようになります。
例17.5 カスタムAntタスクの利用
build.gradle
task check << {ant.taskdef(resource: 'checkstyletask.properties') {classpath {fileset(dir: 'libs', includes: '*.jar')}}
ant.checkstyle(config: 'checkstyle.xml') {fileset(dir: 'src')}}

カスタムタスクを利用するために必要なクラスパスの設定には、Gradleの依存関係管理機能が利用できます。

Page 116 of 436

このために、クラスパスに対するカスタムコンフィグレーションを定義して、コンフィグレーションに対する依存関係
詳細については「依存関係の定義方法 」に記述されています。
例17.6 カスタムAntタスクに対するクラスパスの宣言
build.gradle
configurations {pmd}
dependencies {pmd group: 'pmd', name: 'pmd', version: '4.2.5'}

クラスパスを設定するには、カスタムコンフィグレーションのasPathプロパティを利用します。
例17.7 カスタムAntタスクと依存関係管理を併用
build.gradle
task check << {ant.taskdef(name: 'pmd',
classname: 'net.sourceforge.pmd.ant.PMDTask',
classpath: configurations.pmd.asPath)
ant.pmd(shortFilenames: 'true',
failonruleviolation: 'true',
rulesetfiles: file('pmd-rules.xml').toURI().toString()) {formatter(type: 'text', toConsole: 'true')
fileset(dir: 'src')}}

17.2. Antビルドのインポート
a n t . i m p o r t B u i l d ( )メソッドを利用して、GradleプロジェクトにAntビルドをインポートできます。
Antビルドをインポートした場合、各AntターゲットはGradleのタスクとして扱われます。
つまり、AntターゲットとGradleタスクをまったく同一の方法で操作することができるということです。

Page 117 of 436

例17.8 Antビルドのインポート
build.gradle
ant.importBuild 'build.xml'

build.xml<project><target name="hello"><echo>Hello, from Ant</echo></target></project>gradle hello の出力> gradle hello:hello[ant:echo] Hello, from Ant
BUILD SUCCESSFUL
Total time: 1 secs

Antターゲットに依存するタスクを追加することもできます:
例17.9 Antターゲットに依存するタスク
build.gradle
ant.importBuild 'build.xml'
task intro(dependsOn: hello) << {println 'Hello, from Gradle'}

gradle intro の出力> gradle intro:hello[ant:echo] Hello, from Ant:introHello, from Gradle
BUILD SUCCESSFUL
Total time: 1 secs

Antターゲットにふるまいを追加することも可能です:

Page 118 of 436

例17.10 Antターゲットにふるまいを追加
build.gradle
ant.importBuild 'build.xml'
hello << {println 'Hello, from Gradle'}

gradle hello の出力> gradle hello:hello[ant:echo] Hello, from Ant
Hello, from Gradle
BUILD SUCCESSFUL
Total time: 1 secs

Gradleタスクに依存するAntターゲットを定義することも可能です:
例17.11 Ant target that depends on Gradle taskbuild.gradle
ant.importBuild 'build.xml'
task intro << {println 'Hello, from Gradle'}build.xml<project><target name="hello" depends="intro"><echo>Hello, from Ant</echo></target></project>gradle hello の出力> gradle hello:introHello, from Gradle:hello[ant:echo] Hello, from Ant
BUILD SUCCESSFUL
Total time: 1 secs

Sometimes it may be necessary to “rename” the task generated for an Ant target to avoid anaming collision with existing Gradle tasks. To do this, use the AntBuilder.importBuild()
method.

Page 119 of 436

例17.12 Renaming imported Ant targets
build.gradle
ant.importBuild('build.xml') { antTargetName ->'a-' + antTargetName}build.xml<project><target name="hello"><echo>Hello, from Ant</echo></target></project>gradle a-hello の出力> gradle a-hello:a-hello[ant:echo] Hello, from Ant
BUILD SUCCESSFUL
Total time: 1 secs

Note that while the second argument to this method should be a Transformer, when
programming in Groovy we can simply use a closure instead of an anonymous inner class (orsimilar) due to Groovy's support for automatically coercing closures to single-abstract-method
types.

17.3. Antプロパティとリファレンス
Antタスクで利用できるようにAntプロパティを設定する方法は複数あります。

AntBuilder

インスタンスのプロパティを直接設定できます。
Antプロパティは変更可能なMapとしても利用可能です。 Antのpropertyタスクも利用できます。
以下はこれらをどのように実行するのかを示すサンプルです。
例17.13 Antプロパティの設定
build.gradle
ant.buildDir = buildDir
ant.properties.buildDir = buildDir
ant.properties['buildDir'] = buildDir
ant.property(name: 'buildDir', location: buildDir)build.xml<echo>buildDir = ${buildDir}</echo>

多くのAntタスクは実行時にプロパティを設定します。
これらのプロパティを取得する方法も複数あります。
インスタンスからプロパティを直接取得できます。

AntBuilder

AntプロパティはMapとしても参照可能です。
Page 120 of 436

以下はサンプルです。
例17.14 Antプロパティの取得
build.xml<property name="antProp" value="a property defined in an Ant build"/>build.gradle
println ant.antProp
println ant.properties.antProp
println ant.properties['antProp']

Antリファレンスを設定する方法は複数あります:
例17.15 Antリファレンスの設定
build.gradle
ant.path(id: 'classpath', location: 'libs')
ant.references.classpath = ant.path(location: 'libs')
ant.references['classpath'] = ant.path(location: 'libs')

build.xml<path refid="classpath"/>

Antリファレンスを取得する方法も複数あります:
例17.16 Antリファレンスの取得
build.xml<path id="antPath" location="libs"/>build.gradle
println ant.references.antPathprintln ant.references['antPath']

17.4. API
Ant統合機能はAntBuilderによって提供されています。

[15]

Groovyでは文字列をコマンドとして実行できます。

外部プロセスの実行について詳しく学ぶには、「GroovyinAction」の9.3.2節か、Groovy

Wikiを参照してください。

Page 121 of 436

18
ロギング

ログは、ビルドツールのユーザーインターフェースとも言えるものです。あまりにくどいと本当に重要な警告や問題が
表 1 8 . 1 「 ロ グ レ ベ ル 」)を規定しています。だいたいはどこか見たことのあるログレベルだと思いますが、 QUIET と
LIFECYCLE の2つはGradle特有のものです。 LIFECYCLE
はデフォルトのログレベルで、ビルドプロセスの進行状況をレポートするために使われます。
表18.1 ログレベル
レベル

用途

ERROR

エラーメッセージ

QUIET

重要な情報メッセージWARNING

警告メッセージ

LIFECYCLE

進行状況を示す情報メッセージ

INFO

情報メッセージ

DEBUG

デバッグメッセージ

18.1. ログレベルの選択
表示させるログレベルは、コマンドラインオプション(
表18.2「ログレベルに関するコマンドラインオプション」 )で変更できます。
表18.3「スタックトレースに関するコマンドラインオプション」には、スタックトレースログをどうするか指定する方法を載せています。
表18.2 ログレベルに関するコマンドラインオプション
オプション

出力ログレベル

ロギングオプション未指定

LIFECYCLE以上-q または --quiet

QUIET以上-i または --info

INFO以上-d または --debug

DEBUG以上(要するに全部)Page 122 of 436

表18.3 スタックトレースに関するコマンドラインオプション
オプション

意味

スタックトレースオプション未指定

ビルドエラー(コンパイルエラーとか)のスタックトレースはコンソールに表示が指定されている場合、切り詰められたスタックトレースが常に表示される-s または --stacktrace

切り詰められたスタックトレースが表示される。Groovyのフルスタックトレ

コードのどこがダメなのか有用な情報がでてこない)ので、こちらの切り詰め-S または --full-stacktrace

フルスタックトレースを表示する。

18.2. ログメッセージを書く

ログメッセージを書く簡単な方法は、標準出力に書き込むことです。Gradleは、標準出力に書かれたすべてのメッセー
QUIETレベルでリダイレクトします。
例18.1 ログに標準出力を使う
build.gradle
println 'A message which is logged at QUIET level'

また、ビルドスクリプト内ではloggerプロパティも使えます。このプロパティには、Logger( S L F 4 J の L o g g e r

インターフェースにGradle特有のメソッドを少し追加したもの)のインスタンスがセットされています。使い方は以下
例18.2 自分でログメッセージを書く
build.gradle
logger.quiet('An info log message which is always logged.')logger.error('An error log message.')logger.warn('A warning log message.')logger.lifecycle('A lifecycle info log message.')logger.info('An info log message.')logger.debug('A debug log message.')logger.trace('A trace log message.')

さらに、ビルドで使っている別のクラス(たとえばbuildSrc

ディレクトリのクラス)の中から、Gradleのロギングシステムへログを出力することもできます。やり方も、ただSLF4
例18.3 SLF4Jでログを出力する
build.gradle
import org.slf4j.Logger
import org.slf4j.LoggerFactory
Logger slf4jLogger = LoggerFactory.getLogger('some-logger')
slf4jLogger.info('An info log message logged using SLF4j')

Page 123 of 436

18.3.
外部ツールやライブラリからのログについて

内部的には、GradleはAntとIvyを使っています。どちらも、自身で独自のロギングシステムを持っています。GradleはTRACEだけはGradleのDEBUGに対応)。つまり、Gradleのデフォルトログレベルだと、Ant、Ivyのメッセージはエラーやワーニングでないと出力さログに標準出力を使っているツールは、いまだにたくさんあります。デフォルトでは、Gradleは標準出力を
QUIETレベルログに、標準エラーをERROR
レベルログにリダイレクトします。また、この動作は設定で変更可能です。プロジェクトオブジェクトのL o g g i n g M a n a g e rを使えば、ビルドスクリプト実行時の標準出力、標準エラーをどのログレベルにリダイレクトするか変更できるように
例18.4 標準出力のキャプチャ設定
build.gradle
logging.captureStandardOutput LogLevel.INFO
println 'A message which is logged at INFO level'

さらに、タスク実行時のログリダイレクト設定も変更できるよう、タスクにもLoggingManager
があります。
例18.5 タスク実行時の標準出力キャプチャ設定
build.gradle
task logInfo {logging.captureStandardOutput LogLevel.INFO
doFirst {println 'A task message which is logged at INFO level'}}

Gradleは、Java標準のロギング実装や、Jakarta

CommonsのCommons

Logging、Log4jも統合しています。ビルドで使っているクラスが、これらのツールキットでログメッセージを出力すれ18.4. Gradleがロギングするものを変更する

GradleのロギングUIを、独自のものに差し替えることができます。もっと多くの情報を出したい場合、また、逆に出力G r a d l e . u s e L o g g e r ( )メソッドを使います。次の例では、初期化スクリプトを使って、タスク実行、ビルドの完了をロギングする方法を変更

Page 124 of 436

例18.6 Gradleがロギングするものを変更する
init.gradle
useLogger(new CustomEventLogger())
class CustomEventLogger extends BuildAdapter implements TaskExecutionListener {public void beforeExecute(Task task) {println "[$task.name]"}public void afterExecute(Task task, TaskState state) {println()}public void buildFinished(BuildResult result) {println 'build completed'
if (result.failure != null) {result.failure.printStackTrace()}}}

gradle -I init.gradle build の出力> gradle -I init.gradle build[compile]
compiling source[testCompile]compiling test source[test]
running unit tests[build]build completed

独自ロガーは、以下にリストしたリスナーインターフェースを実装できます。登録したロガーのインターフェースに対「ライフサイクルからの通知に応答する」をご参照ください。
BuildListener
ProjectEvaluationListener
TaskExecutionGraphListener
TaskExecutionListener
TaskActionListener

Page 125 of 436

19
Gradleデーモン
19.1. デーモン入門
Gradleデーモン(ビルドデーモンと呼ばれることもあります)はGradleの起動と実行の速度を改善します。
デーモン実行が非常に有用だと思われるユースケースをいくつか考えてみました。
例えば、少数の、比較的実行が早く終わるようなタスクを、何度も実行しなければならないような場面があります。
テスト駆動開発にて、ユニットテストを度々実行するような場合
Webアプリケーション開発にて、アプリケーションを何度も構築する場合
ビルドの挙動を調べるために、gradle tasksを何度も実行する場合
これらの場合、Gradleを起動・実行するための時間は出来る限り短いことが重要でしょう。

さらに、Gradleモデルがより素早く構築されるようになれば、ユーザーインターフェースが面白い機能を実装できる可
例えば、次のようなケースでデーモンが役に立つかもしれません。
統合開発環境で入力補完する場合
GUIでビルド状況を表示する場合
コマンドラインインターフェースでのタブ補完する場合
一般的にいって、ビルドツールが軽快に動作して困るということはありません。

ローカル環境のビルドでデーモンを試してみてください。デーモンを使わない普通のビルドにはもう戻れなくなるでし
ツールAPI(参照

Chapter63,

Embedding

Gradle)は常にデーモンを使用します。つまり、通常、デーモンなしでツールAPIは使えません。
したがって、EclipseのSTS

GradleプラグインやIntelliJ

IDEAのGradleサポートを使っているときは、常にデーモンが背後で起動しています。
今後は下記の機能が追加される予定です。
軽快な更新チェック: ファイルシステムネイティブの変更通知を(jdk7
nio.2経由などで)使い、プロジェクトが更新されたかどうか前もって解析する
更なるビルドの高速化:
あらかじめプロジェクトを評価し、次回のGradle実行時にプロジェクトモデルを準備しておく

更なるビルドの高速化、はもう言いましたっけ、とにかく、デーモンは潜在的にはあらかじめ依存関係をダウンロ
再利用可能なプロセスのプールを活用して、コンパイル、テストを実施する。
例えばGroovyとScalaコンパイラーの起動にはどちらも多大なコストがかかります。
しかし、ビルドデーモンは、GroovyやScalaが既にロードされたプロセスを維持しておくことができます。
コンパイルなど、ある種のタスクは事前に実行しておく。より早いフィードバックが可能になります。

Page 126 of 436

速くて正確なbash上のタブ補完
Gradleキャッシュを定期的にガーベージコレクトする

19.2. デーモンの再利用と期限切れ

デーモン実行の基本にある考え方は、gradleコマンドがデーモンプロセスを起動して、そのデーモンが実際のビルドをそうすれば、後続のgradleコマンドがそのデーモンプロセスを再利用でき、起動に掛かるコストを抑えることができま

しかし、既存のデーモンプロセスが使用できないこともあります。例えば、プロセスがビジーだったり、要求されたJ
新しいデーモンプロセスが、正確にはいつ起動されるかの詳細については、以下を参照してください。
デーモンプロセスは、アイドル状態で3時間経過すると自動的に期限切れになります。
デーモンプロセスが新しく起動される場面を全て列挙すると、既存のデーモンがある処理を実行中の場合、新たなデーモンが起動されます。
デーモンプロセスは、java
homeごとに起動されます。アイドル状態のデーモンがビルドリクエストを待機していたとしても、別のjava
homeからビルドを実行した場合デーモンプロセスが新しく起動されます。

ビルドのJVM引数が大きく異なる場合、デーモンプロセスが新しく起動されます。いくつかのシステムプロパティ
起動されているデーモンは、特定のバージョンのGradleと関連づいています。

そのため、アイドル状態のデーモンが存在したとしても、それと別のバージョンのGradleでビルドを実行すると新
これは、--stopコマンドについてあることを教唆しています――つまり、--stopで停止できるデーモンは、その--stopを実行しているGradleと同じバージョンのGradleで起動されたデーモンだけだということです。
今後、デーモンの管理方法、プール方法の改善を行う予定です。

19.3. 使い方とトラブルシューティング
コマンドラインの利用方法については別節付録D

Gradleコマンドラインを参照してください。

同じコマンドラインを何度も何度も指定してうんざりしている場合は、「gradle.propertiesを使用したビルド環境の構築」 を参照してください。

上記の節には、デーモンの振る舞いをより「永続的に」設定する方法が(デフォルトでデーモンを起動する方法を含めデーモンのトラブルシューティングについていくつか方法を示します。
ビルドで問題が発生した場合、一時的にデーモンを無効化してみてください(コマンドラインにスイッチ--no-daemonを渡す)。
--stopオプションや、もっと強制的な方法でデーモンを停止しなければならない場面もあります。
デーモンのログファイルは、デフォルトではGradleユーザーホームディレクトリーにあります。
ビルドの実行状況を見るには、--feoregroundを使ってデーモンを起動します。

Page 127 of 436

19.4. デーモンの設定
デーモン設定のうち、JVM引数、メモリーの設定、Java
homeなどは設定ファイルなどで変更できます。詳細については「gradle.propertiesを使用したビルド環境の構築」を参照してください。

Page 128 of 436

20
ビルド環境
20.1.
gradle.propertiesを使用したビルド環境の構築
Gradleでは、ビルドを実行するJavaプロセスの設定を簡単に変更するための方法が複数用意されています。

ローカルの環境変数でGRADLE_OPTSやJAVA_OPTSを使って設定することもできますが、一部の設定値、JVMメモリ

home、デーモンのオンオフなどについてはプロジェクトのVCSに格納してバージョン管理しておけば、チームメンバ
こうした一貫した設定値は、gradle.propertiesに設定値を保存するだけで実現可能です。
設定値は以下の順序で適用されます（複数箇所で設定されている場合は最後の一つが優先されます）。
プロジェクトのビルドディレクトリに置かれたgradle.properties
gradleに置かれたgradle.properties-Dsome.propertyなどで指定されたシステムプロパティ
以下のプロパティがGradleのビルド環境を設定するために使用されます。
org.gradle.daemon
trueに設定するとデーモンによりビルドが実行されます。

開発者がローカルでビルドを実行する際は、このプロパティを設定することをおすすめします。開発環境ではスピ

一方、CI環境では並行性、信頼性といった点を重視したいため、CIビルド（というか実行時間の長い処理）でデー
org.gradle.java.home
Gradleのビルドシステムで使用するJava

homeを指定します。

設定するのは jdkでもjre構いませんが、プロジェクトによってはjdkを指定した方が安全かもしれません。
指定しなければ、適当なデフォルト値が設定されます。
org.gradle.jvmargs
デーモンプロセスに渡すJVM引数を指定します。
この設定はメモリ設定を調節するのに特に便利です。
デフォルト値はメモリに応じて適切に設定されます。
org.gradle.configureondemand
Gradleがプロジェクトを選択的に設定する試験的なモードを有効にします。

関係のあるプロジェクトのみを評価することで、巨大なマルチプロジェクト・ビルドをより高速にビルドできるよ
詳しくは「Configuration on demand」を参照してください。
org.gradle.parallel
この設定を行うと、Gradleの試験的な並列ビルドモードが有効化されます。

Page 129 of 436

20.1.1. Javaプロセスのフォーク

JVMに関する設定の多く(Javaバージョンや最大ヒープサイズなど)は、新しくJVMプロセスを起動するときのみ設定で
これはつまり、Gradleが解析した多様なgradle.properties
に従ってビルドを実行するには、JVMプロセスを新しく起動しなければならないということを意味します。

デーモンを実行しているときは、適切なパラメーターが設定されたJVMが起動され、デーモンごとに再利用されます。

デーモンを使用せずにビルドを実行したときは、Gradleのスタートスクリプトが起動したJVMとたまたま同じパラメー
ビルドを実行する度にJVMを余分に起動しなければならないというのは、とても大きなコストになります。なので、org.gradle.java.homeやorg.gradle.jvmargsを設定しているのであればGradleデーモンを使ってビルドすることを強く推奨します。詳細については19章Gradleデーモン を参照してください。

20.2. プロクシ経由のWebアクセス(例えば依存関係のダウンロードするための)HTTPプロクシの設定は標準的なJVMのシステムプロパティを使って行います。これらの設定は、直接ビルドスクリプト上で設定することが可
例えばプロクシのホストの為に System.setProperty('http.proxyHost', 'www.somehost.org')と設定できます。

あるいは、ビルドのルートディレクトリ上又はGradleホームディレクトリ上にある gradle.propertiesファイルにそれらの値を設定できます。
例20.1 HTTPプロクシの設定
gradle.properties
systemProp.http.proxyHost=www.somehost.org
systemProp.http.proxyPort=8080
systemProp.http.proxyUser=userid
systemProp.http.proxyPassword=password
systemProp.http.nonProxyHosts=*.nonproxyrepos.com|localhost

HTTPS設定の分離
例20.2 HTTPSプロクシの設定
gradle.properties
systemProp.https.proxyHost=www.somehost.org
systemProp.https.proxyPort=8080
systemProp.https.proxyUser=userid
systemProp.https.proxyPassword=password
systemProp.https.nonProxyHosts=*.nonproxyrepos.com|localhost

使用可能な全てのプロクシ設定を概観できる良い資料については残念ながら発見することができませんでした。一つのSubversionへのリンク
ネットワーク設定値のページを載せておきます。他には、JDKドキュメントにがありました。

その他、もっと良い資料をご存知であれば、メーリングリストでお知らせください。

Page 130 of 436

20.2.1. NTLM認証

NTLM認証が必要なプロクシを使う場合、ユーザ名とパスワードだけでなく認証ドメインを設定する必要があります。
システムプロパティhttp.proxyUserに、 domain / username のように値を設定する。
システムプロパティhttp.auth.ntlm.domainに認証ドメインを設定する。

Page 131 of 436

21
Gradleのプラグインについて
Gradleのコア部分には、実際の自動化に役に立つような機能は含まれていません。
これは意図的なもので、Javaのコードをコンパイルしたりといった便利な機能は、全てプラグインに よ り 追 加 さ れ ま す 。
プラグインは、コア部分のオブジェクトや他のプラグインのオブジェクトを拡張するだけでなく、新しいタスク(
JavaCompileなど)やドメインオブジェクト(SourceSetなど)、規約(Javaのコードはsrc/main/javaに置く)、などをGradleに追加します。
この章では、プラグインを使う方法、プラグインまわりの用語や概念について議論します。

21.1. Types of plugins
There are two general types of plugins in Gradle, script plugins and binary plugins. Script
plugins are additional build scripts that further configure the build and usually implement a
declarative approach to manipulating the build. They are typically used within a build although
they can be externalized and accessed from a remote location. Binary plugins are classes that
implement the Plugin interface and adopt a programmatic approach to manipulating the build.
Binary plugins can reside within a build script, within the project hierarchy or externally in aplugin jar.

21.2. プラグインの適用
プラグインの、いわゆる 適用 は、Project.apply()メソッドで行います。
例21.1 プラグインの適用
build.gradle
apply plugin: 'java'

21.2.1. Script plugins
例21.2 Applying a script pluginbuild.gradle
apply from: 'other.gradle'

Page 132 of 436

Script plugins can be applied from a script on the local filesystem or at a remote location.
Filesystem locations are relative to the project directory, while remote script locations are
specified with an HTTP URL. Multiple script plugins (of either form) can be applied to a given
build.

21.2.2. Binary plugins
例21.3 Applying a binary pluginbuild.gradle
apply plugin: 'java'Core plugins register a short name. In the above case, we are using the short name ‘ java’ toapply the JavaPlugin. Plugins also have a plugin id that takes a fully qualified form like com.github.foo.bar, although some legacy plugins may still utilize the short, unqualified form.
This method can also accept a class to identify the plugin:
例21.4 Applying a binary plugin by typebuild.gradle
apply plugin: JavaPlugin

The JavaPlugin symbol in the above sample refers to the the JavaPlugin. This class does notstrictly need to be import as the org.gradle.api.plugins package is automatically imported
in all build scripts (see 付録E IDE対応の現状と、IDEによらない開発支援). Furthermore, it is notnecessary to append .class to identify a class literal in Groovy as it is in Java.
The application of plugins is idempotent . That is, a plugin can be applied multiple times. If theplugin has previously been applied, any further applications will have no effect.

21.2.2.1. Locations of binary plugins
A plugin is simply any class that implements the Plugin interface. Gradle provides the coreplugins as part of its distribution so simply applying the plugin as above is all you need to do.
However, non-core binary plugins need to be available to the build classpath before they can beapplied. This can be achieved in a number of ways, including:Defining the plugin as an inline class declaration inside a build script.
Defining the plugin as a source file under the buildSrc directory in the project.
Including the plugin from an external jar defined as a buildscript dependency (see「ビルドスクリプトで外部ライブラリを使うときの依存関係設定」).
Including the plugin from the plugin portal using the plugins DSL (see 「Applying plugins withthe plugins DSL」).
For more on defining your own plugins, see 59章カスタムプラグインの作成.

Page 133 of 436

21.3. Applying plugins with the plugins DSL
The plugins DSL is currently incubating. Please be aware that the DSL and otherconfiguration may change in later Gradle versions.

The new plugins DSL provides a more succinct and convenient way to declare plugin
dependencies. It works with the new Gradle plugin portal to provide easy access to both coreandcommunity

plugins.

The

plugins

scriptblock

configuresaninstanceof

PluginDependenciesSpec.
プラグインは、自分自身を示す短縮名を保持、公開しています。 上の例では、短縮名'java'を使ってJavaPluginを適用しています。
以下は短縮名を使わなかった場合の例です。
例21.5 型でプラグインを適用する
build.gradle
apply plugin: JavaPlugin

例21.6 Applying a community pluginbuild.gradleplugins {id "com.jfrog.bintray" version "0.4.1"}

No further configuration is necessary. Specifically, there is no need to configure the buildscript
classpath. Gradle will resolve the plugin in the plugin portal, locate it, and make it available tothe build.
See PluginDependenciesSpec for more information on using the Plugin DSL.

21.4. Finding community plugins
Gradle has a vibrant community of plugin developers who contribute plugins for a wide variety ofcapabilities. The Gradle plugin portal provides an interface for searching and exploring
community plugins.
また、プラグインの作り方は59章カスタムプラグインの作成に詳しく記載されています。

Page 134 of 436

21.5. プラグインがすること
プラグインを適用することで、そのプロジェクトの機能を拡張することができます。例えば、プロジェクトにタスクを追加する(compileやtestなど)。
タスクに、便利なデフォルト値を事前に設定しておく。
依存関係のコンフィギュレーションをプロジェクトに追加する(「依存関係のコンフィグレーション 」参照)。
既存の型に新しいプロパティやメソッドを追加する。
次の例を見てください。
例21.7 プラグインにより追加されたタスク
build.gradle
apply plugin: 'java'
task show << {println relativePath(compileJava.destinationDir)
println relativePath(processResources.destinationDir)}

gradle -q show の出力> gradle -q showbuild/classes/mainbuild/resources/main

Javaプラグインは、 compileJava タスクと processResource
タスクをプロジェクトに追加し、それぞれのタスクにdestinationDir
プロパティを設定しています。

21.6. 規約

プラグインは、CoC(設定より規約)をというスマートな方法をサポートするため、プロジェクトを事前に設定しておく

Gradleにはこのメカニズムと洗練されたサポートがあり、パワフルかつ簡潔なビルドスクリプトを記述するためのカギ
先ほどの例、JavaプラグインがcompileJavaタスクを追加し、そこにdestinationDir
プロパティ(コンパイルしたソースが出力される場所)を追加したコードを思い出してください。
Javaプラグインは、デフォルトでこのプロパティが、プロジェクトディレクトリのbuild/classes/mainを指すよう設定します。これは、合理的なデフォルト値を設定するCoCの一例です。
このプロパティは、新しい値を設定するだけで簡単に変更できます。

Page 135 of 436

例21.8 プラグインのデフォルトを変更する
build.gradle
apply plugin: 'java'
compileJava.destinationDir = file("$buildDir/output/classes")task show << {println relativePath(compileJava.destinationDir)}

gradle -q show の出力> gradle -q showbuild/output/classes

ただ、クラスファイルの出力場所が関係するタスクは、おそらくcompileJava
タスクだけではないでしょう。
Javaプラグインは、プロジェクトに ソースセット という概念を追加します(SourceSet参照)。

ソースセットは、ソースコード一式を示す概念であり、それらがコンパイルされた際にクラスファイルが書き出される
Javaプラグインは、 compileJava タスクの destinationDir
プロパティを、ソースセットが示す出力場所にマップしているのです。
クラスファイルの書き出される場所を、ソースセットで変更することができます。
例21.9 プラグインの規約オブジェクト
build.gradle
apply plugin: 'java'
sourceSets.main.output.classesDir = file("$buildDir/output/classes")task show << {println relativePath(compileJava.destinationDir)}

gradle -q show の出力> gradle -q showbuild/output/classes

この例で、Javaプラグインは以下のようなことを含む様々な処理を行っています。
新しいドメインオブジェクト、SourceSetを追加。
mainソースセットに、デフォルト値(つまり規約)を設定。
タスクがこれらのプロパティを使って動作するように設定。
この全てが、apply

plugin:"java"のステップで行われています。例では、規定の設定が行われた後、クラスファイルの場所を変更しました。

compileJava.destinationDirの値が、設定の変更を反映して変わっていることに注目してください。

Page 136 of 436

別のタスクが、クラスファイルを使用するケースを考えてください。そのタスクが、クラスファイルの場所を
sourceSets.main.output.classesDirを参照して取得するようになっていれば、ソースセットを変更するだけでcompileJavaとそのタスク、両方の設定が更新されます。

他のタスクの設定値をいつでも(つまり、変更されたときでさえ)反映するよう、オブジェクトのプロパティを設定でき
規約マッピングとして知られています。

この方法により、GradleはCoCと合理的なデフォルト値による簡潔さを達成しています。また、規定のデフォルト値をもしこの方法を採用していなければ、クラスファイルの設定をするのに全てのオブジェクトを変更してまわらなければ

21.7. プラグインをさらに詳しく知るには
この章は、プラグインと、プラグインがGradleで果たしている役割について簡単に紹介するためのものです。
プラグインの内部動作について、さらに詳しく知るには、59章カスタムプラグインの作成を参照してください。

Page 137 of 436

22
標準Gradleプラグイン
Gradleの配布物にはいくつかのプラグインが同梱されています。以下にその一覧を掲載します。

22.1. 言語プラグイン

これらのプラグインは、Gradleに様々な言語サポートを追加します。JVMに向けたコンパイルやJVM上でのプログラム
表22.1 言語プラグイン
プラグインID

自動適用

協調して動作説明javajava-base-

Javaのコンパイル、テスト、バンドル機能をプロジェクトに追加
7章Javaクイックスタートも参照してください。

groovyjava, groovy-base-

Groovyプロジェクトのビルド機能を追加します。9章Groovyク

scalajava, scala-base-Scalaプロジェクトのビルド機能を追加します。

antlr

java

-

Antlrを使ったパーサーの生成をサポートします。

22.2. 試験的な言語プラグイン
これらのプラグインは、以下のような様々な言語のサポートを追加します。

Page 138 of 436

表22.2 言語プラグイン
プラグインID

自動適用

協調して動作説明

assembler

-

-

Adds

nativeassembly

languagecapabilities to a project.
-c-

Adds C source compilation capabilities
to a project.

-

cpp

-

Adds

C++

sourcecompilation

capabilities to a project.
-

objective-c-

Adds Objective-C source compilation
capabilities to a project.

-

objective-cpp

-

Adds

Objective-C++

sourcecompilation capabilities to a project.

windows-resources--

Adds support for including Windows
resources in native binaries.

22.3. 統合プラグイン
これらのプラグインは、様々なランタイムをプロジェクトに統合して使用できるようにします。
表22.3 統合プラグイン
プラグインID

自動適用

協調して動作説明

application

java

-

プロジェクトをコマンドラインアプリケーションとしてビルド、

ear

-

java

J2EEアプリケーションのビルド機能を追加します。

jetty

war

-

組み込みのJettyウェブコンテナに、アプリケーションをデプロ
Webアプリケーションクイックスタートも参照してください。

maven

-

java, war

Mavenリポジトリにアーティファクトを公開できるようにしますosgi

java-basejava

OSGiバンドルのビルドをサポートします。

war

java

-

ウェブアプリケーションのWARファイルをビルドできるように
Webアプリケーションクイックスタートも参照してください。

Page 139 of 436

22.4. 試験的な統合プラグイン
これらのプラグインは、様々なランタイムをプロジェクトに統合して使用できるようにします。
表22.4 試験的な統合プラグイン
プラグインID

自動適用

協調して動作説明

distribution--

ZIPおよびTARの配布物をビルドできるよう

java-library-distribution

java, distribution-

JavaライブラリをZIPおよびTARの配布物とivy-publish-

java, war

Ivyリポジトリへアーティファクトを公開でmaven-publish-

java, war

Mavenリポジトリへアーティファクトを公22.5. ソフトウェア開発プラグイン
これらのプラグインは、ソフトウェアの開発プロセスを支援します。

Page 140 of 436

表22.5 ソフトウェア開発プラグイン
プラグインID

自動適用

協調して動作説明

announce--

TwitterやGrowlなど、任意のプラットフォーム

build-announcements

announce-

ビルドライフサイクルの各種イベントのうち、

checkstylejava-base-

Checkstyleを使ってJavaソースコードの品質を

codenarcgroovy-base-

CodeNarcを使ってGroovyソースコードの品質

eclipse-java,groovy

Eclipse, scalaJavaクイックスタートも参照してください。

ear, war

eclipseプラグインが生成するファイルに加eclipse-wtp-

IDEが使用するファイルを生成し、Platform)の設定ファイルも生成し

eclipseにインポートすれば、war/earプロジェ
Javaクイックスタートも参照してください。

findbugs

java-base-

FindBugsを使ってプロジェクトに含まれるJava

idea

-

java

Intellij IDEA IDEが使用するファイルを生成し、jdependjava-base-

JDependを使ってソースコードの品質をチェッ

pmd

java-base-

PMDを使ってJavaソースコードの品質をチェッ

project-reportreporting-base-Gradleビルドに関する有用な情報が載ったレポ

signingbase-

ビルドしたファイルとアーティファクトにデジ

sonar

-

java-base,

Sonarコード品質プラットフォームとの連携機

java, jacoco

プラグインが作成されています。

22.6. 試験的なソフトウェア開発プラグイン
これらのプラグインは、ソフトウェアの開発プロセスを支援します。

Page 141 of 436

表22.6 ソフトウェア開発プラグイン
プラグインID

自動適用

協調して動作説明

build-dashboard

reporting-base-

Generates build dashboard report.

build-initwrapper-

Adds support for initializing a new Gradle

Handles converting a Maven build to a Gradle bui

cunit

-

-

Adds support for running CUnit tests.

jacocoreporting-basejava

Provides integration with the JaCoCo code cov
library for Java.

sonar-runner-java-base,

S

o

n

a

r

java, jacoco

コード品質プラットフォームとの連携機能を提供しプラグインの後継プラグインです。

visual-studio-nativeAdds integration with Visual Studio.

languageplugins
wrapper--

Adds a Wrapper task for generating Gradle wr
files.

java-gradle-plugin

java

Assists with development of Gradle pluginproviding standard plugin build configuration
validation.

22.7. ベースプラグイン

これらのプラグインは、他のプラグインを組み立てるための基本的なビルド用の部品を構成します。また、ビルドスク

しかし、これらのプラグインはまだGradleの正式な公開APIとはなっていないことに注意してください。そのため、ユPage 142 of 436

表22.7 ベースプラグイン
プラグインID

説明

base

一般的なライフサイクルを構成するタスクを追加し、アーカイブタスクにリーズナブルなデフォ
buildConfigurationName

タスクを追加します。これらのタスクは、特定のコンフィグレーションに属するアーティファ
uploadConfigurationName

タスクを追加します。これらのタスクは、特定のコンフィグレーション属するアーティファク全てのアーカイブタスク（AbstractArchiveTaskを継承したタスク）に適切なデフォルト値

タイプやTarタイプ、Zipタイプのタスクがアーカイブタスクです。 これらのタスクに、desプロパティを前もって設定します。

これにより、アーカイブの命名規約やビルド後の配置場所に一貫性が生まれるため、とても便
java-base

プロジェクトにソースセットの概念を導入します。実際のソースセットは追加されません。

groovy-base

プロジェクトにGroovyソースセットの概念を導入します。

scala-base

プロジェクトにScalaソースセットの概念を導入します。

reporting-base

レポート生成に関するいくつかの一般的な規約プロパティをプロジェクトに追加します。

22.8. サードパーティプラグイン
サードパーティ製のプラグインはGradleプラグインポータルで見つけることができます。

Page 143 of 436

23
Javaプラグイン

Javaプラグインは、プロジェクトにJavaのコンパイル、テスト、そしてビルド能力を与えます。このプラグインは、他

23.1. 使用方法
Javaプラグインを使うためには、ビルドスクリプトに下記を含めます：
例23.1 Javaプラグインの使用
build.gradle
apply plugin: 'java'

23.2. ソースセット
J a v a プ ラ グ イ ン は ソ ー ス セ ッ トの概念を導入します。ソースセットは、一緒にコンパイルされ実行されるソースファイルのグループです。このソース

ソースセットを使うと、ソースファイルを論理的なグループに分割し、それぞれ別個の目的を持たせることもできます
Javaプラグインは、 main とtest という二つの標準ソースセットを定義します。 main
ソースセットは、コンパイルされJARファイルを構成する製品ソースコードを含みます。test
ソースセットは、コンパイルされJUnitやTestNGで実行されるユニットテストコードを含みます。

23.3. タスク
Javaプラグインは、以下に示すような数多くのタスクをプロジェクトに追加します。

Page 144 of 436

表23.1 Javaプラグイン - タスク
タスク名

依存先

compileJava

コンパイル時クラスパスを作り出すすべてのタスク。 compile
コンフィギュレーションに含まれる、
プロジェクトの依存関係のためのjarタスクを含む

processResources-classescompileJava と processResources。
一部のプラグインはさらにコンパイルタスクを追加する

compileTestJava

compile、そしてテストのコンパイル時クラスパスを作り出すすべてのタスク

processTestResources-

testClasses

compileTestJava と processTestResources。一部のプラグインはさらにテストコンパイルタスクを追加する

jar

compilejavadoccompiletest

compile と compileTest、そしてテストの実行時クラスパスを作り出すすべてのタスク

uploadArchives

archives
コンフィギュレーションのアーティファクトを生成するタスク （ jar
を含む）

clean

-

cleanTaskName-

Javaプラグインは、プロジェクトに追加されるソースセットの各々について以下のコンパイルタスクを追加します：
表23.2 Javaプラグイン - ソースセットタスク
タスク名

依存先

型

compileSourceSet
このソースセットのコンパイル時クラスパスを作り出すすべてのタスク
Java

JavaCompile

processSourceSet
Resources

Copy

sourceSetClasses
compileSourceSetJava と processSourceSetResources

Task。一部のプラグインはさらにこのソースセットのコンパイルタスクを追加する

Javaプラグインは、プロジェクトのライフサイクルを構成する数多くのタスクも追加します：

Page 145 of 436

表23.3 Javaプラグイン - ライフサイクルタスク
タスク名

依存先

assemble

jarを含む、プロジェクトのすべてのアーカイブタスク。
一部のプラグインはプロジェクトにさらにアーカイブタスクを追加する

check

testを含む、プロジェクトのすべての検証タスク。
一部のプラグインはプロジェクトにさらに検証タスクを追加する

buildcheck と assemble

buildNeededbuild と、testRuntimeコンフィギュレーションのプロジェクトライブラリ依存先すべて
タスク

buildDependents

build と、testRuntime

コンフィギュレーションのプロジェクトライブラリ依存先がこのプロジェクトであるすべてbuildDependentsタスク
buildConfigName

ConfigNameコンフィギュレーションのアーティファクトを作り出すタスク

uploadConfigName

ConfigNameコンフィギュレーションのアーティファクトをアップロードするタスク

下の図は、上記のタスク間の関係を示しています。
図23.1 Javaプラグイン - タスク

23.4. プロジェクトレイアウト

Javaプラグインは、以下のようなプロジェクトレイアウトを仮定しています。これらのディレクトリは、存在しなかっPage 146 of 436

表23.4 Javaプラグイン - デフォルトプロジェクトレイアウト
ディレクトリ意味

src/main/java

製品のJavaソース

src/main/resources

製品のリソース

src/test/java

テストのJavaソース

src/test/resources

テストのリソース

src/sourceSet/java

特定のソースセットのJavaソース

src/sourceSet/resources

特定のソースセットのリソース

23.4.1. プロジェクトレイアウトの変更

プロジェクトのレイアウトは、適切なソースセットを設定することでカスタマイズできます。これについては後続の節
例23.2 Javaソースレイアウトのカスタマイズ
build.gradle
sourceSets {main {
java {
srcDir 'src/java'}
resources {srcDir 'src/resources'}}}

23.5. 依存関係の管理
Javaプラグインは、以下のような多くの依存関係のコンフィギュレーションをプロジェクトに追加します。
これらのコンフィギュレーションはcompileJavaやtestといったタスクに割り当てられます。
表23.5 Javaプラグイン - 依存関係のコンフィギュレーション
名前

拡張元

利用するタスク意味

compile-compileJava

コンパイル時の依存関係

runtimecompile-

実行時の依存関係

testCompile

compilecompileTestJava

テストのコンパイル時の追加依存関係

testRuntime

runtime,test

テストの実行時の追加依存関係

testCompile
archives-

uploadArchives

このプロジェクトが生成するアーティファクト(jarファイルなど

default

runtime-

このプロジェクトに依存するプロジェクトが使用する、デフォ

Page 147 of 436

図23.2 Javaプラグイン - 依存関係のコンフィギュレーション

プロジェクトに追加されたそれぞれのソースセットに対し、Javaプラグインは次の依存関係コンフィグレーションを追表23.6 Javaプラグイン - ソースセットの依存関係コンフィグレーション
名前

拡張元

sourceSetCompile

利用するタスク意味

compile

対象ソースセットのコンパイル時依存関係

SourceSetJava
sourceSetRuntime
sourceSetCompile

対象ソースセットの実行時依存関係

23.6. 規約プロパティ
Javaプラグインは、以下のような多くの規約プロパティをプロジェクトに追加します。

これらは、ビルドスクリプトの中で、あたかもprojectオブジェクトのプロパティであるかのように使うことができま(「規約 」参照)。

Page 148 of 436

表23.7 Javaプラグイン - ディレクトリプロパティ
プロパティ名型

デフォルト値

説明

reportsDirName

Stringreports

レポートを生成するディレクトリ名

reportsDir

FilebuildDir/reportsDirName

レポートを生成するディレクトリ

テスト結果の.xmlファイルを生成す(read-only)
testResultsDirName

Stringtest-results

testResultsDir

FilebuildDir/testResultsDirName
テスト結果の.xmlファイルを生成す(read-only)

テストレポートを生成するディレク

testReportDirName

Stringtests

testReportDir

FilereportsDir/testReportDirName
テストレポートを生成するディレク(read-only)
libsDirName

Stringlibs

ライブラリを生成するディレクトリ

libsDir

FilebuildDir/libsDirName

ライブラリを生成するディレクトリ

(read-only)
distsDirName

String

distributions

ディストリビューションを生成する

distsDir

FilebuildDir/distsDirName

ディストリビューションを生成する(read-only)
docsDirName

Stringdocs

ドキュメントを生成するディレクト

docsDir

FilebuildDir/docsDirName

ドキュメントを生成するディレクト

ソースの依存関係情報をキャッシュ(read-only)
dependencyCacheDirName

Stringdependency-cachedependencyCacheDir

FilebuildDir/dependencyCacheDirName
ソースの依存関係情報をキャッシュ(read-only)

表23.8 Javaプラグイン - その他のプロパティ
プロパティ名型

デフォルト値

sourceSets

SourceSetContainer (read-only)

非null

sourceCompatibility

JavaVersion。

Value of the current

StringやNumberで設定することも可能。例：

used JVM'1.5' や 1.5
targetCompatibility

JavaVersion。

sourceCompatibility

StringやNumberで設定することも可能。例：'1.5' や 1.5
archivesBaseName

StringprojectName

manifest

Manifest

空のマニフェスト

これらのプロパティは、 JavaPluginConvention 、

BasePluginConvention

Page 149 of 436

などの型の規約オブジェクトによって提供されます。

23.7. ソースセットの利用
例23.3 ソースセットへのアクセス
build.gradle// Various ways to access the main source set
println sourceSets.main.output.classesDirprintln sourceSets['main'].output.classesDirsourceSets {println main.output.classesDir}sourceSets {main {
println output.classesDir}}// Iterate over the source setssourceSets.all {println name}

既存のソースセットを設定するには、上記のアクセスメソッドの一つを使って、そのソースセットのプロパティを設定
プロパティについては後述します。以下に、mainのJavaソースとリソースディレクトリを設定する例を示します：
例23.4 ソースセットのソースディレクトリの設定
build.gradle
sourceSets {main {
java {
srcDir 'src/java'}
resources {srcDir 'src/resources'}}}

23.7.1. ソースセットプロパティ
以下の表は、ソースセットの重要なプロパティの一覧です。

さらに詳しくは、SourceSetのAPIドキュメントをご覧ください。

Page 150 of 436

表23.9 Javaプラグイン - ソースセットプロパティ
プロパティ名型

デフォルト値

説明

name

String (read-only)

非null

このソースセットを識別

outputSourceSetOutput (read-only)

Not null

このソースセットに対す

output.classesDir

FilebuildDir/classes/name
このソースセットのクラ

output.resourcesDir

FilebuildDir/resources/name
このソースセットのリソ

compileClasspath

FileCollection

compileSourceSet

このソースセットのソーコンフィグレーション
runtimeClasspath

FileCollection

output + runtimeSourceSet
このソースセットのクラコンフィグレーション

java

SourceDirectorySet

非null

このソースセットのJav(read-only)
java.srcDirs

Set<File>。 設定にはファイルのみを含み、そ[projectDir/src/nameこのソースセットのJav/java]「入力ファイルセットを指定する」
で述べる方法ならどれでも使用可
resources

SourceDirectorySet

非null

このソースセットのリソ(read-only)
resources.srcDirs

Set<File>。 設定にはGroovyプラグインのよ[projectDir/src/nameこのソースセットのリソ/resources]「入力ファイルセットを指定する」
で述べる方法ならどれでも使用可
allJava

SourceDirectorySet

このソースセットのすべ

java(read-only)
allSource

SourceDirectorySet

Groovyプラグインのよresources + java

(read-only)

このソースセットのすべ

Groovyプラグインのよ23.7.2. 新しいソースセットの定義
新しいソースセットは、sourceSets{}ブロックの中でそれを参照するだけで定義できます。以下がその例です。:
例23.5 ソースセットの定義
build.gradle
sourceSets {intTest}

ソースセットを定義すると、Javaプラグインは、そのソースセットのために表23.6「Javaプラグイン-

ソースセットの依存関係コンフィグレーション」
Page 151 of 436

で示した依存関係のコンフィグレーションを追加します。これらのコンフィグレーションを、そのソースセットのコン
例23.6 ソースセットの依存関係定義
build.gradle
sourceSets {intTest}dependencies {intTestCompile 'junit:junit:4.11'
intTestRuntime 'org.ow2.asm:asm-all:4.0'}

また、Javaプラグインは、表23.2「Javaプラグイン-

ソースセットタスク」に示したような、

そのソースセットのクラスを構築するためのタスクを追加します。
例えば、intTestというソースセットを追加すると、gradle

intTestClassesと実行することでそのソースセットのクラスをコンパイルできるようになります。
例23.7 ソースセットのコンパイル
gradle intTestClasses の出力> gradle intTestClasses:compileIntTestJava:processIntTestResources:intTestClasses
BUILD SUCCESSFUL
Total time: 1 secs

23.7.3. ソースセットの実例
ソースセットのクラスを含んだJARを追加します：
例23.8 ソースセットのJARを生成
build.gradle
task intTestJar(type: Jar) {from sourceSets.intTest.output}

ソースセットのJavadocを生成します：
例23.9 ソースセットのJavadocを生成
build.gradle
task intTestJavadoc(type: Javadoc) {source sourceSets.intTest.allJava}

Page 152 of 436

ソースセットに含まれるテストを実行するテストスイートを追加します：
例23.10 ソースセットのテストを実行
build.gradle
task intTest(type: Test) {testClassesDir = sourceSets.intTest.output.classesDirclasspath = sourceSets.intTest.runtimeClasspath}

23.8. Javadoc
javadocタスクはJavadocのインスタンスです。 javadocの主なオプションと、javadocコマンドのリファレンスガイド に記載されている標準docletのオプションをサポートしています。

サポートしているjavadocオプションの完全なリストについては、次のクラスのAPIドキュメントを参照してください:
CoreJavadocOptionsおよびStandardJavadocDocletOptions。
表23.10 Javaプラグイン - Javadocプロパティ
プロパティ名型

デフォルト値

classpath

FileCollection

sourceSets.main.output + sourceSets.main.co

sourceFileTree。 設定には

sourceSets.main.allJava「入力ファイルセットを指定する」
で述べる方法ならどれでも使用可
destinationDir

FiledocsDir/javadoc

title

String

プロジェクトの名前とバージョン

23.9. Clean
cleanタスクはDeleteのインスタンスです。

dir

プロパティで示されるディレクトリを削除します。
表23.11 Javaプラグイン - Cleanプロパティ
タスクプロパティ型

デフォルト値

dir

File

buildDir

23.10. リソース
Javaプラグインは、リソースの処理にCopyタスクを使います。
プロジェクトの各ソースセットに対して一つのインスタンスを追加します。
copyタスクの詳細については、「ファイルをコピーする 」をご覧ください。

Page 153 of 436

表23.12 Javaプラグイン- processResourcesプロパティ
タスクプロパティ型

デフォルト値

srcDirs

Object。 設定には

sourceSet.resources「入力ファイルセットを指定する 」
で述べる方法ならどれでも使用可
destinationDir

File。 設定には「ファイルを参照する 」

sourceSet.output.resourcesDir

で述べる方法ならどれでも使用可

23.11. CompileJava
Javaプラグインは、プロジェクトの各ソースセットに対して一つのJavaCompile
イ ン ス タ ン ス を 追 加 し ま す 。
compileタスクは、実際のコンパイル作業をAntのjavacタスクに委譲します。
Antのjavacタスクの大部分のプロパティが設定可能です。
表23.13 Javaプラグイン - Compileプロパティ
タスクプロパティ型

デフォルト値

classpath

FileCollection

sourceSet.compileClasspath

sourceFileTree。 設定には

sourceSet.java「入力ファイルセットを指定する 」
で述べる方法ならどれでも使用可
destinationDirFile.

sourceSet.output.classesDir

デフォルトでは、javaコンパイラはGradleプロセス上で実行されます。設定を options.fork を trueにすると、個別のプロセスでコンパイルを実行します。

Antのjavacタスクを例に挙げると,コンパイルタスクを実行するたびに新しいプロセスが実行される形で遅延実行させることも可能です。反対に、Gradleのダイレクトコンパイラの利用を有効にした場合(上記参照)

出来るだけ同一のプロセスでコンパイルを実行しようとします.

両方利用するケースの場合は、全ての処理実行オプションは

options.forkOptions

によって指定されるでしょう。

23.12. Incremental Java compilation
Starting with Gradle 2.1, it is possible to compile Java incrementally. This feature is still
incubating. See the JavaCompile task for information on how to enable it.
Main goals for incremental compilations are:
Avoid wasting time compiling source classes that don't have to be compiled. This means
faster builds, especially when a change to a source class or a jar does not incur recompilationof many source classes that depend on the changed input.

Page 154 of 436

Change as few output classes as possible. Classes that don't need to be recompiled remainunchanged in the output directory. An example scenario when this is really useful is using
JRebel - the fewer output classes are changed the quicker the jvm can use refreshed classes.
The incremental compilation at a high level:
The detection of the correct set of stale classes is reliable at some expense of speed. The
algorithm uses bytecode analysis and deals gracefully with compiler optimizations (inlining of
non-private constants), transitive class dependencies, etc. Example: When a class with apublic constant changes, we eagerly compile everything to avoid problems with constants
inlined by the compiler. Down the road we will tune the algorithm and caching so that
incremental Java compilation can be a default setting for every compile task.
To make incremental compilation fast, we cache class analysis results and jar snapshots. The
initial incremental compilation can be slower due to the cold caches.

23.13. テスト
testタスクはTestのインスタンスです。

このタスクは、test

ソースセットに含まれるすべてのユニットテストを自動的に検出し、実行します。
また、テストの実行が完了するとレポートを生成します。JUnitとTestNGの両方がサポートされています。
完全なAPIについては、Testを見てください。

23.13.1. テストの実行
テストの実行は別のJVMで行われ、メインのビルドプロセスからは分離されます。Test
タスクのAPIを使って、テストの実行を制御できます。
テストプロセスの起動を制御するための多くのプロパティが用意されています。
これにはシステムプロパティや、JVMへの引数、Java実行コマンドなどが含まれます。
テストが並列に実行されるかどうかを指定することができます。
Gradleでは、複数のテストプロセスを同時に実行する並列テスト実行が可能です。

各テストプロセスは一度に一つのテストだけを実行するので、通常、これを活用するために何か特別な準備をする必要
maxParallelForksプロパティで、同時に実行されるテストプロセスの最大個数を指定します。
デフォルトは1で、これはテストが並列実行されないということです。
テストプロセスでは、そのテストプロセスの一意な識別子であるorg.gradle.test.worker
システムプロパティが設定されます。
これは例えばファイル名の一部や、その他のリソースの識別子などに利用することができます。
一定のテストクラスを実行し終わったら、そのテストプロセスが再起動されるように指定することができます。
これは、テストプロセスに巨大なヒープを割り当てることに対する便利な代替手段になりえます。 forkEvery
プロパティは、一つのテストプロセス内で実行されるテストクラスの最大数を指定します。
デフォルトでは各テストプロセスで無制限な数のテストを実行できます。
このタスクは、テストが失敗したときの振る舞いを制御するignoreFailures
プロパティを持っています。 Testはいつも見つけたテストをすべて実行します。 ignoreFailures

Page 155 of 436

がfalseのとき、失敗したテストがあるとそれ以降のビルドは停止されます。

ignoreFailuresのデフォルト値はfalseです。
t e s t L o g g i n g
プロパティで、どのテストイベントを、どのログレベルでログに出すべきか設定することができます。

デフォルトでは、全ての失敗したテストに対して簡潔なメッセージがログ出力されます。好みに応じてテストログを設
TestLoggingContainerを参照してください。

23.13.2. Debugging
The test task provides a Test.getDebug() property that can be set to launch to make the JVM
wait for a debugger to attach to port 5005 before proceeding with test execution.
This can also be enabled at invocation time via the --debug-jvm task option (since Gradle
1.12).

23.13.3. Test filtering
Starting with Gradle 1.10, it is possible to include only specific tests, based on the test namepattern. Filtering is a different mechanism than test class inclusion / exclusion that will be
described in the next few paragraphs (-Dtest.single, test.include and friends). The latteris based on files, e.g. the physical location of the test implementation class. File-level test
selection does not support many interesting scenarios that are possible with test-level filtering.
Some of them Gradle handles now and some will be satisfied in future releases:
Filtering at the level of specific test methods; executing a single test method
Filtering based on custom annotations (future)
Filtering based on test hierarchy; executing all tests that extend ceratain base class (future)
Filtering based on some custom runtime rule, e.g. particular value of a system property orsome static state (future)
Test filtering feature has following characteristic:
Fully qualified class name or fully qualified method name is supported, e.g.
“org.gradle.SomeTest”, “org.gradle.SomeTest.someMethod”
Wildcard '*' is supported for matching any characters
Command line option “--tests” is provided to conveniently set the test filter. Especially
useful for the classic 'single test method execution' use case. When the command line option
is used, the inclusion filters declared in the build script are ignored.
Gradle tries to filter the tests given the limitations of the test framework API. Some advanced,
synthetic tests may not be fully compatible with filtering. However, the vast majority of tests
and use cases should be handled neatly.
Test filtering supersedes the file-based test selection. The latter may be completely replacedin future. We will grow the the test filtering api and add more kinds of filters.

Page 156 of 436

例23.11 Filtering tests in the build script
build.gradle
test {
filter {//include specific method in any of the tests
includeTestsMatching "*UiCheck"//include all tests from package
includeTestsMatching "org.gradle.internal.*"//include all integration tests
includeTestsMatching "*IntegTest"}}

For more details and examples please see the TestFilter reference.
Some examples of using the command line option:
gradle test --tests org.gradle.SomeTest.someSpecificFeaturegradle test --tests *SomeTest.someSpecificFeaturegradle test --tests *SomeSpecificTest
gradle test --tests all.in.specific.package*gradle test --tests *IntegTest
gradle test --tests *IntegTest*ui*
gradle someTestTask --tests *UiTest someOtherTestTask --tests *WebTest*ui

23.13.4. Single test execution via System Properties
This mechanism has been superseded by 'Test Filtering', described above.

Setting a system property of taskName.single = testNamePattern will only execute tests
that match the specified testNamePattern . The taskName can be a full multi-project path like“:sub1:sub2:test” or just the task name. The testNamePattern will be used to form an
include pattern of “**/testNamePattern*.class”;. If no tests with this pattern can be found an
exception is thrown. This is to shield you from false security. If tests of more than one subproject
are executed, the pattern is applied to each subproject. An exception is thrown if no tests can befound for a particular subproject. In such a case you can use the path notation of the pattern, sothat the pattern is applied only to the test task of a specific subproject. Alternatively you canspecify the fully qualified task name to be executed. You can also specify multiple patterns.
Examples:taskName.single = testNamePattern というシステムプロパティを設定すると、指定された
testNamePattern にマッチするテストだけが実行されます。

taskNameには、":sub1:sub2:test"のような完全なマルチプロジェクトパスか、単なるタスク名が使えます。
t e s t N a m e P a t t e r nは、"**/testNamePattern*.class"という形式のincludesパターンを構成するのに使われます。

Page 157 of 436

このパターンでテストが一つも見つからない場合は例外が発生します。
これは手違いによる偽りの安心を防ぐためです。
複数のサブプロジェクトに対してテストが実行される場合、パターンは各サブプロジェクトに適用されます。
ある一つのサブプロジェクトでテストが見つからなかった場合でも例外が発生します。

このような場合は、パターンのパス記法を使って、パターンが特定のサブプロジェクトのtestタスクだけに適用される
あるいは、完全修飾タスク名を使って実行するタスクを指定することも可能です。
パターンは複数指定することもできます。以下は実例です：
gradle -Dtest.single=ThisUniquelyNamedTest test
gradle -Dtest.single=a/b/ test
gradle -DintegTest.single=*IntegrationTest integTest
gradle -Dtest.single=:proj1:test:Customer build
gradle -DintegTest.single=c/d/ :proj1:integTest

23.13.5. テストの検出
T

e

s

t

タスクは、コンパイル済みのtestクラスを調べて、どのクラスがテストクラスかを見つけだします。
デフォルトでは、すべての.classファイルがスキャンされます。 カスタムの includes / excludesを設定して、特定のクラスだけをスキャンするようにもできます。
テストクラスの検出には、使用するテストフレームワーク(JUnit/

TestNG)によって異なる基準が使われます。
JUnitを使っている場合は、JUnit

3と4両方のテストクラスをスキャンします。

以下のいずれかの基準に合致する場合、そのクラスはJUnitのテストクラスだと見なされます：
そのクラスまたはスーパークラスが TestCaseかGroovyTestCaseをextendsしている
そのクラスまたはスーパークラスに @RunWithアノテーションが付いている
そのクラスまたはスーパークラスが@Testアノテーションが付いたメソッドを含んでいる
TestNGを使っている場合は、@Testアノテーションが付いたメソッドをスキャンします。
抽象クラスは実行されないことに注意してください。
Gradleは、testクラスパス上のjarファイルに含まれる継承ツリーもスキャンします。
上記のテストクラス検出を使いたくないときは、scanForTestClasses
をfalseに設定することで、これを無効にすることができます。

この場合、testタスクがテストクラスを探すときにはincludes / excludesだけが使われます。 scanForTestClasse
が無効になっていて、かつincludesやexcludesパターンが指定されていないときは、
デフォルトとしてincludesには "**/*Tests.class","**/*Test.class" 、そしてexcludesには"**/Abstract*.class"が使われます。

23.13.6. Test grouping
JUnit and TestNG allows sophisticated groupings of test methods.
For grouping JUnit test classes and methods JUnit 4.8 introduces the concept of categories. [16]The test task allows the specification of the JUnit categories you want to include and exclude.

Page 158 of 436

例23.12 JUnit Categories
build.gradle
test {
useJUnit {includeCategories 'org.gradle.junit.CategoryA'
excludeCategories 'org.gradle.junit.CategoryB'}}

The TestNG framework has a quite similar concept. In TestNG you can specify different test
groups. [17] The test groups that should be included or excluded from the test execution can be
configured in the test task.
例23.13 Grouping TestNG tests
build.gradle
test {
useTestNG {excludeGroups 'integrationTests'
includeGroups 'unitTests'}}

23.13.7. Test reporting
The Test task generates the following results by default.
An HTML test report.
The results in an XML format that is compatible with the Ant JUnit report task. This format is
supported by many other tools, such as CI servers.
Results in an efficient binary format. The task generates the other results from these binary
results.
There is also a stand-alone TestReport task type which can generate the HTML test report fromthe binary results generated by one or more Test task instances. To use this task type, you needto define a destinationDir and the test results to include in the report. Here is a sample
which generates a combined report for the unit tests from subprojects:

Page 159 of 436

例23.14 Creating a unit test report for subprojects
build.gradle
subprojects {apply plugin: 'java'// Disable the test report for the individual test task
test {
reports.html.enabled = false}}
task testReport(type: TestReport) {destinationDir = file("$buildDir/reports/allTests")// Include the results from the `test` task in all subprojects
reportOn subprojects*.test}

You should note that the TestReport type combines the results from multiple test tasks andneeds to aggregate the results of individual test classes. This means that if a given test class is
executed by multiple test tasks, then the test report will include executions of that class, but it
can be hard to distinguish individual executions of that class and their output.

23.13.7.1. TestNG parameterized methods and reporting
TestNG supports parameterizing test methods, allowing a particular test method to be executed
multiple times with different inputs. Gradle includes the parameter values in its reporting of thetest method execution.
Given a parameterized test method named aTestMethod that takes two parameters, it will bereported with the name: aTestMethod(toStringValueOfParam1, toStringValueOfParam2). This makes identifying the parameter values for a particular iteration easy.

23.13.8. 規約値
表23.14 Javaプラグイン - テストプロパティ
タスクプロパティ型

デフォルト値

testClassesDirFilesourceSets.test.output.classesDirclasspath

FileCollection

sourceSets.test.runtimeClasspath

testResultsDir

File

testResultsDir

testReportDir

FiletestReportDir

testSrcDirs

List<File>sourceSets.test.java.srcDirs

Page 160 of 436

23.14. Jarjar

タスクは、プロジェクトのクラスファイルとリソースを含んだJARファイルを生成します。このJARファイルは
a

r

c

h

i

v

e

s

という依存関係のコンフィギュレーションで、アーティファクトとして宣言されています。
これは、（このプロジェクトに）依存しているプロジェクトのクラスパスでこのJARが利用可能ということです。

プロジェクトをリポジトリにアップロードする場合、このJARは依存関係のディスクリプタの一部として宣言されます
アーカイブの扱いについては「アーカイブを作成する 」、アーティファクトの設定については52章
アーティファクトの公開 で、さらに詳しく学ぶことができます。

23.14.1. Manifest
各jarやwarオブジェクトは、それぞれ Manifest のインスタンスである manifest
プロパティを持ちます。

アーカイブが生成されるとき、対応するMANIFEST.MF

ファイルがアーカイブ内に作成されます。
例23.15 MANIFEST.MFのカスタマイズ
build.gradlejar {manifest {attributes("Implementation-Title": "Gradle","Implementation-Version": version)}}

独立したManifestインスタンスを生成することもできます。
これは例えば、複数のjar間でマニフェスト情報を共有する目的などに利用できます。
例23.16 manifestオブジェクトの作成
build.gradle
ext.sharedManifest = manifest {attributes("Implementation-Title": "Gradle","Implementation-Version": version)}task fooJar(type: Jar) {manifest = project.manifest {from sharedManifest}}

Manifestオブジェクトに他のマニフェストをマージすることもできます。
マージ対象のマニフェストは、ファイルパス、または上の例のように別のManifest
オブジェクトの参照によって指定できます。

Page 161 of 436

例23.17 特定のアーカイブ用にMANIFEST.MFを分離
build.gradle
task barJar(type: Jar) {manifest {attributes key1: 'value1'
from sharedManifest, 'src/config/basemanifest.txt'
from('src/config/javabasemanifest.txt','src/config/libbasemanifest.txt') {eachEntry { details ->if (details.baseValue != details.mergeValue) {details.value = baseValue}if (details.key == 'foo') {details.exclude()
}
}
}
}
}

マニフェストはfrom文で宣言された順にマージされます。

元のマニフェストとマージするマニフェストの双方に同じキーを持つ値が定義されている場合、デフォルトではマージ
マージの振る舞いは、マージで生成されるマニフェストの各エントリに対するManifestMergeDetails インスタンスにアクセスする、 eachEntry
アクションを追加することによって自在にカスタマイズ可能です。

マージはfrom文によって即座に実行されるわけではありません。 jarの生成時、またはwriteToや effectiveManifの呼び出し時に、遅延して実行されます。
マニフェストをディスクに書き出すのは簡単です。
例23.18 特定のアーカイブ用にMANIFEST.MFを分離
build.gradle
jar.manifest.writeTo("$buildDir/mymanifest.mf")

23.15. アップロード
作成したアーカイブをアップロードする方法は、52章アーティファクトの公開 で説明しています。

[16] The JUnit wiki contains a detailed description on how to work with JUnit categories:
https://github.com/junit-team/junit/wiki/Categories.
[ 17 ]The

TestNG

documentation

contains

moredetails

about

test

groups:http://testng.org/doc/documentation-main.html#test-groups.

Page 162 of 436

24Groovyプラグイン
Groovyプラグインは、Javaプラグインを拡張し、Groovyプロジェクトのサポートを追加したものです。

GroovyコードとGroovy/Javaの混合コードをサポートするほか、Javaコードのみのプロジェクトを取り扱うこともでき

また、JavaとGroovyのジョイントコンパイルをサポートしており、GroovyコードとJavaコードを自由に混ぜ合わせた

例えば、GroovyのクラスはJavaのクラスを継承できますし、更にそのJavaクラスがGroovyクラスを継承していても問24.1. 使用方法
Groovyプラグインを使うためには、ビルドスクリプトに下記を含めます：
例24.1 Groovyプラグインの使用
build.gradle
apply plugin: 'groovy'

24.2. タスク
Groovyプラグインは、以下のタスクをプロジェクトに追加します。
表24.1 Groovyプラグイン - タスク
タスク名

依存先

型

説明

compileGroovy

compileJava

GroovyCompile

製品のGroovyソースファイルをコンパイルすcompileTestGroovy

compileTestJava

GroovyCompile

テストのGroovyソースファイルをコンパイル

GroovyCompile
compileSourceSetGroovy
compileSourceSetJava

特定のソースセットのGroovyソースファイル

groovydoc-

Groovydoc

製品のGroovyソースファイルのAPIドキュメ

Groovyプラグインは、Javaプラグインによって追加されたタスクに以下の依存関係を追加します。

Page 163 of 436

表24.2 Groovyプラグイン - タスクの追加依存関係
タスク名

依存先

classescompileGroovy

testClasses

compileTestGroovy

sourceSetClasses

compileSourceSetGroovy

図24.1 Groovyプラグイン - タスク

24.3. プロジェクトレイアウト
Groovyプラグインでは、表24.3「Groovyプラグイン-

プロジェクトレイアウト」に示したようなプロジェクトレイアウトを想定しています。すべてのGroovyソースディレクトリは、Groovy
およびJavaコードを含むことができます。Javaソースディレクトリは、Javaソースコードだけしか含むことができません。
[

1

9

]

これらのどのディレクトリも、存在しなかったり、何も含んでいなくてもかまいません。Groovyプラグインは、単純
表24.3 Groovyプラグイン - プロジェクトレイアウト
ディレクトリ意味

src/main/java
src/main/resources
src/main/groovy

製品のGroovyソース。ジョイントコンパイルするJavaソースを含んでもよい

src/test/java
src/test/resources
src/test/groovy

テストのGroovyソース。ジョイントコンパイルするJavaソースを含んでもよいsrc/sourceSet/java
src/sourceSet/resources

src/sourceSet/groovy 特定のソースセットのGroovyソース。ジョイントコンパイルするJavaソースを含んでも24.3.1. プロジェクトレイアウトの変更
Javaプラグインと同じように、Groovyプラグインも製品コードやテストコードの場所を変更することができます。

Page 164 of 436

例24.2 Groovyソースレイアウトのカスタマイズ
build.gradle
sourceSets {main {
groovy {srcDirs = ['src/groovy']}}
test {
groovy {srcDirs = ['test/groovy']}}}

24.4. 依存関係の管理

Gradleのビルド言語はGroovyをベースにしており、Gradleの一部もGroovyで実装されているので、Gradleには既にG

ここで宣言したGroovyへの依存関係は、コンパイルクラスパスおよび実行時クラスパスに追加されます。さらに、Gr
Groovyが製品コードで使われている場合は、Groovy依存関係はcompile
コンフィギュレーションに追加してください。
例24.3 Groovyプラグインの設定
build.gradle
repositories {mavenCentral()}dependencies {compile 'org.codehaus.groovy:groovy-all:2.3.6'}

Groovyがテストコードのみで使われている場合は、Groovy依存関係はtestCompile
コンフィギュレーションに追加してください。
例24.4 Groovyテスト用の依存関係設定
build.gradle
dependencies {testCompile "org.codehaus.groovy:groovy:2.3.6"}

Gradleに同梱されているGroovyを使うには、localGroovy()

を依存関係で宣言してください。ただ注意してほしいのは、Gradleのバージョンが異なれば同梱されているGroovyのlocalGroovy()は、普通の宣言方法に比べると安全とは言えません。

Page 165 of 436

例24.5 同梱のGroovyを使用する依存関係設定
build.gradle
dependencies {compile localGroovy()}

Groovyライブラリは、必ずしもリモートのリポジトリから取得しなければならないわけではありません。ローカルのlib

ディレクトリなどに格納して、ソースコード管理システムにチェックインしたりすることもできます。
例24.6 Groovyをファイル依存関係で設定する
build.gradle
repositories {flatDir { dirs 'lib' }}
dependencies {compile module('org.codehaus.groovy:groovy:1.6.0') {dependency('asm:asm-all:2.2.3')
dependency('antlr:antlr:2.7.7')
dependency('commons-cli:commons-cli:1.2')
module('org.apache.ant:ant:1.9.3') {dependencies('org.apache.ant:ant-junit:1.9.3@jar','org.apache.ant:ant-launcher:1.9.3')}}}

The “module” reference may be new to you. See 51章依存関係の管理 for more information
about this and other information about dependency management.

24.5. Groovyクラスパスの自動設定
GroovyCompileタスクとGroovydocタスクは二つの用途でGroovyを使用します。タスクのclasspathと g r o o v y C l a s s p a t hです。前者はソースコードから参照されているクラスを配置するパスで、Groovyライブラリも典型的には他のライブ
groovyClasspathが明示的に設定されていない場合、Groovy(base)プラグインはタスクのclasspathから以下のように設定値を推論しようとします。
groovy-all(-indy)のJarがclasspathに見つかれば、そのjarをgroovyClasspathにも追加します。
groovy(-indy)のJarがclasspathに見つかれば、そして少なくとも一つのリポジトリがプロジェクトに設定されていれば、リポジトリから対応する
groovy(-indy)の依存関係を取得してgroovyClasspathに追加します。
それ以外の場合は、groovyClasspathの推論に失敗した旨のメッセージを出力してタスクは失敗します。

Page 166 of 436

Note that the “-indy” variation of each jar refers to the version with invokedynamic support.

24.6. 規約プロパティ
Groovyプラグインは、プロジェクトには規約プロパティを追加しません。

24.7. ソースセットプロパティ

Groovyプラグインは、プロジェクトの各ソースセットに以下の規約プロパティを追加します。これらのプロパティは「規約 」参照)。
表24.4 Groovyプラグイン - ソースセットプロパティ
プロパティ名型

デフォルト値

説明

groovySourceDirectorySet (読取り専用)

非null

このソースセットのGroovyソース

ファイルを含み、その他のタイプのgroovy.srcDirs

Set<File>。

[projectDir/src/
このソースセットのGroovyソース
name/groovy]「入力ファイルセットを指定する 」
で説明されたものなら何でも設定可能
allGroovy

FileTree (読取り専用)

非null

このソースセットの全Groovyソー

上記プロパティはGroovySourceSet型の規約オブジェクトにより提供されます。
また、Groovyプラグインは、いくつかのソースセットプロパティを修正します：
表24.5 Groovyプラグイン - ソースセットプロパティ
プロパティ名

変更点

allJava

Groovyソースディレクトリにあるすべての.javaファイルを追加

allSource

Groovyソースディレクトリにあるすべてのソースファイルを追加

24.8. GroovyCompile
Groovyプラグインは、プロジェクトの各ソースセットにGroovyCompile
タスクを追加します。このタスクはJavaCompileタスクを拡張したものです(「CompileJava」
参照)。groovyOptions.useAnt

がtrueになっていなければ、GradleネイティブのGroovyコンパイラ統合が使用されます。Antベースのコンパイラを使
こ の G r o o v y C o m p i l e
タスクは、公式Groovyコンパイラのオプションをほとんど全てサポートしています。

Page 167 of 436

表24.6 Groovyプラグイン - GroovyCompileプロパティ
タスクプロパティ型

デフォルト値

classpath

FileCollection

sourceSet.compileClasspath

sourceFileTree。

sourceSet.groovy「入力ファイルセットを指定する 」
で説明されたものなら何でも設定可能
destinationDirFile.

sourceSet.output.classesDirgroovyClasspath

FileCollection

groovy configuration if
non-empty; Groovy libraryfound on classpathotherwise[19] Russel WinderのGant (http://gant.codehaus.org)が導入したのと同じ規約を使っています。

Page 168 of 436

25
Scalaプラグイン
Scalaプラグインは、Javaプラグインを拡張し、Scalaプロジェクトのサポートを追加したものです。

ScalaコードとScala/Javaの混合コードをサポートするほか、Javaコードのみのプロジェクトを取り扱うこともできま

また、JavaとScalaのジョイントコンパイルをサポートしており、ScalaコードとJavaコードを自由に混ぜ合わせたり、

例えば、ScalaのクラスはJavaのクラスを継承できますし、更にそのJavaクラスがScalaクラスを継承していても問題あ25.1. 使用方法
Scalaプラグインを使うには、ビルドスクリプトに以下の行を追加します。
例25.1 Scalaプラグインを使う
build.gradle
apply plugin: 'scala'25.2. タスク
Scalaプラグインは、プロジェクトに以下のタスクを追加します。
表25.1 Scalaプラグイン - タスク
タスク

依存先

型

説明

compileScalacompileJava

ScalaCompile

Scalaの製品ソースファイルをコンパイルする。

compileTestScalacompileTestJava

ScalaCompile

Scalaのテストソースファイルをコンパイルする

ScalaCompile
compileSourceSetScalacompileSourceSetJava

指定したソースセットのScalaソースファイルを

scaladoc-

ScalaDoc

Scala製品ソースファイルのAPIドキュメントを

Scalaプラグインは、Javaプラグインによって追加されたタスクに以下の依存関係を追加します。

Page 169 of 436

表25.2 Scalaプラグイン - タスクの追加依存関係
タスク名

依存先

classescompileScala

testClasses

compileTestScalasourceSetClasses

compileSourceSetScala

図25.1 Scalaプラグイン - タスク

25.3. プロジェクトレイアウト
Scalaプラグインは次のようなプロジェクトレイアウトを想定しています。
すべてのScalaソースディレクトリにはScala だけでなくJavaコードも含めることができますが、JavaソースディレクトリにはJavaコードしか含めることができません。

また、これらのどのディレクトリも、存在しなかったり、何も含んでいなくてもかまいません。Scalaプラグインは、
表25.3 Scalaプラグイン
ディレクトリ意味

src/main/java
src/main/resources
src/main/scala

製品のScalaソース。ジョイントコンパイルするJavaソースを含んでもよい

src/test/java
src/test/resources
src/test/scala

テストのScalaソース。ジョイントコンパイルするJavaソースを含んでもよいsrc/sourceSet/java
src/sourceSet/resources
src/sourceSet/scala

特定のソースセットのScalaソース。ジョイントコンパイルするJavaソースを含んでもよ25.3.1. プロジェクトレイアウトの変更
Javaプラグインと同じように、Scalaプラグインも製品コードやテストコードの場所を変更することができます。

Page 170 of 436

例25.2 Scalaソースレイアウトのカスタマイズ
build.gradle
sourceSets {main {
scala {
srcDirs = ['src/scala']}}
test {
scala {
srcDirs = ['test/scala']}}}

25.4. 依存関係の管理
Scalaプロジェクトでは、 scala-library への依存関係を宣言する必要があります。

この依存関係は、Scalaコードをコンパイルしたり実行したりする際のクラスパスに追加されるほか、Scalaコンパイラ[20]

Scalaが製品コードで使われている場合は、 scala-library への依存関係は compile
コンフィグレーションに追加してください。
例25.3 製品コードに使うScalaへの依存関係の宣言
build.gradle
repositories {mavenCentral()}dependencies {compile 'org.scala-lang:scala-library:2.11.1'}

Scalaがテストコードのみで使われている場合は、scala-libraryへの依存関係はtestCompile
コンフィグレーションに追加してください。
例25.4 テストコードに使うScalaへの依存関係の宣言
build.gradle
dependencies {testCompile "org.scala-lang:scala-library:2.11.1"}

Page 171 of 436

25.5. scalaClasspathの自動設定
ScalaCompileタスクとScalaDocタスクは二つの用途でScalaを使用します。タスクのclasspathと s c a l a C l a s s p a t hです。前者はソースコードから参照されているクラスを配置するパスで、scala-libraryも典型的には他のライブラリとscalaClasspathが明示的に設定されていない場合、Scala(base)プラグインはタスクのclasspathから以下のように設定値を推論しようとします。
scala-libraryのJarがclasspathに見つかれば、そして少なくとも一つのリポジトリがプロジェクトに設定されていれば、リポジトリから対応する
scala-compilerの依存関係を取得してscalaClasspathに追加します。
それ以外の場合は、scalaClasspathの推論に失敗した旨のメッセージを出力してタスクは失敗します。

25.6. 規約プロパティ
Scalaプラグインは、プロジェクトに規約プロパティを追加しません。

25.7. ソースセットプロパティ

Scalaプロジェクトの各ソースセットに以下の規約プロパティを追加します。これらのプロパティは、あたかもソース「規約 」参照）
表25.4 Scalaプラグイン - ソースセットプロパティ
プロパティ名型

デフォルト値

説明

scala

SourceDirectorySet (読取り専用)

非null

このソースセットのScalaソースファ

ファイルを含み、その他のタイプのscala.srcDirs「入力ファイルセットを指定する 」[projectDir/src/
このソースセットのScalaソースファ
name/scala]で説明されたものなら何でも設定可能
allScala

FileTree (読取り専用)

非null

このソースセットの全Scalaソースフ

これらの規約プロパティはScalaSourceSet型の規約オブジェクトにより提供されます。
また、Scalaプラグインはいくつかのソースセットプロパティを修正します。
表25.5 Scalaプラグイン
プロパティ名

変更点

allJava

Scalaソースディレクトリにあるすべての.javaファイルを追加

allSource

Scalaソースディレクトリにあるすべてのファイルを追加

Page 172 of 436

25.8. Fast Scala Compiler
Scalaプラグインには、fsc、Fast Scala Compilerのサポートが含まれています。
例25.5 Fast Scala Compilerを有効にする
build.gradle
compileScala {scalaCompileOptions.useCompileDaemon = true// optionally specify host and port of the daemon:
scalaCompileOptions.daemonServer = "localhost:4243"}

ただし、次の点に注意してください。 fscは、コンパイル時のクラスパス に含まれるもの（訳注：jarなど）が変更される度に再起動させる必要があります。（コンパイル時クラスパス自体の変更は検知されま
このため、マルチプロジェクトとの相性は悪くなります。

25.9. 別プロセスでコンパイルする
scalaCompileOptions.fork
オプションがtrueにセットされていると、コンパイル処理は外部プロセスで実行されます。
フォーク処理の詳細はどのコンパイラを使用するかにより異なり、Antベースのコンパイラを使用する場合は（scalaCompileOptions.useAnt=

true ）、 ScalaCompile

タスクが実行される度に新しいプロセスがフォークされます。また、デフォルトではフォークされません。
Zincベースのコンパイラを使う場合（scalaCompileOptions.useAnt

=

false

）、Gradleのコンパイラデーモンを使用してコンパイルされます。Antベースのコンパイラと異なり、こちらがデフォ
外部プロセスのメモリ設定は、デフォルトではJVMのデフォルト値が使用されます。メモリ設定を調整するには、
scalaCompileOptions.forkOptionsを必要に応じて設定してください。
例25.6 メモリ設定の調整
build.gradle
tasks.withType(ScalaCompile) {configure(scalaCompileOptions.forkOptions) {memoryMaximumSize = '1g'
jvmArgs = ['-XX:MaxPermSize=512m']}}

25.10. インクリメンタルコンパイル

前回コンパイルしたときからの変更差分、およびそれにより影響を受けるクラスのみを再コンパイルすることで、Sca

これは、コードを小さく変更して頻繁にコンパイルするようなとき、開発中にはしばしばそういうことがありますが、Page 173 of 436

Scalaプラグインは、Zincという、sbtのインクリメンタルScalaコンパイラのスタンドアローン版を統合することでインクリメンタルコンパイルをサポート
例25.7 Zincベースのコンパイラを有効にする
build.gradle
tasks.withType(ScalaCompile) {scalaCompileOptions.useAnt = false}

A P I ド キ ュ メ ン トに記載されている部分を除き、ZincベースのコンパイラはAntベースのコンパイラと全く同じ設定オプションをサポー

ただ、ZincコンパイラはJava6以上のバージョンを必要とするので注意してください。これは、Gradle自身もJava6以

Scalaプラグインは、zincという名前のコンフィグレーションを追加し、Zincライブラリとその依存関係を解決するた
Gradleがデフォルトで使用するZincのバージョンをオーバーライドするには、Zincへの依存関係（例えば、
zinc"com.typesafe.zinc:zinc:0.1.4" ）を明示的に指定してください。

どのバージョンのZincが使用されているかにかかわらず、Zincは常にscalaToolsコンフィグレーションに含まれるSca
Antベースのコンパイラ同様、ZincベースのコンパイラもJavaとScalaのジョイントコンパイルをサポートします。
デフォルトでは、src/main/scalaにある全てのJavaとScalaのコードがジョイントコンパイルに使用されます。Zincベースのコンパイラは、たとえJava

インクリメンタルコンパイルを行うには、ソースコードを解析する必要があります。解析結果は、scalaCompileOp（適切なデフォルト値が設定されています）で指定されたファイルに保存されます。
マルチプロジェクトの場合、この解析ファイルは下流のScalaCompile
タスクに渡されるので、プロジェクトをまたいでのインクリメンタルコンパイルが可能です。
Scalaプラグインにより追加されたScalaCompile
タスクはデフォルトでそのように動作するので、追加の設定は必要ありません。 その他のScalaCompile
タスクでこの動作を有効にするには、scalaCompileOptions.incrementalOptions.publishedCodeが適切なクラスフォルダやJarアーカイブを指すように設定し、下流のタスクのコンパイルクラスパスにコードを渡す必
p u b l i s h e d C o d e

が正しく設定されていない場合、上流のソースが変更されても下流のタスクの再コンパイルが適切に動かず、コンパイ

解析処理に伴うオーバーヘッドにより、クリーンコンパイルや大規模な変更を行った後のコンパイルは、AntベースのZincのNailgunベースのデーモンモードには対応していません。代わりに、Gradle自身のコンパイラデーモンを拡張し25.11. Eclipse Integration
When the Eclipse plugin encounters a Scala project, it adds additional configuration to make theproject work with Scala IDE out of the box. Specifically, the plugin adds a Scala nature anddependency container.

Page 174 of 436

25.12. IntelliJ IDEA Integration
When the IDEA plugin encounters a Scala project, it adds additional configuration to make theproject work with IDEA out of the box. Specifically, the plugin adds a Scala facet and a Scalacompiler library that matches the Scala version on the project's class path.

Page 175 of 436

26
War プラグイン
War

プラグインはWEB

アプリケーションのプラグインを拡張したものです。

Java

WAR

ファイルを生成できるように

プラグインの

標準の

Java
JAR

ファイルは生成されなくなり、WAR アーカイブ タスクが追加されます。

26.1. 使用方法
War プラグインを使うためには、ビルドスクリプトに下記を含めます：
例26.1 Using the War pluginbuild.gradle
apply plugin: 'war'

26.2. タスク
War プラグインは 次のタスクをプロジェクトに追加します。
表26.1 War プラグイン - タスク
タスク名

依存先

型

説明

war

compileWar

WAR ファイルを生成します。

War プラグインは Java プラグインで追加されたタスクに対し、次の依存関係を追加します。
表26.2 War プラグイン - 追加されたタスクの依存関係
タスク名

依存先

assemblewar

図26.1 War プラグイン - タスク

Page 176 of 436

26.3. プロジェクトレイアウト
表26.3 War プラグイン - プロジェクトレイアウト
ディレクトリ意味

src/main/webapp

WEB アプリケーションソース

26.4. 依存関係の管理
War プラグインは providedCompile と providedRuntime の２つの依存構成を追加します。
これらの構成は WAR アーカイブには追加されないという点を除けば、それぞれ compile、runtimeと同じスコープを持ちます。

provided

構成が推移的に機能することは特筆すべき点です。

そうですね。例えば provided 構成の何れかに commons-httpclient:commons-httpclient:3.0を追加したとします。 この依存ライブラリは commons-codec に依存します。 これは、たとえ、commons-codec
が compile 構成に依存していることが明らかであったとしても WAR ファイルには httpclient もも追加されないことを意味します。

commons-codec

もし、この推移的な挙動を望まないのであれば、単純に commons-httpclient:commons-httpclient:3.0@jar
を dependencies の provided 構成に定義してください。

26.5. 規約プロパティ
表26.4 War プラグイン - ディレクトリプロパティ
プロパティ名型

デフォルト値説明

webAppDirName

Stringsrc/main/webapp

WEB

アプリケーションソースディレクトリの名前、プロジェク
webAppDirFileprojectDir/webAppDirName
WEB アプリケーションソースディレクトリ

(読取専用)

これらのプロパティは WarPluginConvention オブジェクトによって提供されています。

26.6. WarThe War class in the API documentation has additional useful information.

26.7. カスタマイズ
以下は最も重要なカスタマイズ例です。

Page 177 of 436

例26.2 Customization of war pluginbuild.gradle
configurations {moreLibs}
repositories {flatDir { dirs "lib" }mavenCentral()}dependencies {compile module(":compile:1.0") {dependency ":compile-transitive-1.0@jar"
dependency ":providedCompile-transitive:1.0@jar"}
providedCompile "javax.servlet:servlet-api:2.5"
providedCompile module(":providedCompile:1.0") {dependency ":providedCompile-transitive:1.0@jar"}
runtime ":runtime:1.0"
providedRuntime ":providedRuntime:1.0@jar"
testCompile "junit:junit:4.11"
moreLibs ":otherLib:1.0"}
war {from 'src/rootContent' // adds a file-set to the root of the archive
webInf { from 'src/additionalWebInf' } // adds a file-set to the WEB-INF dir.
classpath fileTree('additionalLibs') // adds a file-set to the WEB-INF/lib dir.
classpath configurations.moreLibs // adds a configuration to the WEB-INF/lib dir.
webXml = file('src/someWeb.xml') // copies a file to WEB-INF/web.xml}

もちろん、excludesとincludesを定義したクロージャを使って異なるファイルセットを設定することもできます。

Page 178 of 436

27
Earプラグイン
EarプラグインはWebアプリケーションのEARファイルアセンブリサポートを追加します。

Javaプラグインは必須ではありませんが、Javaプラグインを利用するプロジェクトに対してはデフォルトのJARアーカ

27.1. 使用方法
Earプラグインを使うには、ビルドスクリプトに以下を含めてください:
例27.1 Earプラグインの利用
build.gradle
apply plugin: 'ear'

27.2. タスク
Earプラグインはプロジェクトに以下のタスクを追加します。
表27.1 Earプラグイン - タスク
タスク名

依存先

型

説明

ear

compileEar

アプリケーションのEARファイルをアセン(Javaプラグインが同時に適用されている場合のみ)

Earプラグインはベースプラグインが追加したタスクに以下の依存関係を追加します。
表27.2 Earプラグイン - タスク依存関係の追加
タスク名

依存先

assembleear

Page 179 of 436

27.3. プロジェクトレイアウト
表27.3 Earプラグイン - プロジェクトレイアウト
ディレクトリ意味

src/main/application

META-INFディレクトリなどのEarリソース

27.4. 依存関係の管理
Earプラグインは2つの依存関係コンフィグレーションを追加します: deployおよびearlib deploy
コンフィグレーションにおけるすべての依存関係はEARアーカイブのルートに配置され、それらは推移的ではありません 。

earlib

コンフィグレーションにおけるすべての依存関係はEARアーカイブの'lib'ディレクトリに配置され、推移的です 。

27.5. 規約プロパティ
表27.4 Earプラグイン - ディレクトリプロパティ
プロパティ名型

デフォルト値

appDirName

Stringsrc/main/application

libDirName

Stringlib

deploymentDescriptororg.gradle.plugins.

デプロイメントディスクリプター、デフォルトは通常aear.descriptor.
DeploymentDescriptor

これらのプロパティは規約オブジェクトEarPluginConventionが提供します。

27.6. Ear
Earタスクのデフォルトのふるまいは、src/main/applicationの内容をアーカイブのルートにコピーすることです。

application

ディレクトリがデプロイメントディスクリプタMETA-INF/application.xmlを含まない場合は、生成してくれます。
Earも参照してみてください。

Page 180 of 436

27.7. カスタマイズ
最も重要なカスタマイズオプションを使う例はこちらです:
例27.2 Earプラグインのカスタマイズ
build.gradle
apply plugin: 'ear'
apply plugin: 'java'
repositories { mavenCentral() }dependencies {// The following dependencies will be the ear modules and// will be placed in the ear root
deploy project(':war')// The following dependencies will become ear libs and will// be placed in a dir configured via the libDirName property
earlib group: 'log4j', name: 'log4j', version: '1.2.15', ext: 'jar'}ear {appDirName 'src/main/app' // use application metadata found in this folder// put dependent libraries into APP-INF/lib inside the generated EAR
libDirName 'APP-INF/lib'
deploymentDescriptor { // custom entries for application.xml://
fileName = "application.xml" // same as the default value//
version = "6" // same as the default value
applicationName = "customear"
initializeInOrder = true
displayName = "Custom Ear" // defaults to project.name// defaults to project.description if not set
description = "My customized EAR for the Gradle documentation"//libraryDirectory = "APP-INF/lib" // not needed, above libDirName setting does this//module("my.jar", "java") // won't deploy as my.jar isn't deploy dependency//
webModule("my.war", "/") // won't deploy as my.war isn't deploy dependency
securityRole "admin"securityRole "superadmin"
withXml { provider -> // add a custom node to the XML
provider.asNode().appendNode("data-source", "my/data/source")}}}

fromやmetaInfといった、Earタスクが提供するカスタマイズオプションも利用できます。

Page 181 of 436

27.8.
カスタムのディスクリプタファイルを使う
ear.deploymentDescriptorセクションで設定するかわりに、既にapplication.xmlがあって、それを使いたいとしましょう。

そのためにはMETA-INF/application.xml

をソースフォルダ内の適切な場所に配置します( appDirName プロパティを参照)。
既存のファイルの内容が利用され、ear.deploymentDescriptorの設定内容は無視されます。

Page 182 of 436

28
Jetty プラグイン

JettyプラグインはWarプラグインを拡張し、あなたのWEBアプリケーションをJettyコンテナにビルドしてデプロイでき

28.1. 使用方法
Jettyプラグインを使うためには、ビルドスクリプトに下記を含めます：
例28.1 Using the Jetty pluginbuild.gradle
apply plugin: 'jetty'

28.2. タスク
Jettyプラグインは、以下のタスクを定義します。
表28.1 Jettyプラグイン - タスク
タスク名

依存先

型

説明

jettyRun

compileJettyRun

Jettyのインスタンスを開始し、webアプリケーションをデプロイしjettyRunWar

war

JettyRunWar

Jettyのインスタンスを開始し、WARファイルをデプロイしますjettyStop-

JettyStop

Jettyのインスタンスを停止します

図28.1 Jettyプラグイン - タスク

Page 183 of 436

28.3. プロジェクトレイアウト
Jettyプラグインは、Warプラグインと同じレイアウトを使用します。

28.4. 依存関係の管理
Jettyプラグインは、依存関係を定義しません。

28.5. 規約プロパティ
Jettyプラグインは、規約プロパティに従って定義されます。
表28.2 Jettyプラグイン - プロパティ
プロパティ名型

デフォルト値

説明

contextPath

String

WAR file base

The application deployment location within

namethe Jetty container.

httpPort

Integer

8080

JettyのHTTPリクエストの待受けTCPポート

stopPort

Integernull

Jettyの管理者リクエストの待受けTCPポート

stopKey

Stringnull

停止要求時にJettyに渡す文字列キー

上記プロパティはJettyPluginConvention型の規約オブジェクトにより提供されます。

Page 184 of 436

29
Checkstyleプラグイン
Checkstyleプラグインは

Checkstyleを使用して、あなたのプロジェクトのJavaソースファイルの品質チェックを行ないます。
そして、これらのチェック結果から結果レポートを生成します。

29.1. 使用方法
Checkstyleプラグインを使うためには、ビルドスクリプトに下記を含めます：
例29.1 Checkstyleプラグインの使用
build.gradle
apply plugin: 'checkstyle'

このプラグインは、品質チェックを行なうプロジェクトへの多くのタスクを加えます。
貴方はタスク実行時にチェック処理を実行させることが出来ます。 gradle check.

29.2. タスク
Checkstyleプラグインは、以下のタスクをプロジェクトに追加します:表29.1 Checkstyleプラグイン - タスク
タスク名

依存先

型

説明

checkstyleMainclasses

Checkstyle

製品のJavaソースを対象にCheckstyleを実行します。

checkstyleTest

testClasses

Checkstyle

テストのJavaソースを対象にCheckstyleを実行します。

checkstyleSourceSet
CheckstylesourceSetClasses

特定のソースセットで指定されたJavaソースを対象にChe

Checkstyleプラグインは、Javaプラグインによって追加されたタスクに以下の依存関係を追加します。
表29.2 Checkstyleプラグイン - タスクの追加依存関係
タスク名

依存先

check

全てのCheckstyleタスクは、checkstyleMain と checkstyleTestを含みます。

Page 185 of 436

29.3. プロジェクトレイアウト
Checkstyleプラグインは、以下のようなプロジェクトレイアウトを想定しています:
表29.3 Checkstyle プラグイン - プロジェクトレイアウト
ファイル

意味

config/checkstyle/checkstyle.xml

Checkstyle の設定ファイル

29.4. 依存関係の管理
Checkstyleプラグインは、以下の依存関係設定を追加します。
表29.4 Checkstyleプラグイン - 依存関係設定
名前

意味checkstyle

Checkstyleのライブラリを使用します。

29.5. 設定
CheckstyleExtensionを参照。

Page 186 of 436

30
CodeNarcプラグイン
CodeNarcプラグインは

CodeNarcを使用して、あなたのプロジェクトのGroovyソースファイルの品質チェックを行ないます。
そして、これらのチェック結果から結果レポートを生成します。

30.1. 使用方法
CodeNarcプラグインを使うためには、ビルドスクリプトに下記を含めます：
例30.1 CodeNarcプラグインの使用
build.gradle
apply plugin: 'codenarc'

このプラグインは、品質チェックを行なうプロジェクトへの多くのタスクを加えます。
貴方はタスク実行時にチェック処理を実行させることが出来ます。 gradle check.

30.2. タスク
CodeNarcプラグインを使うためには、ビルドスクリプトに下記を含めます：
表30.1 CodeNarcプラグイン - タスク
タスク名

依存先

型

説明

codenarcMain-

CodeNarc

製品のGroovyソースを対象にCodeNarcを実行します。

codenarcTest-

CodeNarc

Runs CodeNarc against the test Groovy source files.

CodeNarc

特定のソースセットで指定されたGroovyソースを対象にCodeNarcを実codenarcSourceSet-

CodeNarcプラグインは、Groovyプラグインによって追加されたタスクに以下の依存関係を追加します。
表30.2 CodeNarcプラグイン - タスクの追加依存関係
タスク名

依存先

check

全てのCodeNarcタスクは、codenarcMain と codenarcTestを含みます。

Page 187 of 436

30.3. プロジェクトレイアウト
CodeNarcプラグインは、以下のようなプロジェクトレイアウトを想定しています:
表30.3 CodeNarc プラグイン - プロジェクトレイアウト
ファイル

意味

config/codenarc/codenarc.xml

CodeNarc の設定ファイル

30.4. 依存関係の管理
CodeNarcプラグインは、以下の依存関係設定を追加します。
表30.4 CodeNarcプラグイン - 依存関係設定
名前

意味

codenarc

CodeNarcのライブラリを使用します。

30.5. 設定
CodeNarcExtensionを参照。

Page 188 of 436

31
FindBugsプラグイン
FindBugsプラグインは

FindBugsを使用して、あなたのプロジェクトのJavaソースファイルの品質チェックを行ないます。
そして、これらのチェック結果から結果レポートを生成します。

31.1. 使用方法
FindBugsプラグインを使うためには、ビルドスクリプトに下記を含めます：
例31.1 FindBugsプラグインの使用
build.gradle
apply plugin: 'findbugs'

このプラグインは、品質チェックを行なうプロジェクトへの多くのタスクを加えます。
貴方はタスク実行時にチェック処理を実行させることが出来ます。 gradle check.

31.2. タスク
FindBugsプラグインは、以下のタスクをプロジェクトに追加します:表31.1 FindBugsプラグイン - タスク
タスク名

依存先

型

説明

findbugsMainclasses

FindBugs

製品のJavaソースを対象にFindBugsを実行します。

findbugsTest

testClasses

FindBugs

テストのJavaソースを対象にFindBugsを実行します。

findbugsSourceSet
sourceSetClasses
FindBugs

特定のソースセットで指定されたJavaソースを対象にFindBugs

FindBugsプラグインは、Javaプラグインによって追加されたタスクに以下の依存関係を追加します。
表31.2 FindBugsプラグイン - タスクの追加依存関係
タスク名

依存先

check

全てのFindBugsタスクは、findbugsMain と findbugsTestを含みます。

Page 189 of 436

31.3. 依存関係の管理
FindBugsプラグインは、以下の依存関係設定を追加します。
表31.3 FindBugsプラグイン - 依存関係設定
名前

意味

findbugs

FindBugsのライブラリを使用します。

31.4. 設定
FindBugsExtensionを参照。

Page 190 of 436

32
JDependプラグイン
JDependプラグインは

JDependを使用して、あなたのプロジェクトのJavaソースファイルの品質チェックを行ないます。
そして、これらのチェック結果から結果レポートを生成します。

32.1. 使用方法
JDependプラグインを使うためには、ビルドスクリプトに下記を含めます：
例32.1 JDependプラグインの使用
build.gradle
apply plugin: 'jdepend'

このプラグインは、品質チェックを行なうプロジェクトへの多くのタスクを加えます。
貴方はタスク実行時にチェック処理を実行させることが出来ます。 gradle check.

32.2. タスク
JDependプラグインは、以下のタスクをプロジェクトに追加します:表32.1 JDependプラグイン - タスク
タスク名

依存先

型

説明

jdependMainclasses

JDepend

製品のJavaソースを対象にJDependを実行します。

jdependTest

testClasses

JDepend

テストのJavaソースを対象にJDependを実行します。

jdependSourceSet
sourceSetClasses
JDepend

特定のソースセットで指定されたJavaソースを対象にJDependを実JDependプラグインは、Javaプラグインによって追加されたタスクに以下の依存関係を追加します。
表32.2 JDependプラグイン - タスクの追加依存関係
タスク名

依存先

check

全てのJDependタスクは、jdependMain と jdependTestを含みます。

Page 191 of 436

32.3. 依存関係の管理
JDependプラグインは、以下の依存関係設定を追加します。
表32.3 JDependプラグイン - 依存関係設定
名前

意味

jdepend

JDependのライブラリを使用します。

32.4. 設定
JDependExtensionを参照。

Page 192 of 436

33
PMDプラグイン
P M D プ ラ グ イ ン は

P M D

を使用して、あなたのプロジェクトのJavaソースファイルの品質チェックを行ないます。
そして、これらのチェック結果から結果レポートを生成します。

33.1. 使用方法
PMDプラグインを使うためには、ビルドスクリプトに下記を含めます：
例33.1 PMDプラグインの使用
build.gradle
apply plugin: 'pmd'

このプラグインは、品質チェックを行なうプロジェクトへの多くのタスクを加えます。
貴方はタスク実行時にチェック処理を実行させることが出来ます。 gradle check.

33.2. タスク
PMDプラグインは、以下のタスクをプロジェクトに追加します:表33.1 PMDプラグイン - タスク
タスク名

依存先

型

説明

pmdMain-Pmd

製品のJavaソースを対象にPMDを実行します。

pmdTest-

Pmd

テストのJavaソースを対象にPMDを実行します。

pmdSourceSet-

Pmd

特定のソースセットで指定されたJavaソースを対象にPMDを実行します。

PMDプラグインは、Javaプラグインによって追加されたタスクに以下の依存関係を追加します。
表33.2 PMDプラグイン - タスクの追加依存関係
タスク名

依存先

check

全てのPMDタスクは、pmdMain と pmdTestを含みます。

Page 193 of 436

33.3. 依存関係の管理
PMDプラグインは、以下の依存関係設定を追加します。
表33.3 PMDプラグイン - 依存関係設定
名前

意味

pmd

PMDのライブラリを使用します。

33.4. 設定
PmdExtensionを参照。

Page 194 of 436

34
The JaCoCo Plugin
The JaCoCo plugin is currently incubating. Please be aware that the DSL and otherconfiguration may change in later Gradle versions.

The JaCoCo plugin provides code coverage metrics for Java code via integration with JaCoCo.

34.1. Getting Started
To get started, apply the JaCoCo plugin to the project you want to calculate code coverage for.
Example 34.1. Applying the JaCoCo pluginbuild.gradle
apply plugin: "jacoco"If the Java plugin is also applied to your project, a new task named jacocoTestReport iscreated that depends on the test task. The report is available at $buildDir /reports/jacoco/test. By default, a HTML report is generated.

34.2. Configuring the JaCoCo Plugin
The JaCoCo plugin adds a project extension named jacoco of type JacocoPluginExtension,
which allows configuring defaults for JaCoCo usage in your build.
Example 34.2. Configuring JaCoCo plugin settingsbuild.gradle
jacoco {toolVersion = "0.7.1.201405082137"
reportsDir = file("$buildDir/customJacocoReportDir")}

Page 195 of 436

Table 34.1. Gradle defaults for JaCoCo properties
Property

Gradle default

reportsDir“$buildDir/reports/jacoco”

34.3. JaCoCo Report configuration
The JacocoReport task can be used to generate code coverage reports in different formats. It
implements the standard Gradle type Reporting and exposes a report container of type
JacocoReportsContainer.
Example 34.3. Configuring test taskbuild.gradle
jacocoTestReport {reports {xml.enabled false
csv.enabled false
html.destination "${buildDir}/jacocoHtml"}}

34.4. JaCoCo specific task configuration
The JaCoCo plugin adds a JacocoTaskExtension extension to all tasks of type Test. Thisextension allows the configuration of the JaCoCo specific properties of the test task.

Page 196 of 436

Example 34.4. Configuring test taskbuild.gradle
test {
jacoco {append = false
destinationFile = file("$buildDir/jacoco/jacocoTest.exec")classDumpFile = file("$buildDir/jacoco/classpathdumps")}}

Table 34.2. Default values of the JaCoCo Task extension
Property

Gradle default

enabledtrue

destPath$buildDir/jacoco

appendtrue

includes[]excludes[]excludeClassLoaders[]

sessionId

auto-generated

dumpOnExit

true

outputOutput.FILE

address

-

port

-

classDumpPath

-

jmx

false

While all tasks of type Test are automatically enhanced to provide coverage information when
the java plugin has been applied, any task that implements JavaForkOptions can beenhanced by the JaCoCo plugin. That is, any task that forks Java processes can be used togenerate coverage information.
For example you can configure your build to generate code coverage using the application
plugin.

Page 197 of 436

Example 34.5. Using application plugin to generate code coverage databuild.gradle
apply plugin: "application"
apply plugin: "jacoco"
mainClassName = "org.gradle.MyMain"jacoco {applyTo run}task applicationCodeCoverageReport(type:JacocoReport){
executionData run
sourceSets sourceSets.main
}

ノ

ー

ト

:

本例のソースコードは、Gradleのバイナリ配布物またはソース配布物に含まれています。以下の場所をご参照くだsamples/testing/jacoco/application

Example 34.6. Coverage reports generated by applicationCodeCoverageReport
Build layout
application/build/
jacoco/run.exec
reports/jacoco/applicationCodeCoverageReport/html/
index.html

34.5. Tasks
For projects that also apply the Java Plugin, The JaCoCo plugin automatically adds the following
tasks:
Table 34.3. JaCoCo plugin - tasks
Task name

Depends

Type

Description

JacocoReport

Generates code coverage report foronjacocoTestReport-

the test task.

34.6. Dependency management
The JaCoCo plugin adds the following dependency configurations:Page 198 of 436

Table 34.4. JaCoCo plugin - dependency configurations
Name

Meaning

jacocoAnt

The JaCoCo Ant library used for running the JacocoReport and JacocoMerge
tasks.

jacocoAgent

The JaCoCo agent library used for instrumenting the code under test.

Page 199 of 436

35
Sonarプラグイン
このプラグインの代わりに、新しくできたSonnar
Runnerを使いたくなる場面もあるかもしれません。
特に、Sonar3.4以上をサポートしているのはSonar Runnerプラグインだけです。

Sonarプラグインは、コード品質モニタリングのためのWebベースのプラットフォームであるSonarとの統合機能を提供します。

プラグインにより追加されるsonarAnalyze

タスクは、プラグインが適用されたプロジェクト、およびそのサブプロジェクトを解析することができます。結果はS
このプラグインはベースにSonar Runnerが使われていて、Sonar 2.11以上を必要とします。
sonarAnalyze タスクは明示的に実行する必要のあるスタンドアロンタスクで、他のいかなるタスクにも依存しません。
ソースコードだけでなく、タスクはクラスファイルと(可能であれば)テスト結果ファイルも解析します。
そのため、最大限の結果を得るために、解析の前にフルビルドを実行することが推奨されます。
典型的なセットアップでは、解析はビルドサーバー上で1日1回実行されるようにします。

35.1. 使用方法
必要最小限、Sonarプラグインがプロジェクトに適用されている必要があります。
例35.1 Sonarプラグインの適用
build.gradle
apply plugin: "sonar"

Sonarがデフォルト設定でローカル実行されるのでなければ、Sonarサーバーとデータベースへの接続設定も必要にな

Page 200 of 436

例35.2 Sonar接続設定のコンフィグレーション
build.gradle
sonar {
server {url = "http://my.server.com"}
database {url = "jdbc:mysql://my.server.com/sonar"
driverClassName = "com.mysql.jdbc.Driver"username = "Fred Flintstone"
password = "very clever"}}

代わりに、いくつかの、または全ての接続設定をコマンドラインで設定することもできます(「コマンドラインでSonarの設定を行う 」参照)。
プロジェクト設定によって、プロジェクトをどのように解析するのかが決まります。

標準的なJavaプロジェクトに対してはデフォルト設定で事が足りますが、さまざまな方法でカスタマイズも可能です。
例35.3 Sonarプロジェクト設定のコンフィグレーション
build.gradle
sonar {
project {coberturaReportPath = file("$buildDir/cobertura.xml")}}

サンプルのsonar、server、database、およびproject
ブロックは、それぞれコンフィグレーションオブジェクト SonarRootModel、 SonarServer、SonarDatabase、およびSonarProjectに対応します。

詳細はAPIドキュメントを参照してください。

35.2. マルチプロジェクトビルドの解析
Sonarプラグインはプロジェクト階層全体を一度に解析する機能をもちます。

集約されたメトリクスとサブプロジェクトへのドリルダウン機能を含む階層ビューをSonarのWebインターフェースに個別のプロジェクトごとに解析を行うよりも高速でもあります。
プロジェクト階層を解析するには、Sonarプラグインを階層の最上位のプロジェクトに適用する必要があります。
これは、典型的には(必須ではないですが)ルートプロジェクトです。
ブロックがそのプロジェクトのsonar

SonarRootModel 型のオブジェクトを構成します。

これはすべてのグローバルコンフィグレーションを保持しますが、最も重要なのはサーバーとデータベース接続設定です。

Page 201 of 436

例35.4 マルチプロジェクトビルドにおけるグローバルコンフィグレーション
build.gradle
apply plugin: "sonar"sonar {
server {url = "http://my.server.com"}
database {url = "jdbc:mysql://my.server.com/sonar"
driverClassName = "com.mysql.jdbc.Driver"username = "Fred Flintstone"
password = "very clever"}}

階層の各プロジェクトは独自のプロジェクトコンフィグレーションを持ちます。
共通の値は親のビルドスクリプトから設定可能です。
例35.5 マルチプロジェクトビルドにおける共通のプロジェクトコンフィグレーション
build.gradle
subprojects {sonar {
project {sourceEncoding = "UTF-8"}}}

サブプロジェクトのsonarブロックは SonarProjectModel型のオブジェクトを構成します.
プロジェクトを個別に構成することもできます。

例えば、 skip プロパティを trueに 設 定 す る こ と で 、
プロジェクト(およびそのサブプロジェクト)を解析対象から除外することができます。
スキップされたプロジェクトはSonar Webインターフェースには表示されません。
例35.6 マルチプロジェクトビルドにおけるプロジェクト個別コンフィグレーション
build.gradle
project(":project1") {sonar {
project {skip = true}}}

プロジェクト単位のコンフィグレーションでもう一つ典型的なのは、解析対象のプログラム言語です。
Sonarはプロジェクトあたり一つの言語しか解析できないことに注意してください。

Page 202 of 436

例35.7 解析対象の言語のコンフィグレーション
build.gradle
project(":project2") {sonar {
project {language = "groovy"}}}

一度に単一のプロパティしか設定しないときは、等価なプロパティの文法はより簡潔になります:
例35.8 プロパティ文法の利用
build.gradle
project(":project2").sonar.project.language = "groovy"

35.3. カスタムソースセットの解析
デフォルトでは、Sonarプラグインはmainソースセットのプロダクションソースと、

test

ソースセットのテストソースを解析します。
これはプロジェクトのソースディレクトリレイアウトとは独立して動作します。
ソースセットは必要に応じて追加できます。
例35.9 カスタムソースセットの解析
build.gradle
sonar.project {sourceDirs += sourceSets.custom.allSource.srcDirs
testDirs += sourceSets.integTest.allSource.srcDirs}

35.4. Java言語以外の解析
Java以外の言語で書かれたコードを解析するには、対応するSonarプラグイン
をインストールして、次のようにsonar.project.languageを設定してください。
例35.10 Java言語以外の解析
build.gradle
sonar.project {language = "grvy" // set language to Groovy}

Sonarでは、バージョン3.4現在、一プロジェクトにつき一つの言語の解析しかできません。しかし、マルチプロジェク

Page 203 of 436

35.5. カスタムSonarプロパティの設定
最終的には、コンフィグレーションのほとんどは、Sonarプロパティとして知られるkey-valueペアの形でSonarコードアナライザに渡されます。
プラグインのオブジェクトモデルのプロパティが対応するSonarプロパティにどのようにしてマップされるかは、
APIドキュメントの SonarProperty アノテーションが示してます。
Sonarプラグインは、Sonarプロパティがコードアナライザに渡される前の後処理のためのフックを提供します。
このフックは、プラグインのオブジェクトモデルがカバーしていないプロパティを追加するためにも利用できます。
グローバルSonarプロパティに対しては、SonarRootModelのwithGlobalProperties
フックを利用してください:
例35.11 カスタムグローバルプロパティ設定
build.gradle
sonar.withGlobalProperties { props ->props["some.global.property"] = "some value"// non-String values are automatically converted to Strings
props["other.global.property"] = ["foo", "bar", "baz"]}

プロジェクト毎のSonarプロパティに対しては、SonarProjectのwithProjectProperties
フックを利用してください:
例35.12 カスタムプロジェクトプロパティ設定
build.gradle
sonar.project.withProjectProperties { props ->props["some.project.property"] = "some value"// non-String values are automatically converted to Strings
props["other.project.property"] = ["foo", "bar", "baz"]}

使用できるSonarプロパティは Sonarのドキュメント で調べることができます。
ただし、これらのプロパティのほとんどはプラグインのオブジェクトモデルに対応するプロパティがあり、withGlobalProperties や withProjectProperties
フックを使って設定する必要はありません。
サードパーティのSonarプラグインに対しては、それらのドキュメントを参照してください。

35.6. コマンドラインでSonarの設定を行う
次に示すプロパティは、sonarAnalyze
タスクのパラメーターとしてコマンドラインからでも設定できます。
タスクパラメーターは、ビルドスクリプト内の対応する値を全て上書きします。
server.url
database.url
Page 204 of 436

database.driverClassName
database.username
database.password
showSql
showSqlResultsverboseforceAnalysis
以下に使用例を示します。
gradlesonarAnalyze--server.url=http://sonar.mycompany.com--database.password=myPassword --verbose
他の値をコマンドラインから設定する必要がある場合は、システムプロパティが使用できます。
例35.13 カスタムのコマンドラインプロパティを実装する
build.gradle
sonar.project {language = System.getProperty("sonar.language", "java")}

ただ、たいていの場合は設定値をビルドスクリプトに格納し、ソースコード管理システムで管理するのが一番良い方法

35.7. タスク
Sonarプラグインはプロジェクトに以下のタスクを追加します。
表35.1 Sonarプラグイン - タスク
タスク名

依存先

タイプ

説明

sonarAnalyze-

SonarAnalyze

プロジェクト階層全体を解析し、結果をSonarデータベースに格納

Page 205 of 436

36
The Sonar Runner Plugin
The Sonar Runner plugin is currently incubating. Please be aware that the DSL and otherconfiguration may change in later Gradle versions.
It is intended that this plugin will replace the older Sonar Plugin in a future Gradle version.

The Sonar Runner plugin provides integration with Sonar, a web-based platform for monitoringcode quality. It is based on the Sonar Runner, a Sonar client component that analyzes sourcecode and build outputs, and stores all collected information in the Sonar database. Compared tousing the standalone Sonar Runner, the Sonar Runner plugin offers the following benefits:
Automatic provisioning of Sonar Runner
The ability to execute the Sonar Runner via a regular Gradle task makes it available anywhere
Gradle is available (developer build, CI server, etc.), without the need to manually download,
setup, and maintain a Sonar Runner installation.
Dynamic configuration from Gradle build scripts
All of Gradle's scripting features can be leveraged to configure Sonar Runner as needed.
Extensive configuration defaults
Gradle already has much of the information needed for Sonar Runner to successfully analyze
a project. By preconfiguring the Sonar Runner based on that information, the need for
manual configuration is reduced significantly.

36.1. Sonar Runner version andcompatibility
The default version of the Sonar Runner used by the plugin is 2.3, which makes it compatible
with Sonar 3.0 and higher. For compatibility with Sonar versions earlier than 3.0, you canconfigure the use of an earlier Sonar Runner version (see Section 36.4, “Specifying the Sonar
Runner version”).

36.2. Getting started
To get started, apply the Sonar Runner plugin to the project to be analyzed.

Page 206 of 436

Example 36.1. Applying the Sonar Runner pluginbuild.gradle
apply plugin: "sonar-runner"

Assuming a local Sonar server with out-of-the-box settings is up and running, no further
mandatory configuration is required. Execute gradle sonarRunner and wait until the build hascompleted, then open the web page indicated at the bottom of the Sonar Runner output. You
should now be able to browse the analysis results.
Before executing the sonarRunner task, all tasks producing output to be analysed by Sonar
need to be executed. Typically, these are compile tasks, test tasks, and code coverage tasks. To
meet these needs, the plugins adds a task dependency from sonarRunner on test if the java
plugin is applied. Further task dependencies can be added as needed.

36.3. Configuring the Sonar Runner
The Sonar Runner plugin adds a SonarRunnerRootExtension extension to the project and a
SonarRunnerExtension extension to its subprojects, which allows you to configure the Sonar
Runner via key/value pairs known as Sonar properties . A typical base line configuration includes
connection settings for the Sonar server and database.
Example 36.2. Configuring Sonar connection settingsbuild.gradle
sonarRunner {sonarProperties {property "sonar.host.url", "http://my.server.com"
property "sonar.jdbc.url", "jdbc:mysql://my.server.com/sonar"
property "sonar.jdbc.driverClassName", "com.mysql.jdbc.Driver"property "sonar.jdbc.username", "Fred Flintstone"
property "sonar.jdbc.password", "very clever"}}

Alternatively,

Sonar

properties

can

be

set

from

the

command

line.

See

「コマンドラインでSonarの設定を行う 」 for more information.
For a complete list of standard Sonar properties, consult the Sonar documentation. If you
happen to use additional Sonar plugins, consult their documentation.
In addition to set Sonar properties, the SonarRunnerRootExtension extension allows theconfiguration of the Sonar Runner version and the JavaForkOptions of the forked Sonar
Runner process.
The Sonar Runner plugin leverages information contained in Gradle's object model to provide
smart defaults for many of the standard Sonar properties. The defaults are summarized in thetables below. Notice that additional defaults are provided for projects that have the java-base

Page 207 of 436

or java plugin applied. For some properties (notably server and database connection settings),
determining a suitable default is left to the Sonar Runner.
Table 36.1. Gradle defaults for standard Sonar properties
Property

Gradle default

sonar.projectKey“$project.group:$project.name” (for root project of analysedhierarchy; left to Sonar Runner otherwise)sonar.projectName

project.namesonar.projectDescription

project.description

sonar.projectVersion

project.version

sonar.projectBaseDir

project.projectDirsonar.working.directory“$project.buildDir/sonar”

sonar.dynamicAnalysis“reuseReports”

Table 36.2. Additional defaults when java-base plugin is applied
Property

Gradle default

sonar.java.source

project.sourceCompatibility

sonar.java.target

project.targetCompatibility

Table 36.3. Additional defaults when java plugin is applied
Property

Gradle default

sonar.sources

sourceSets.main.allSource.srcDirs (filtered to only include
existing directories)

sonar.tests

sourceSets.test.allSource.srcDirs (filtered to only include
existing directories)

sonar.binaries

sourceSets.main.runtimeClasspath (filtered to only include
directories)

sonar.libraries

sourceSets.main.runtimeClasspath (filtering to only include
files; rt.jar added if necessary)

sonar.surefire.reportsPathtest.testResultsDir (if the directory exists)sonar.junit.reportsPathtest.testResultsDir (if the directory exists)

Table 36.4. Additional defaults when jacoco plugin is applied
Property

Gradle default

sonar.jacoco.reportPathjacoco.destinationFile

Page 208 of 436

36.4. Specifying the Sonar Runner version
By default, version 2.3 of the Sonar Runner is used. To specify an alternative version, set the
SonarRunnerRootExtension.getToolVersion() property of the sonarRunner extension of
the project the plugin was applied to to the desired version. This will result in the Sonar Runnerdependencyorg.codehaus.sonar.runner:sonar-runner-dist:«toolVersion»

being

used as the Sonar Runner.
Example 36.3. Configuring Sonar runner version
build.gradle
sonarRunner {toolVersion = '2.3' // default}

36.5. Analyzing Multi-Project Builds
The Sonar Runner is capable of analyzing whole project hierarchies at once. This yields ahierarchical view in the Sonar web interface, with aggregated metrics and the ability to drill
down into subprojects. Analyzing a project hierarchy also takes less time than analyzing eachproject separately.
To analyze a project hierarchy, apply the Sonar Runner plugin to the root project of thehierarchy. Typically (but not necessarily) this will be the root project of the Gradle build.
Information pertaining to the analysis as a whole, like server and database connections settings,
have to be configured in the sonarRunner block of this project. Any Sonar properties set on thecommand line also apply to this project.
Example 36.4. Global configuration settingsbuild.gradle
sonarRunner {sonarProperties {property "sonar.host.url", "http://my.server.com"
property "sonar.jdbc.url", "jdbc:mysql://my.server.com/sonar"
property "sonar.jdbc.driverClassName", "com.mysql.jdbc.Driver"property "sonar.jdbc.username", "Fred Flintstone"
property "sonar.jdbc.password", "very clever"}}Configuration shared between subprojects can be configured in a subprojects block.

Page 209 of 436

Example 36.5. Shared configuration settingsbuild.gradle
subprojects {sonarRunner {sonarProperties {property "sonar.sourceEncoding", "UTF-8"}}}

Project-specific information is configured in the sonarRunner block of the corresponding
project.
Example 36.6. Individual configuration settingsbuild.gradle
project(":project1") {sonarRunner {sonarProperties {property "sonar.language", "grvy"}}}

To skip Sonar analysis for a particular subproject, set sonarRunner.skipProject to true.
Example 36.7. Skipping analysis of a projectbuild.gradle
project(":project2") {sonarRunner {skipProject = true}}

36.6. Analyzing Custom Source Sets
By default, the Sonar Runner plugin passes on the project's main source set as production
sources, and the project's test source set as test sources. This works regardless of the project's
source directory layout. Additional source sets can be added as needed.

Page 210 of 436

Example 36.8. Analyzing custom source setsbuild.gradle
sonarRunner {sonarProperties {properties["sonar.sources"] += sourceSets.custom.allSource.srcDirs
properties["sonar.tests"] += sourceSets.integTest.allSource.srcDirs}}

36.7. Analyzing languages other than JavaTo analyze code written in a language other than Java, you'll need to set sonar.project.language
accordingly. However, note that your Sonar server has to have the Sonar plugin that handles that
programming language.
Example 36.9. Analyzing languages other than Javabuild.gradle
sonarRunner {sonarProperties {property "sonar.language", "grvy" // set language to Groovy}}

As of Sonar 3.4, only one language per project can be analyzed. It is, however, possible toanalyze a different language for each project in a multi-project build.

36.8. More on configuring Sonar properties
Let's take a closer look at the sonarRunner.sonarProperties {} block. As we have alreadyseen in the examples, the property() method allows you to set new properties or override
existing ones. Furthermore, all properties that have been configured up to this point, including
all properties preconfigured by Gradle, are available via the properties accessor.
Entries in the properties map can be read and written with the usual Groovy syntax. To
facilitate their manipulation, values still have their “idiomatic” type (File, List, etc.). Afterthe sonarProperties block has been evaluated, values are converted to Strings as follows:
Collection values are (recursively) converted to comma-separated Strings, and all other values
are converted by calling their toString() method.
Because the sonarProperties block is evaluated lazily, properties of Gradle's object model
can be safely referenced from within the block, without having to fear that they have not yet
been set.

Page 211 of 436

36.9. Setting Sonar Properties from theCommand Line
Sonar Properties can also be set from the command line, by setting a system property named
exactly like the Sonar property in question. This can be useful when dealing with sensitive
information (e.g. credentials), environment information, or for ad-hoc configuration.

gradle sonarRunner -Dsonar.host.url=http://sonar.mycompany.com -Dsonar.jdbc.password=myPassword

While certainly useful at times, we do recommend to keep the bulk of the configuration in a(versioned) build script, readily available to everyone.

A Sonar property value set via a system property overrides any value set in a build script (for thesame property). When analyzing a project hierarchy, values set via system properties apply to theroot project of the analyzed hierarchy. Each system property starting with " "sonar." will taken
into account for the sonar runner setup.

36.10. Controlling the Sonar Runnerprocess
The Sonar Runner is executed in a forked process. This allows fine grained control over memory
settings, system properties etc. just for the Sonar Runner process. The forkOptions property ofthe sonarRunner extension of the project that applies the sonar-runner plugin (Usually the rootProjectbut not necessarily) allows the process configuration to be specified. This property is notavailable in the SonarRunnerExtension extension applied to the subprojects.
Example 36.10. setting custom Sonar Runner fork options
build.gradle
sonarRunner {forkOptions {maxHeapSize = '512m'}}

For a complete reference about the available options, see JavaForkOptions.

36.11. Tasks
The Sonar Runner plugin adds the following tasks to the project.

Page 212 of 436

Table 36.5. Sonar Runner plugin - tasks
Task name

Depends

Type

Description

SonarRunner

Analyzes a project hierarchy and stores theonsonarRunner-results in the Sonar database.

Page 213 of 436

37
OSGiプラグイン
OSGiプラグインは

OsgiManifest

オブジェクトを生成するためのファクトリメソッドを提供します。 OsgiManifest は Manifest
を継承しています。一般的な

manifest

操作に関しての詳細については、「Manifest」

を 参 照 し て く だ さ い 。
Javaプラグインが適用されている場合、OSGiプラグインはデフォルトのjarのmanifestオブジェクトを
OsgiManifest

オブジェクトに置き換えます。

置き換えられたmanifestは新しいmanifestにマージされます。
OSGiプラグインは Peter Kriens の BND tool を大いに活用しています。

37.1. 使用方法
OSGiプラグインを使うためには、ビルドスクリプトに以下のコードを追加します:
例37.1 OSGiプラグインの利用
build.gradle
apply plugin: 'osgi'

37.2. 暗黙的に適用されるプラグイン
Java ベースプラグインを適用します。

37.3. タスク
このプラグインはタスクを追加しません。

37.4. 依存関係の管理
TBD

Page 214 of 436

37.5. 規約オブジェクト
OSGiプラグインは以下の規約オブジェクトを追加します: OsgiPluginConvention

37.5.1. 規約プロパティ
OSGiプラグインはプロジェクトに規約プロパティを追加しません。

37.5.2. 規約メソッド

OSGiプラグインは以下の規約メソッドを追加します。詳細については規約オブジェクトのAPIドキュメントを参照して
表37.1 OSGiメソッド
メソッド

戻り値

説明

osgiManifest()

OsgiManifest

OsgiManifestオブジェクトを返す。

osgiManifest(Closure

OsgiManifest

クロージャによって構成されたOsgiManifestオブジェクトを返す。

cl)classesディレクトリにあるクラスのパッケージ依存関係と公開するパッケージが解析され、その情報に基づいてOSG
ManifestのImport-PackageとExport-Packageの値が決定されます。

クラスパスにOSGiバンドル形式のjarがある場合、 Import-Packageの値を決定するためにバンドルの情報が参照されます。

OsgiManifest

オブジェクトに明示的にinstructionプロパティを追加することでメタデータを追加できます。
例37.2 OSGiのMANIFEST.MFファイルの設定
build.gradlejar {manifest { // the manifest of the default jar is of type OsgiManifest
name = 'overwrittenSpecialOsgiName'
instruction 'Private-Package','org.mycomp.package1','org.mycomp.package2'
instruction 'Bundle-Vendor', 'MyCompany'
instruction 'Bundle-Description', 'Platform2: Metrics 2 Measures Framework'
instruction 'Bundle-DocURL', 'http://www.mycompany.com'}}
task fooJar(type: Jar) {manifest = osgiManifest {instruction 'Bundle-Vendor', 'MyCompany'}}

instructionの第1引数にはプロパティのキー、第2引数には値を指定します。

それらはGradleによって , で結合されます。 利用可能な instruction の詳細については BND toolを参照してください。

Page 215 of 436

38Eclipse プラグイン
Eclipse プラグインは Eclipse IDE が利用するファイルを生成し、 (ファイル - インポート... 既存プロジェクトをワークスペースへ

で)

Eclipse内にプロジェクトをインポートできるようにします。 外部依存関係 (ソースと Javadoc も含む)とプロジェクト依存関係の両方が考慮されます。
1.0-milestone-4

以降、WTP生成コードはリファクタリングされ、eclipse-wtp

プラグインに分離されました。

もしWTPが必要であれば、eclipse-wtp

プラグインを適用するだけです。必要でなければ、eclipse
プラグインを適用するだけでよいです。 この変更は WTP を利用せずに war プラグインや ear
プラグインだけを利用するという

Eclipse

ユーザの要望によるものです。

eclipse-wtp

プラグインは 内部的に eclipse プラグインも適用するので 両方を適用する必要はありません。
Eclipse プラグインが何を生成するかは どのプラグインと一緒に利用するかで決まります。
表38.1 Eclipse プラグインの振舞い
プラグイン

説明

なし

最小構成の .project ファイルを生成します。

Java

Java の構成を .project ファイルに追加します。 .classpath ファイルと JDT
設定ファイルを生成します。

GroovyGroovy の構成を.project ファイルに追加します。

ScalaAdds Scala support to .project and .classpath files.

War

WEBアプリケーションのサポートを.projectファイルと.classpath
ファイルに追加します。 eclipse-wtp プラグインを適用している場合のみ WTP
設定ファイルを生成します。

Ear

EAR アプリケーションのサポートを .project ファイルに追加します。 eclipse-wtp
プラグインを適用している場合のみ WTP 設定ファイルを生成します。

Eclipseプラグインは、カスタマイズが容易なように作られています。
生成されたファイルに内容を追加したり削除したりするための、標準化されたフックが用意されています。

38.1. 使用方法
Eclipseプラグインを使う為には、ビルドスクリプトに下記を含めます：

Page 216 of 436

例38.1 Eclipseプラグインの使用方法
build.gradle
apply plugin: 'eclipse'

Eclipseプラグインは多くのタスクをプロジェクトに追加しますが、主に利用するのは eclipse と cleanEclipse
タスクだけです。

38.2. タスク
Eclipseプラグインはプロジェクトに以下のタスクを追加します。
表38.2 Eclipse プラグイン - タスク
タスク名

依存先

型

eclipseeclipseProject, eclipseClasspath
Task, eclipseJdt, eclipseWtpComponent, cleanEclipseWtpFacetcleanEclipse

cleanEclipseProject, cleanEclipseClasspath
Delete, cleanEclipseJdt, cleanEclipseWtpComponent, cleanEclipseWtpFacetcleanEclipseProject-

DeletecleanEclipseClasspath-

DeletecleanEclipseJdt-

DeletecleanEclipseWtpComponent-

DeletecleanEclipseWtpFacet-

DeleteeclipseProject-

GenerateEclipseProject

eclipseClasspath-

GenerateEclipseClasspath

eclipseJdt-

GenerateEclipseJdt

eclipseWtpComponent-

GenerateEclipseWtpComponent

eclipseWtpFacet-

GenerateEclipseWtpFacet

Page 217 of 436

38.3. 設定
表38.3 Eclipseプラグインの設定
モデル

参照名

説明

EclipseModeleclipseDSLにあったやり方でEclipseプラグインの設定が可能な

EclipseProject

eclipse.project

プロジェクトの情報を設定できます。

EclipseClasspath

eclipse.classpath

クラスパスの情報を設定できます。 Allows configurin
information

EclipseJdt

eclipse.jdt

JDT の情報を設定できます。(source/target java互換)

EclipseWtpComponent

eclipse.wtp.component

eclipse-wtp

プラグインを適用した場合のみ、WTPコンポーネントのEclipseWtpFaceteclipse.wtp.facet

eclipse-wtp

プラグインを適用した場合のみ、WTPファセットの情報

38.4. 生成されたファイルをカスタマイズする
Eclipseプラグインは、生成されるメタデータファイルをカスタマイズできるようになっています。

このプラグインでは、DSLを使ってモデルオブジェクトの設定を行うことができます。このモデルオブジェクトは、E

DSLで設定したEclipseのモデルオブジェクトは、既存のXMLメタデータとマージされ、最終的な新しいメタデータが生メタデータの内容は、ドメインオブジェクトという形で表現されます。マージ前後にそのドメインオブジェクトを操作

また、さらに低レベルなフックも用意されており、メタデータをファイルに保存する前に、生のXMLデータを直接取りそのフックを使えば、プラグインがモデル化していない設定要素を微調整したり編集したりすることも可能です。

38.4.1. マージする

既存のEclipseファイルの、対象のセクションだけを生成された内容で変更、もしくは上書きし、それ以外はそのまま

38.4.1.1. マージせずに完全に上書きする
既存のEclipse

ファイルを完全に上書きしたい場合は、対応する生成タスクと一緒にタスクも実行します。
この順番で...)

例えば

gradlecleanEclipse

eclipseのように...

clean

(もちろん

もし、この動きをデフォルトにしたい場合は、ビルドスクリプトに

eclipse.dependsOn(cleanEclipse)を追加します。

そうすれば

明示的に

clean

タスクを実行する必要はありません。
This strategy can also be used for individual files that the plugin would generate. For instance,
this can be done for the “.classpath” file with “gradle cleanEclipseClasspath eclipseClasspath”.

個々のファイルについても同じように完全に上書きすることができます。例えば、 gradle cleanEclipseClasspのように...

Page 218 of 436

38.4.2. 生成ライフサイクルにフックする
Eclipse

プラグインはGradleが生成する

Eclipse

ファイルのセクションをモデリングしたドメインクラスを提供します。
生成ライフサイクルは次の通りです。
1. ファイルが読み込まれる。ファイルが存在しない場合は、Gradleがデフォルトの内容を用意する。
2. beforeMerged
フックが実行され、既存の設定内容を表すドメインオブジェクトがフックに引き渡される。
3. Gradleのビルド内容から推測される、またはEclipse
DSLで明示された設定内容と、既存の設定内容がマージされる。
4. whenMerged
フックが実行され、保存される予定の設定内容を表すドメインオブジェクトがフックに引き渡される。
5. withXmlフックが実行され、保存される予定の生XMLがフックに引き渡される。
6. 最終的なXMLが保存される。
以下は Eclipseモデルの型毎の利用ドメインオブジェクトの一覧表です。
表38.4 高度な構成フックモデル

beforeMerged { arg -> }whenMerged { arg -> }withXml { arg -

引数型

引数型

引数型

EclipseProject

Project

Project

XmlProvider

EclipseClasspath

Classpath

Classpath

XmlProvider

EclipseJdt

Jdt

Jdt

EclipseWtpComponent

WtpComponent

WtpComponent

XmlProvider

EclipseWtpFacet

WtpFacetWtpFacet

XmlProvider

38.4.2.1. 既存の内容の一部を上書きする
完全に上書き してしまうと既存の内容を全て破棄してしまいます。

で直接変更した内容が消されてしまいます。 beforeMerged

それにより

IDE

フックを使えば

既存の内容の一部だけを上書きすることができます。 次の例は 存在する全ての依存関係を classpath
ドメインオブジェクトから削除します。
例38.2 classpath の一部を上書き
build.gradle
eclipse.classpath.file {beforeMerged { classpath ->classpath.entries.removeAll { entry -> entry.kind == 'lib' || entry.kind == 'var' }}}この例で生成された.classpath

ファイルにはGradleによって生成された依存関係のエントリしか含みません。

元のファイルにあった他の依存関係のエントリは全く含みません。(依存関係のエントリの場合はこれがデフォルトのPage 219 of 436

.classpathファイルの他のセクションはそのまま残るかマージされるでしょう。

.project

ファイルの ネーチャーでも同様です。
例38.3 project の一部を上書き
build.gradle
eclipse.project.file.beforeMerged { project ->project.natures.clear()}

38.4.2.2. 完全に populate されたドメインオブジェクトを変更する
whenMergedフックは完全にデータが設定されたドメインオブジェクトを操作することができます。
これはEclipseのファイルをカスタマイズするのにはよい方法です。

以下はEclipseプロジェクトの全ての依存関係をエクスポートする方法です:
例38.5 依存関係のエクスポート
build.gradle
eclipse.classpath.file {whenMerged { classpath ->classpath.entries.findAll { entry -> entry.kind == 'lib' }*.exported = false}}

38.4.2.3. XML表現を変更する
withXmlフックはディスクに書き出される直前のメモリ内の XML 表現を操作することができます。
た だ 、 G r o o v y

の

X M L

サポートがいろいろと補ってくれたとしても、このアプローチはドメインオブジェクトを操作するほど便利ではありま

その代わりに、生成されたファイルを通して全ての操作が可能です。もちろん、ドメインオブジェクトにモデル化され例38.7 XML のカスタマイズCustomizing the XML
build.gradle
apply plugin: 'eclipse-wtp'
eclipse.wtp.facet.file.withXml { provider ->provider.asNode().fixed.find { it.@facet == 'jst.java' }.@facet = 'jst2.java'}

Page 220 of 436

39
IDEAプラグイン
IDEAプラグインは、IntelliJ IDEAが使用するファイルを生成し、プロジェクトをIDEA(File - Open
Project)で開けるようにします。
外部依存関係(関連するソースやjavadocファイルを含む)とプロジェクト依存関係についても考慮されています。
IDEAプラグインが実際に生成するものは、使用されているプラグインによって異なります。
表39.1 IDEAプラグインの振る舞い
プラグイン

説明

なし

IDEAモジュールファイルを生成する。プロジェクトがルートプロジェクトだった場合は、IDEAプロジ

Java

モジュールファイルとプロジェクトファイルに、Javaの設定を追加する。

IDEAプラグインで重視されているものの一つがカスタマイズ性です。生成するファイルに内容を追加したり削除したり

39.1. 使用方法
IDEAプラグインを使うには、ビルドスクリプトに次の行を追加します。
例39.1 IDEAプラグインを使う
build.gradle
apply plugin: 'idea'

IDEAプラグインは、プロジェクトにいくつかのタスクを追加します。主に使うものはideaタスクとcleanIdea
タスクでしょう。

39.2. タスク
IDEAプラグインはプロジェクトに以下のタスクを追加します。 cleanタスクがcleanIdeaWorkspace
タスクに依存していないことに注意してください。

ワークスペースにはユーザーごとの一時データが多く含まれており、一般的にはIDEAの外からは操作されたくないもの

Page 221 of 436

表39.2 IDEAプラグイン - タスク
タスク名

依存先

型

idea

ideaProject, ideaModule-

説明

全てのIDEA設定ファイルを生成, ideaWorkspacecleanIdea

cleanIdeaProject

DeleteIDEAの設定ファイルを全て削除, cleanIdeaModulecleanIdeaProject-

DeleteIDEAのプロジェクトファイルを

cleanIdeaModule-

DeleteIDEAのモジュールファイルを削

cleanIdeaWorkspace-

DeleteIDEAのワークスペースファイル

ideaProject-

GenerateIdeaProject.ipr

ファイルを生成する。このタス
ideaModule-

GenerateIdeaModule.imlファイルを作成する。

ideaWorkspace-

GenerateIdeaWorkspace.iws

ファイルを生成する。このタス

39.3. 設定
表39.3 IDEAプラグインの設定
モデル

参照名

説明

IdeaModel

idea

DSLフレンドリーな方法でIDEAプラグインの設定を行うための、最上位

IdeaProjectidea.project

プロジェクト情報の設定ができる

IdeaModule

idea.module

モジュールの設定ができる

IdeaWorkspaceidea.workspace

ワークスペースXMLの設定ができる

39.4. 生成するファイルのカスタマイズ
IDEAプラグインには、生成される内容をカスタマイズするためのフックと特徴があります。
なお、ワークスペースファイルは、対応するドメインオブジェクトが実質的に空なので、withXml
フックを使用しないと効果的に操作できません。
IDEAプラグインのタスクは、既存のIDEAファイルを検知し、生成された内容をそれにマージします。

39.4.1. マージ

既存のIDEAファイルのセクションのうち、生成される内容の対象になっているものは、セクションごとに修正、またはそれ以外のセクションはそのまま残されます。

Page 222 of 436

39.4.1.1. マージを無効にして、完全に上書きする

既存のIDEAファイルを完全に上書きするには、クリーンタスクを、対応する生成タスクと一緒に使用してください。例
gradleideaをこの順序で使用します。

cleanIdea

デフォルトでそのように動作させたいのであれば、tasks.idea.dependsOn(cleanIdea)というコードをビルドスクリプトに追加してください。明示的にクリーンタスクを実行する必要がなくなります。
この戦略はプラグインが生成する個々のファイルに対しても適用可能で、例えば“.iml”ファイルに対して" gradle cleanIdeaModule ideaModule"のようにできます。

39.4.2. 生成ライフサイクルへフックする
このプラグインでは、様々なオブジェクトにより生成されるメタデータファイルの各セクションを表現します。
メタデータファイルを生成する際のライフサイクルは次のとおりです。
1. ファイルが読み込まれる。ファイルが存在しない場合は、Gradleがデフォルトの内容を用意する。
2. beforeMerged
フックが実行され、既存の設定内容を表すドメインオブジェクトがフックに引き渡される。
3. Gradleのビルド内容から推測される、またはDSLで明示された設定内容と、既存の設定内容がマージされる。
4. whenMerged
フックが実行され、保存される予定の設定内容を表すドメインオブジェクトがフックに引き渡される。
5. withXmlフックが実行され、保存される予定の生XMLがフックに引き渡される。
6. 最終的なXMLが保存される。
各モデルで使われるドメインオブジェクトは、次の表の通りです。
表39.4 IDEAプラグインフック
モデル

beforeMerged { arg -> }whenMerged { arg -> }withXml { arg -> }

引数の型

引数の型

引数の型

IdeaProject

Project

Project

XmlProvider

IdeaModule

ModuleModuleXmlProvider

IdeaWorkspace

Workspace

Workspace

XmlProvider

39.4.2.1. 既存の内容を部分的に上書きする
完全な上書きは、既存の内容を全て破棄するので、IDEで直接行った変更も失われてしまいます。
beforeMergedフックを使うと、既存の内容のうち特定の部分だけを上書きすることができます。
次の例では、Moduleドメインオブジェクトから、既存の依存関係を全て削除しています。

Page 223 of 436

例39.2 モジュールの部分的な上書き
build.gradle
idea.module.iml {beforeMerged { module ->module.dependencies.clear()}}

結果として生成されるモジュールファイルには、Gradleが生成した依存関係のエントリのみが含まれており、元のファ
そして、モジュールファイルの別のセクションはそのまま、またはマージされた状態で残されます。
同じことはプロジェクトファイルのモジュールパスを使用しても実現可能です。
例39.3 プロジェクトの部分的な上書き
build.gradle
idea.project.ipr {beforeMerged { project ->project.modulePaths.clear()}}

39.4.2.2. 読み込まれた全ドメインオブジェクトを編集する
whenMergedフックを使うと、読み込まれた全てのドメインオブジェクトを操作できます。

IDEAファイルをカスタマイズするときは、多くの場合このフックを使うのが好ましい方法です。例えば、IDEAモジュ例39.4 Export Dependencies
build.gradle
idea.module.iml {whenMerged { module ->module.dependencies*.exported = true}}

39.4.2.3. XMLデータを編集する
w

i

t

h

X

m

l

フックを使うと、メモリ内のXMLデータを、ファイルに書き出される直前に操作できます。

GroovyのXMLサポートで大幅にフォローされるものの、このアプローチはドメインオブジェクトを操作する方法ほどその代わり、ドメインオブジェクトで表現されないような部分も含め、生成されるファイルの全てを制御することがで

Page 224 of 436

例39.5 XMLをカスタマイズする
build.gradle
idea.project.ipr {withXml { provider ->provider.node.component.find { it.@name == 'VcsDirectoryMappings' }.mapping.@vcs = 'Git'}}

39.5. その他の注意事項
生成されるIDEAファイルでは、依存関係が絶対パスで保存されます。

しかし、Gradleキャッシュを場所を参照するパス変数を定義すれば、IDEAは依存関係の絶対パスをそのパス変数で自そのようなパス変数を使いたい場合は、idea.pathVariables
を使って変数を設定してください。それにより、重複なしで正しくマージを行うこともできます。

Page 225 of 436

40
ANTLRプラグイン
ANTLRプラグインはJavaプラグインを拡張して、ANTLRを利用したパーサーの生成に対するサポートを追加します。

40.1. 使用方法
ANTLRプラグインを使うには、ビルドスクリプトに以下を含めます:
例40.1 ANTLRプラグインの利用
build.gradle
apply plugin: 'antlr'

40.2. タスク
ANTLRプラグインは以下に示すいくつかのタスクをプロジェクトに追加します。
表40.1 ANTLR plugin - タスク
タスク名

依存先

タイプ

説明

generateGrammarSource-

AntlrTask

すべてのプロダクションANTLRグラマーに対するソー

generateTestGrammarSource-

AntlrTask

すべてのテストANTLRグラマーに対するソースファイ

AntlrTask

指定されたソースセットですべてのANTLRグラマーに

generateSourceSetGrammarSource-

ANTLRプラグインはJavaプラグインによって追加されたタスクに以下の依存関係を追加します。
表40.2 ANTLR plugin - 追加のタスク依存関係
タスク名

依存先

compileJava

generateGrammarSourcecompileTestJava

generateTestGrammarSourcecompileSourceSetJava

generateSourceSetGrammarSource

Page 226 of 436

40.3. プロジェクトレイアウト
表40.3 ANTLRプラグイン - プロジェクトレイアウト
ディレクトリ意味

src/main/antlr

プロダクションANTLRグラマーファイル

src/test/antlr

テストANTLRグラマーファイル

src/sourceSet/antlr

指定されたソースセットに対するANTLRグラマーファイル

40.4. 依存関係管理
ANTLRプラグインは依存性コンフィグレーション antlr を追加します。
これは利用したいANTLRのバージョンを宣言するのに使えます。
例40.2 ANTLRバージョン宣言
build.gradle
repositories {mavenCentral()}dependencies {
antlr 'antlr:antlr:2.7.7'}

40.5. 規約プロパティ
ANTLRプラグインはいかなる規約プロパティも追加しません。

40.6. ソースセットプロパティ
ANTLRプラグインはプロジェクトのソースセット毎に以下のプロパティを追加します。
表40.4 ANTLRプラグイン - ソースセットプロパティ
プロパティ名タイプ

デフォルト値

説明

antlr

SourceDirectorySet (read-only)

Not null

このソースセットのANTLRグラマ

ANTLRソースディレクトリにあるを含み、それ以外のタイプのファ
antlr.srcDirs

Set<File>。

[projectDir/src/
このソースセットのANTLRグラマ
name/antlr]「入力ファイルセットを指定する 」
で説明した任意のパターンが設定可能。

Page 227 of 436

41
プロジェクトレポートプラグイン

プロジェクトレポートプラグインは、ビルドに関する有益な情報を含むレポートを生成するタスクをプロジェクトに追これらのタスクは、gradle

tasks、gradle

dependencies およびgradle

propertiesによるコマンドラインレポートとまったく同じ内容を生成します(「ビルドに関する情報を取得する」を参照)。
コマンドラインレポートとは対照的に、レポートプラグインはレポートをファイルに出力します。
プラグインによって追加されたすべてのレポートタスクに依存する集約タスクもあります。
Gradleの将来のリリースではもっと多くの情報をレポートに追加する予定です。

41.1. 使用法
プロジェクトレポートプラグインを使うには、ビルドスクリプトに以下を含めます:

apply plugin: 'project-report'

41.2. タスク
プロジェクトレポートプラグインは以下のタスクを定義しています:
表41.1 プロジェクトレポートプラグイン - タスク
タスク名

依存先

タイプ

説明

dependencyReport-

DependencyReportTask

プロジェクト依存関

htmlDependencyReport-

HtmlDependencyReportTask

Generates an HTM

dependency insig
set of projects.
propertyReport-

PropertyReportTask

プロジェクトプロパ

taskReport-

TaskReportTask

プロジェクトタスク

projectReport

dependencyReport, propertyReport
Task

すべてのプロジェク, taskReport, htmlDependencyReport

Page 228 of 436

41.3. プロジェクトレイアウト
プロジェクトレポートプラグインは特定のプロジェクトレイアウトを要求しません。

41.4. 依存関係
プロジェクトレポートプラグインはいかなる依存関係コンフィグレーションも定義しません。

41.5. 規約プロパティ
プロジェクトレポートプラグインは以下の規約プロパティを定義します:表41.2 プロジェクトレポートプラグイン - 規約プロパティ
プロパティ名タイプ

デフォルト値

説明

reportsDirName

Stringreports

レポートを生成するディレクトリ名

reportsDir

FilebuildDir/reportsDirNameレポートを生成するディレクトリ

(read-only)
projects

Set<Project>

1Set

レポート生成対象のプロジェクト

projectReportDirName

Stringproject

プロジェクトレポート生成先ディレ

projectReportDir

FilereportsDir/projectReportDirName
プロジェクトレポート生成先ディレ(read-only)

規約プロパティはProjectReportsPluginConvention

型の規約オブジェクトによって提供されます。

Page 229 of 436

42
通知プラグイン

通知プラグインを使うと、ビルド実行中に通知を送信することができます。以下の通知システムがサポートされていまTwitter
notify-send (Ubuntu)
Snarl (Windows)
Growl (Mac OS X)

42.1. 使用方法
通知プラグインを使うには、まずビルドスクリプトにプラグインを適用してください。
Example 42.1. 通知プラグインを使用する
build.gradle
apply plugin: 'announce'

次に、選んだ通知方法に応じて設定を行います。設定用のプロパティについては、以下のテーブルを参照してください
Example 42.2. 通知プラグインの設定
build.gradle
announce {username = 'myId'
password = 'myPassword'}

最後に、announceメソッドで通知を送信します。

Page 230 of 436

Example 42.3. 通知プラグインを使用する
build.gradle
task helloWorld << {println "Hello, world!"}
helloWorld.doLast {announce.announce("helloWorld completed!", "twitter")announce.announce("helloWorld completed!", "local")
}

a

n

n

o

u

n

c

e

メソッドは二つの引数を取ります。一つは通知メッセージで、もう一つは使用する通知用サービスです。
サポートされている通知用サービスとその設定値は以下の通りです。
Table 42.1. 通知プラグイン対応サービス
通知サービス

オペレーティングシステム

設定プロパティ

twitter

何でもusername,

備考

passwordsnarlWindows

growl

Mac OS X

notify-send

Ubuntunotify-sendパッケージをインストールする必要がを実行してインストールしてください。

local

Windows, Mac OS X,

snarl、growl、notify-sendの中から、オペレーテ

Ubuntu42.2. 設定
AnnouncePluginExtensionを参照してください。

Page 231 of 436

43
ビルド通知プラグイン
ビルド通知プラグインはまだ試験的なプラグインです。DSLやその他設定が後のバージョンで変更される可能性もありますので注意してください。

ビ ル ド 通 知 プ ラ グ イ ン は 、 通 知
プラグインを使って、ビルドで重要なイベントが発生したときにローカル上で通知します。

43.1. 使用方法
ビルド通知プラグインを使うには、ビルドスクリプトに以下を含めます:
例43.1 ビルド通知プラグインの利用
build.gradle
apply plugin: 'build-announcements'

通 知 先 を 調 整 し た い 場 合 は 、 通 知
プラグインのコンフィグレーションでローカル通知機能を切り替えられます。
また、初期化スクリプトを使ってプラグインを適用することもできます:
例43.2 初期化スクリプトからビルド通知プラグインを使う
init.gradle
rootProject {apply plugin: 'build-announcements'}

Page 232 of 436

44
The Distribution Plugin
The distribution plugin is currently incubating. Please be aware that the DSL and otherconfiguration may change in later Gradle versions.

The distribution plugin facilitates building archives that serve as distributions of the project.
Distribution archives typically contain the executable application and other supporting files,
such as documentation.

44.1. Usage
To use the distribution plugin, include the following in your build script:
Example 44.1. Using the distribution pluginbuild.gradle
apply plugin: 'distribution'

The plugin adds an extension named “distributions” of type DistributionContainer tothe project. It also creates a single distribution in the distributions container extension named “main”. If your build only produces one distribution you only need to configure this distribution (oruse the defaults).
You can run “gradle distZip” to package the main distribution as a ZIP, or “gradle distTar” to create a TAR file. The files will be created at “ $buildDir /distributions/ $project.name - $project.
”.

You can run “gradle installDist” to assemble the uncompressed distribution into “ $buildDir /instal”.

44.2. Tasks
The Distribution plugin adds the following tasks to the project:

Page 233 of 436

Table 44.1. Distribution plugin - tasks
Task name

Depends

Type

Description

on
distZip-

Zip

Creates a ZIP archive of the distribution contents

distTar-

Tar

Creates a TAR archive of the distribution contents

installDist

-

Sync

Assembles the distribution content and installs it on
the current machine

For each extra distribution set you add to the project, the distribution plugin adds the following
tasks:
Table 44.2. Multiple distributions - tasks
Task name

Depends

Type

Description

Zip

Creates a ZIP archive ofon${distribution.name}DistZip-

the distribution contents${distribution.name}DistTar-

Tar

Creates a TAR archive ofthe distribution contents

install${distribution.name.capitalize()}
Dist Sync

Assembles the
distribution content andinstalls it on the current
machineExample 44.2. Adding extra distributions
build.gradle
apply plugin: 'distribution'version = '1.2'
distributions {custom {}}This will add following tasks to the project:customDistZip
customDistTar
installCustomDist
Given that the project name is “myproject” and version “1.2”, running “gradle customDistZip” will produce a ZIP file named “myproject-custom-1.2.zip”.

Running “gradle installCustomDist” will install the distribution contents into “ $buildDir /install/cu”.

Page 234 of 436

44.3. Distribution contents
All of the files in the “src/ $distribution.name /dist” directory will automatically be
included in the distribution. You can add additional files by configuring the Distribution
object that is part of the container.
Example 44.3. Configuring the main distribution
build.gradle
apply plugin: 'distribution'
distributions {main {
baseName = 'someName'contents {from { 'src/readme' }}}}In the example above, the content of the “ src/readme” directory will be included in the
distribution (along with the files in the “src/dist/main” directory which are added bydefault).
The “baseName” property has also been changed. This will cause the distribution archives tobe created with a different name.

Page 235 of 436

45
アプリケーション プラグイン
G r a d l e

ア プ リ ケ ー シ ョ ン

プラグインは言語プラグインを一般的なアプリケーションの関連タスクで拡張しています。

JVM

用アプリケーションの実行 及び ビルドが可能です。

45.1. 使用方法
アプリケーション プラグインを使うためには、ビルドスクリプトに下記を含めます：
例45.1 Using the application pluginbuild.gradle
apply plugin:'application'

アプリケーションのメインクラスを定義するには、次のように

mainClassName

プロパティを設定するだけでよいです。
例45.2 Configure the application main classbuild.gradle
mainClassName = "org.gradle.sample.Main"

あとは gradle run を実行するだけで、アプリケーションを実行することができます。 Gradle は
アプリケーションクラスのビルドから実行時の依存解決、

適切なクラスパスでのアプリケーションの起動まで全て面倒みてくれます。
このプラグインではアプリケーション用のディストリビューションをビルドすることもできます。
ディストリビューションにはOS

依存の起動スクリプトと一緒に

アプリケーションの実行時の依存ライブラリもパッケージングされます。 gradle install で build/install/p
配下に

アプリケーションイメージを生成することができます。

gradledistZipでディストリビューションを含む ZIP ファイルを生成することができます。
If your Java application requires a specific set of JVM settings or system properties, you canconfigure the applicationDefaultJvmArgs property. These JVM arguments are applied to therun task and also considered in the generated start scripts of your distribution.

Page 236 of 436

例45.3 Configure default JVM settingsbuild.gradle
applicationDefaultJvmArgs = ["-Dgreeting.language=en"]

45.2. タスク
アプリケーション プラグインは 次のタスクをプロジェクトに追加します。
表45.1 アプリケーション プラグイン - タスク
タスク名

依存先

型

説明

run

classes

JavaExec

アプリケーションを起動します。

startScripts

jarCreateStartScripts

プロジェクトを JVM アプリケーションとして実installApp

jar, startScripts
Sync

指定したディレクトリ配下にアプリケーションを

distZip

jar, startScripts
Zip

実行ライブラリと OS 依存スクリプトを含んだ 完
アーカイブを生成します。

distTarjar, startScripts
Tar

実行ライブラリとOS依存スクリプトを含んだ完全

45.3. 規約プロパティ
ア プ リ ケ ー シ ョ ン

プ ラ グ イ ン は

いくつかのプロパティをプロジェクトに追加します。そのプロパティを設定すれば挙動が変えられます。詳しくはProject を参照してください。

45.4.
ディストリビューションに他のリソースを含める
このプラグインは、 applicationDistribution という CopySpec
型の規約プロパティを追加します。

これは、 installApp タスクと distZip

タスクにより何がディストリビューションに含められるのか、その仕様を定義したものです。
実行用スクリプトをディストリビューションの bin ディレクトリに、必要なjarを libにコピーするほか、 src/dist ディレクトリにある全てのファイルをコピーします。
何らかの静的ファイルをディストリビューションに含めたい場合は、単にsrc/dist
ディレクトリにそれらのファイルを置くだけで大丈夫です。

あるプロジェクトが、ディストリビューションに含めるファイル(例えばドキュメントなど)を生成する、といったケー
そのような場合、applicationDistribution
コピー仕様を追加することで、ファイルをディストリビューションに追加することができます。

Page 237 of 436

例45.4 他タスクの出力をアプリケーションのディストリビューションに含める
build.gradle
task createDocs {def docs = file("$buildDir/docs")
outputs.dir docs
doLast {docs.mkdirs()
new File(docs, "readme.txt").write("Read me!")}}applicationDistribution.from(createDocs) {into "docs"}

ディストリビューションにタスクの出力(「タスクの入力物と出力物を宣言する」
参照)を格納するように指定すると、Gradleは、ディストリビューションを作成する前にそのタスクを実行しなければならないのだと判断し、その作業を引例45.5 ディストリビューションのファイルを自動的に作成する
gradle distZip の出力> gradle distZip:createDocs:compileJava:processResources UP-TO-DATE:classes:jar:startScripts:distZip
BUILD SUCCESSFUL
Total time: 1 secs

Page 238 of 436

46
The Java Library Distribution Plugin
The Java library distribution plugin is currently incubating. Please be aware that the DSL
and other configuration may change in later Gradle versions.

The Java library distribution plugin adds support for building a distribution ZIP for a Java library.
The distribution contains the JAR file for the library and its dependencies.

46.1. Usage
To use the Java library distribution plugin, include the following in your build script:
Example 46.1. Using the Java library distribution pluginbuild.gradle
apply plugin: 'java-library-distribution'

To define the name for the distribution you have to set the baseName property as shown below:
Example 46.2. Configure the distribution namebuild.gradle
distributions {main{baseName = 'my-name'}}

The plugin builds a distribution for your library. The distribution will package up the runtime
dependencies of the library. All files stored in src/main/dist will be added to the root of thearchive distribution. You can run “gradle distZip” to create a ZIP file containing the
distribution.

46.2. Tasks
The Java library distribution plugin adds the following tasks to the project.

Page 239 of 436

Table 46.1. Java library distribution plugin - tasks
Task

Depends

nameondistZip

jar

Type

Description

Zip

Creates a full distribution ZIP archive including runtime
libraries.

46.3. Including other resources in the
distribution
All of the files from the src/dist directory are copied. To include any static files in the
distribution, simply arrange them in the src/dist directory, or add them to the content of the
distribution.
Example 46.3. Include files in the distribution
build.gradle
distributions {main {
baseName = 'my-name'contents {from { 'src/dist' }}}}Page 240 of 436

47
Build Init Plugin
The Build Init plugin is currently incubating. Please be aware that the DSL and otherconfiguration may change in later Gradle versions.

The Gradle Build Init plugin can be used to bootstrap the process of creating a new Gradle build.
It supports creating brand new projects of different types as well as converting existing builds(e.g. An Apache Maven build) to be Gradle builds.
Gradle plugins typically need to be applied to a project before they can be used (see「プラグインの適用 」). The Build Init plugin is an automatically applied plugin, which means
you do not need to apply it explicitly. To use the plugin, simply execute the task named init
where you would like to create the Gradle build. There is no need to create a “stub” build.gradle
file in order to apply the plugin.
It also leverages the wrapper task from the Wrapper plugin (see Chapter 48, Wrapper Plugin),which means that the Gradle Wrapper will also be installed into the project.

47.1. Tasks
The plugin adds the following tasks to the project:
Table 47.1. Build Init plugin - tasks
Task name

Depends on

Type

Description

initwrapper

InitBuild

Generates a Gradle project.

wrapper-

Wrapper

Generates Gradle wrapper files.

47.2. What to set up
The init supports different build setup types . The type is specified by supplying a --typeargument value. For example, to create a Java library project simply execute: gradle init --type java-libr.
If a --type parameter is not supplied, Gradle will attempt to infer the type from theenvironment. For example, it will infer a type value of “ pom” if it finds a pom.xml to convert toPage 241 of 436

a Gradle build.
If the type could not be inferred, the type “basic” will be used.
All build setup types include the setup of the Gradle Wrapper.

47.3. Build init types
As this plugin is currently incubating, only a few build init types are currently supported.
More types will be added in future Gradle releases.

47.3.1. “pom” (Maven conversion)
The “pom” type can be used to convert an Apache Maven build to a Gradle build. This works
by converting the POM to one or more Gradle files. It is only able to be used if there is a valid “pom.xml” file in the directory that the init task is invoked in. This type will be automatically inferred if
such a file exists.
The Maven conversion implementation was inspired by the maven2gradle tool that was
originally developed by Gradle community members.
The conversion process has the following features:
Uses effective POM and effective settings (support for POM inheritance, dependency
management, properties)
Supports both single module and multimodule projects
Supports custom module names (that differ from directory names)
Generates general metadata - id, description and version
Applies maven, java and war plugins (as needed)
Supports packaging war projects as jars if needed
Generates dependencies (both external and inter-module)
Generates download repositories (inc. local Maven repository)
Adjusts Java compiler settings
Supports packaging of sources and tests
Supports TestNG runner
Generates global exclusions from Maven enforcer plugin settings

47.3.2. “java-library”
The “java-library” build init type is not inferable. It must be explicitly specified.
It has the following features:
Uses the “java” plugin
Uses the “mavenCentral” dependency repository
Uses JUnit for testingHas directories in the conventional locations for source code

Page 242 of 436

Contains a sample class and unit test, if there are no existing source or test files

47.3.3. “scala-library”
The “scala-library” build init type is not inferable. It must be explicitly specified.
It has the following features:
Uses the “scala” plugin
Uses the “mavenCentral” dependency repository
Uses Scala 2.10
Uses ScalaTest for testingHas directories in the conventional locations for source code
Contains a sample scala class and an associated ScalaTest test suite, if there are no existingsource or test files

47.3.4. “groovy-library”
The “groovy-library” build init type is not inferable. It must be explicitly specified.
It has the following features:
Uses the “groovy” plugin
Uses the “mavenCentral” dependency repository
Uses Groovy 2.x
Uses Spock testing framework for testingHas directories in the conventional locations for source code
Contains a sample Groovy class and an associated Spock specification, if there are no
existing source or test files

47.3.5. “basic”
The “basic” build init type is useful for creating a fresh new Gradle project. It creates asample build.gradle file, with comments and links to help get started.
This type is used when no type was explicitly specified, and no type could be inferred.

Page 243 of 436

48
Wrapper Plugin
The wrapper plugin is currently incubating. Please be aware that the DSL and otherconfiguration may change in later Gradle versions.

The Gradle wrapper plugin allows the generation of Gradle wrapper files by adding a Wrapper
task, that generates all files needed to run the build using the Gradle Wrapper. Details about theGradle Wrapper can be found in 62章Gradleラッパー .

48.1. Usage
Without modifying the build.gradle file, the wrapper plugin can be auto-applied to the root
project of the current build by running “ gradle wrapper” from the command line. Thisapplies the plugin if no task named wrapper is already defined in the build.

48.2. Tasks
The wrapper plugin adds the following tasks to the project:
Table 48.1. Wrapper plugin - tasks
Task name

Depends on

Type

Description

wrapper-

Wrapper

Generates Gradle wrapper files.

Page 244 of 436

49
The Build Dashboard Plugin
The build dashboard plugin is currently incubating. Please be aware that the DSL and otherconfiguration may change in later Gradle versions.

The Build Dashboard plugin can be used to generate a single HTML dashboard that provides asingle point of access to all of the reports generated by a build.

49.1. Usage
To use the Build Dashboard plugin, include the following in your build script:
Example 49.1. Using the Build Dashboard pluginbuild.gradle
apply plugin: 'build-dashboard'

Applying the plugin adds the buildDashboard task to your project. The task aggregates thereports for all tasks that implement the Reporting interface from all projects in the build. It is
typically only applied to the root project.
The buildDashboard task does not depend on any other tasks. It will only aggregate thereporting tasks that are independently being executed as part of the build run. To generate thebuild dashboard, simply include this task in the list of tasks to execute. For example, “gradle buildDashboar” will generate a dashboard for all of the reporting tasks that are dependents of the build task.

49.2. Tasks
The Build Dashboard plugin adds the following task to the project:
Table 49.1. Build Dashboard plugin - tasks
Task name

Depends

Type

Description

GenerateBuildDashboard

Generates build

onbuildDashboard-

dashboard report.

Page 245 of 436

49.3. Project layout
The Build Dashboard plugin does not require any particular project layout.

49.4. Dependency management
The Build Dashboard plugin does not define any dependency configurations.

49.5. Configuration
You can influence the location of build dashboard plugin generation via ReportingExtension.

Page 246 of 436

50
The Java Gradle Plugin Development
PluginThe Java Gradle plugin development plugin is currently incubating. Please be aware thatthe DSL and other configuration may change in later Gradle versions.

The Java Gradle Plugin development plugin can be used to assist in the development of Gradleplugins. It automatically applies the Java plugin, adds the gradleApi() dependency to thecompile configuration and performs validation of plugin metadata during jar task execution.

50.1. Usage
To use the Java Gradle Plugin Development plugin, include the following in your build script:
Example 50.1. Using the Java Gradle Plugin Development pluginbuild.gradle
apply plugin: 'java-gradle-plugin'

Applying the plugin automatically applies the Java plugin and adds the gradleApi()
dependency to the compile configuration. It also decorates the jar task with validations.
The following validations are performed:
There is a plugin descriptor defined for the plugin.
The plugin descriptor contains an implementation-class property.
The implementation-class property references a valid class file in the jar.
Any failed validations will result in a warning message.

Page 247 of 436

51
依存関係の管理51.1. はじめに依存関係の管理は、あらゆるビルドで決定的に重要になる機能です。Gradleも、理解しやすく、既存の様々な管理方法

Gradleの管理機能はとても柔軟でカスタマイズ性の高いものですが、MavenやIvyでの管理に慣れ親しんできたなら、
Gradleの依存関係管理機能で特筆すべき点を挙げると、
推 移 的 な 依 存 関 係 の 管 理 :Gradleは、プロジェクトの依存関係ツリー全体を完全にコントロールできます。
未 管 理 の 依 存 関 係 も サ ポ ー ト :プロジェクトの依存ファイルを単純にバージョン管理システムや共有ドライブに格納したい場合も、Gradleはそれ依存関係定義のカスタマイズをサポート:
Gradleでは、依存関係の階層構造をビルドスクリプトで直接定義できます。
非常にカスタマイズ性の高い依存関係の解決方法 :Gradleでは依存関係を解決する際のルールをカスタマイズでき、簡単に依存関係を差し替えることができます。
Maven、Ivyとの完全な互換性 :既にMavenのPOMやIvyファイルで依存関係を定義しているかもしれません。Gradleは人気のある様々なビルドツ
既存の依存関係管理インフラとの連携:

Gradleは、Maven、Ivyどちらの形式のリポジトリとも互換性があります。既にArchivaやNexus、Artifactoryなどを現在無数に存在するオープンソースライブラリは、それぞれ互いに依存し合っていて、さらにバージョンや互換性の有51.1.1. ビルドツール移行に必要な依存関係管理の柔軟性
依存関係の管理で特に問題が発生しやすいのは、あるビルドシステムから別のビルドシステムへ移行するときです。
AntやMavenからGradleへ移行する際には、難しい問題に突き当たることがあるかもしれません。

例えば、よくあるAntプロジェクトですが、バージョンのないjarファイルがファイルシステムに置かれていたりするこ

一方Gradleでは、依存関係をどこから、どんなメタデータで取得していたとしても、新しいビルドでそれを変更する必
プロジェクトが独自の方法で依存関係を管理していたとしても、例え依存関係のマスターデータにEclipseの.classpathを使っているようなプロジェクトであったとしても、Gradleでそのデータを使うためのプラグイ

51.1.2. Javaにおける依存関係管理

Javaはその豊富なオープンソースライブラリで知られる言語ですが、皮肉なことにライブラリやバージョンといった概Javaでは、JVMに、今使っているものがHibernateのバージョン3.0.5であると伝える標準的な方法はありませんし、
foo-1.0.jarがbar-2.0.jarに依存していると伝える方法も標準では存在しないのです。

このため、これを実現するための様々なソリューションがサードパーティにより考案されてきました。また、ビルドツ

Page 248 of 436

どちらのツールも、ある特定のjarファイルについて、その依存関係の情報をXML形式のディスクリプタに定義して使用

どちらも依存関係を解決するための標準的な方法となっており、Gradleも最初は依存関係管理機能の水面下でIvyを使

Gradleは、今ではそのように直接Ivyに依存するのではなく、Gradle独自の依存関係解決エンジンを使用しています。

51.2. 依存関係管理のベストプラクティス

Gradleは依存関係の管理についてとても強固な指針を持ってはいますが、ユーザーには二つのオプションを提示していこ の 節 で は 、 G r a d l e
Projectが推奨する依存関係管理のベストプラクティスについて概要を記載します。
開発言語にかかわらず、依存関係を正しく管理することはあらゆるプロジェクトで大事なファクターです。

数百ものオープンソースライブラリに依存した複雑なエンタープライズJavaアプリケーションから、わずかなライブラ

例えば、再配布して使用されることを想定したライブラリプロジェクトの場合、巨大なソフトウェアやインフラのシス
Projectでは全てのプロジェクトで以下の指針に従うことを推奨しています。

51.2.1. ファイル名にバージョン番号を含める(jarのバージョニング)ライブラリのバージョンはファイル名で簡単に分かるようになっていなければなりません。jarのバージョンは、たいてもし、20個のjarファイルがズラッと並べられて、これを見てほしいと言われたら、どちらがいいと思いますか？

つ

commons-beanutils-1.3.jar のようなファイル群と、 spring.jarのようなファイル群と、どちらの方がわかりやすいと思いますか？

ファイル名にバージョン番号が付いていれば、プロジェクトが依存しているjarのバージョンを簡単に、迅速に特定でき不明瞭なバージョンは、発見するのが非常に難しい、微妙なバグに繋がります。

例えば、Hibernate2.5を使っているプロジェクトがあるとしましょう。Hibernate3.0.5にアップグレードして、致命的数週間後、インテグレーションサーバーで例外が発生します。しかし他のマシンでは再現しません。結果、Hibernate

jarのファイル名にバージョン付けすることは、プロジェクトの表現性を高め、メンテナンスを簡単にします。また、潜51.2.2. 推移的な依存関係の管理

推移的な依存関係の管理とは、プロジェクトがあるライブラリに依存しているとき、その依存ライブラリがさらに別の

このように推移的な依存関係が再帰的に発生すると、プロジェクトが直接依存する第一層の依存、それが依存する第二

階層的にモデリングされていない依存関係は、構造化されないまま複雑にふくれあがり、簡単に制御を失ってしまうで

Gradle自身のことを考えてみても、Gradleプロジェクト自体は直接の、つまり第一層の依存関係はそう多くはありませさらに規模が大きくなれば、例えばSpring、Hibernate、その他のライブラリを使うエンタープライズプロジェクトとこのように依存関係ツリーが巨大になってくると、それを修正する際、バージョンの競合が発生しやすくなり、その解

例えば、あるバージョンのロギングライブラリを必要としているオープンソースライブラリがあるとしましょう。このこれらの問題を、手で何とかしようと頑張ることはできるかもしれませんが、すぐにそうした方法には拡張性がないこ

例えば、第一層、直接の依存関係を取り除きたいとなったとき、関連する他のjarも削除して良いものかどうか、分から削除しようとする依存関係の依存ライブラリだと思っていたjarが、それ自身第一層の依存関係に含まれているかもしれ自分で、手で推移的な依存関係を管理しようとすれば、その行き着く先は壊れやすく脆いビルドです。

思い切ってそのプロジェクトの依存関係を変更しようなどという人はどこにもいません。ビルドを壊してしまうリスク

プロジェクトのクラスパスはいつか完全にめちゃくちゃになって、ひとたびそのクラスパスで問題が発生すれば地獄のノート:
Page 249 of 436

あるプロジェクトで、私たちはミステリーに遭遇しました。クラスパスにあるLDAP関連のjarなのですが、このjarを

この謎のjarは、推移的な、第四層の依存関係に当たるものでした。推移的な依存関係を管理してやろうという人がGradleは、直接の依存関係および推移的な依存関係を表現するための手段を複数用意しています。複数のアプローチを

51.2.3. バージョン競合の解決

同じjar間でバージョンの競合が検出された場合、それを解決するか、エラーを発生させなければなりません。ここでもたくさんの開発者が依存関係を変更しているような巨大プロジェクトの場合、依存関係の順序がビルドの成否(またはもしクラスパスのバージョンが競合するという不幸に苦しんだことがないようでしたら、あなたを待ち受ける愉快な逸

30のサブモジュールからなるある巨大なプロジェクトがありました。ここにあるサブモジュールに依存関係を追加した

ビルドはまだ正常に動き続けているのに、開発者たちは無数の驚くような、というか驚くくらいひどいバグをプロダク

さらに悪いことに、この意図しないSpringのダウングレードはいくつかのセキュリティ的な脆弱性をシステムに招き、要するに、バージョンの競合は悪いことなので、それを避けるために推移的な依存関係は管理しなければならないのでまた、競合したバージョンが組織全体で何処で使われているのか調べ、一つのバージョンに統一したいという場合につもしバージョン競合など自分には起こるわけがないと思っているようでしたら、どうかもう一度考え直してみてくださ

第一層の依存関係が、更に別のライブラリに依存していて、それが他の依存関係とバージョンが競合しているというの
また、JVMには同じjarの違うバージョンをクラスパスで共存させられるような簡単な方法がありません(「Javaにおける依存関係管理 」参照)。
Gradleでは、バージョン競合を解決するための戦略として以下のものを用意しています。
Newest:

もっとも新しいバージョンの依存関係を使用します。これはGradleのデフォルトの戦略で、バージョン間で上位互
Fail:バージョンが競合した場合、ビルドを失敗させます。この戦略は、ビルドスクリプトで全てのバージョン競合をユ
特定のバージョンを明示的に選択する方法についてはResolutionStrategy
を参照してください。

上記の戦略で大抵の場合はほとんどの競合を解決できますが、Gradleはさらに微調整を行うためのメカニズムを備えて
プロジェクトが直接依存する第一層の依存関係を forced として強制できます。
これは、競合した依存関係が第一層の依存関係だったときに便利なアプローチです。
例についてはDependencyHandlerを参照してください。
依存関係は、第一層のものか推移的なものかにかかわらずとにかくforcedとして強制することもできます。
これは、推移的な依存関係で競合が発生してしまったときに便利なアプローチです。
また、第一層の依存関係も、前述の方法でなくこちらの方法で強制させることもできます。
例についてはResolutionStrategyを参照してください。
依存関係解決ルールというGradle1.4で導入された試験的な機能があり、特定の依存関係において選択されるバージョンを細かく調整することができます。

バージョン競合により発生する様々な問題に対応するときには、依存関係グラフを表示するレポートも非常に有用です

Page 250 of 436

51.2.4. 動的バージョンと変更性モジュールを使う

あるモジュールについて、常に最新版を使いたい、またはある範囲においての最新版を使いたいといった場面がよくあ

例えば、開発作業中や、ある範囲のバージョンのライブラリと協調して動作するよう設計されたライブラリを開発してこの種の、絶えず変更されるような依存関係は、 動的バージョン
を使うと簡単に参照することができます。 動的バージョンは、バージョンの範囲で指定すること(2.+など)も、使用できる最新版を表すプレースホルダで指定すること(latest.integrationなど)もできます。

また、要求しているモジュールのバージョンそのものは変わらないのに、中身だけが変更されていく場合もあります。
変更性モジュール の典型的な例は、MavenのSNAPSHOT
モジュールです。このモジュールは、公開された最新のモジュールを常にポイントし続けます。

言い換えれば、標準的なMavenのスナップショットは静的な状態にとどまっているものではありません。それがつまり動的バージョンと 変更性モジュール の主な違いは、モジュール名に付加されるバージョンです。
動的バージョン が静的な、実際のバージョンに変換されて付加されるのに対し、 変更性モジュールは要求したバージョン名がそのまま付加されます。その上で、モジュールの中身が時間が経つにつれて変わっていくの

デフォルトでは、Gradleは動的バージョンと変更性モジュールのキャッシュを24時間保持します。デフォルトに使用
コマンドラインオプションで変更できます。

また、ビルド時の実際のキャッシュの有効期限はを使って設定できます(「依存関係キャッシュ制御の微調整 」参照)。

51.3. 依存関係のコンフィギュレーション

Gradleでは、依存関係は「コンフィギュレーション」によりグループ化されます。コンフィギュレーションは名前(naGradleプラグインの多くが、独自のコンフィグレーションを事前に定義してプロジェクトに追加します。

たとえば、Javaプラグインは、いくつかのコンフィグレーションをプロジェクトに追加して、必要とされる様々なクラ「依存関係の管理」をご参照ください。

もちろん、定義済みのものだけでなく、自分でコンフィギュレーションを定義して追加することも可能です。このようプロジェクトのコンフィギュレーションはconfigurations

オブジェクトで管理されています。このオブジェクトに渡したクロージャは、configurationsのAPIに対して適用されまAPIの詳細についてはConfigurationContainerをご参照ください。
コンフィギュレーションを定義するには、
例51.1 コンフィギュレーションの定義
build.gradle
configurations {compile}コンフィギュレーションにアクセスするには、

Page 251 of 436

例51.2 コンフィギュレーションへのアクセス
build.gradle
println configurations.compile.nameprintln configurations['compile'].name

コンフィギュレーションの設定を変更するには、
例51.3 コンフィギュレーションの設定変更
build.gradle
configurations {compile {description = 'compile classpath'transitive = true}
runtime {extendsFrom compile}}
configurations.compile {description = 'compile classpath'}

51.4. 依存関係の定義方法
定義できる依存関係にはいくつかの種類があります。
表51.1 依存関係の種類
種類

説明

外部モジュール依存関係

どこかのリポジトリにある外部モジュールへの依存関係

プロジェクト依存関係

同じビルドに含まれる別プロジェクトへの依存関係

ファイル依存関係

ローカルファイルシステム上のファイル群への依存関係

クライアントモジュール依存関係

どこかのリポジトリにあるアーティファクトへ依存しているが、そのモジュー

Gradle APIへの依存関係

現在使用しているバージョンのGradleが持つAPIへの依存関係。Gradleのカスタ

ローカルGroovy依存関係

現在使用中のGradleで使われているGroovyへの依存関係。これもGradleのカス

51.4.1. 外部モジュール依存関係

外部モジュール依存関係は、もっともポピュラーな種類の依存関係です。このタイプの依存関係は、外部リポジトリに

Page 252 of 436

例51.4 モジュール依存関係
build.gradle
dependencies {runtime group: 'org.springframework', name: 'spring-core', version: '2.5'
runtime 'org.springframework:spring-core:2.5','org.springframework:spring-aop:2.5'
runtime([group: 'org.springframework', name: 'spring-core', version: '2.5'],[group: 'org.springframework', name: 'spring-aop', version: '2.5'])
runtime('org.hibernate:hibernate:3.0.5') {transitive = true}
runtime group: 'org.hibernate', name: 'hibernate', version: '3.0.5', transitive: true
runtime(group: 'org.hibernate', name: 'hibernate', version: '3.0.5') {transitive = true}}

より多くの例と完全なリファレンスはDependencyHandlerを参照してください。

Gradleはモジュール依存関係を定義するために二つの記法を用意しています。文字列記法とマップ記法です。モジュー
ExternalModuleDependencyも併せてご覧ください。

このAPIはプロパティとメソッドを公開しており、文字列記法ではプロパティのうち一部を指定することができます。

マップ記法を使うと全てのプロパティにアクセスできます。全てのAPIにアクセスするには、文字列記法、マップ記法
モジュール依存関係が宣言されていると、Gradleは対応するモジュールディスクリプタファイル(pom.xml
ま た は i v y . x m l)をリポジトリに探しに行きます。結果、ディスクリプタファイルが見つかった場合は、それをパースし、指定されてhibernate-3.0.5.jarなど)および推移的依存関係(cglibなど)をダウンロードします。
ディスクリプタファイルが見つからなければ、Gradleは今度はhibernate-3.0.5.jarという名前のファイルを探して取得しようとします。

Mavenのモジュールは、アーティファクトを一つしか持つことができません。GradleとIvyは一つのモジュールが複数

51.4.1.1. 複数のアーティファクトを持つモジュールへの依存関係

前述のように、Mavenのモジュールはアーティファクトを一つしか持てません。そのため、プロジェクトが依存していしかし、GradleやIvyの場合は違います。Ivyの依存関係モデル(ivy.xml)では、一つのモジュールに複数のアーティファクトを宣言できるからです。 詳細についてはivy.xmlのリファレンスを参照してください。
Gradleでivyモジュールへ依存していることを宣言したとき、実際にはそのモジュールのdefault
コンフィギュレーションへの依存関係を宣言しています。
つまり、プロジェクトが実際に依存しているアーティファクト(典型的にはjar)は、モジュールのdefault
コンフィギュレーションに格納された全アーティファクトです。
このことが重要になるのは、以下のような場合です。
defaultコンフィグレーションに、不必要なアーティファクトが含まれている場合。この場合、default
コンフィグレーション全てに依存するのではなく、必要なアーティファクトへの依存関係のみを宣言します。
必要なアーティファクトがdefault

コンフィグレーション以外のコンフィグレーションに含まれている場合。この場合、そのコンフィグレーションを

Page 253 of 436

依存関係の宣言を微調整しなければならないようなシチュエーションはまだまだあります。
その他の例や依存関係宣言の完全なリファレンスについてはDependencyHandler
をご覧ください。

51.4.1.2. アーティファクトオンリー記法

上記のように、モジュールのディスクリプタファイルが見つからなかった場合、Gradleはデフォルトでモジュールの名

しかし、リポジトリにディスクリプタファイルがあるアーティファクトでも、場合によってはjarのみをダウンロードし
[

2

2

]

その他にも、ディスクリプタファイルを持たないリポジトリからzipファイルをダウンロードしたいという場合なども
ア ー テ ィ フ ァ ク ト オ ン リ ー

記法というものをサポートしています。書き方は簡単で、ダウンロードしたいものの拡張子を「@」で指定するだけで例51.5 アーティファクトオンリー記法
build.gradle
dependencies {runtime "org.groovy:groovy:2.2.0@jar"
runtime group: 'org.groovy', name: 'groovy', version: '2.2.0', ext: 'jar'}

アーティファクトオンリー記法は、指定した拡張子のファイルのみをダウンロードする、というモジュール依存関係を

51.4.1.3. 分類子(Classifiers)
Mavenには分類子(classifiers)という記法があります。

[23]

Gradleでもこの記法をサポートしています。Mavenリポジトリから分類子つきの依存関係を取得するには、次のように
例51.6 分類子付きの依存関係
build.gradle

compile "org.gradle.test.classifiers:service:1.0:jdk15@jar"
otherConf group: 'org.gradle.test.classifiers', name: 'service', version: '1.0', classifier:

上記の一行目にあるように、分類子は明示的に拡張子を指定して(アーティファクトオンリー記法で)使うこともできま
コンフィグレーションに含まれる依存アーティファクトの一覧は簡単に列挙できます。

Page 254 of 436

例51.7 あるコンフィグレーションの内部を列挙する
build.gradle
task listJars << {configurations.compile.each { File file -> println file.name }}gradle -q listJars の出力> gradle -q listJars
hibernate-core-3.6.7.Final.jar
antlr-2.7.6.jar
commons-collections-3.1.jar
dom4j-1.6.1.jarhibernate-commons-annotations-3.2.0.Final.jar
hibernate-jpa-2.0-api-1.0.1.Final.jar
jta-1.1.jar
slf4j-api-1.6.1.jar

51.4.2. クライアントモジュール依存関係
クライアントモジュール依存関係を使うと、モジュールの 推移的な依存関係をビルドスクリプトの中で直接定義できます。これは外部リポジトリにある実際のモジュールディスクリプタ
例51.8 クライアントモジュール依存関係 - 推移的な依存関係
build.gradle
dependencies {runtime module("org.codehaus.groovy:groovy:2.3.6") {dependency("commons-cli:commons-cli:1.0") {transitive = false}
module(group: 'org.apache.ant', name: 'ant', version: '1.9.3') {dependencies "org.apache.ant:ant-launcher:1.9.3@jar","org.apache.ant:ant-junit:1.9.3"}}}

この例では、Groovyに依存していることが宣言されています。Groovyは、それ自身別の依存関係を持っているのです

クライアントモジュールの依存関係としては、普通のモジュール依存関係の他、アーティファクトオンリー記法、またClientModuleも参考にしてください。

現在、クライアントモジュールには一つの制限があります。プロジェクトがライブラリをビルドするもので、そのライ

51.4.3. プロジェクト依存関係

Gradleでは、外部モジュール依存関係と、マルチプロジェクト内で別のプロジェクトを参照する依存関係は明確に区別
後者は プロジェクト依存関係 として宣言します。

Page 255 of 436

例51.9 プロジェクト依存関係
build.gradle
dependencies {compile project(':shared')}

APIドキュメントProjectDependencyに詳しい情報が記載されています。
また、マルチプロジェクトについては、57章マルチプロジェクトのビルドで詳述されています。

51.4.4. ファイル依存関係

ファイル依存関係は、前もってファイルをリポジトリに格納することなく、直接コンフィギュレーションに追加するこ方法も簡単で、単にファイルコレクション
を依存関係としてコンフィギュレーションに渡すだけです。
例51.10 ファイル依存関係
build.gradle
dependencies {runtime files('libs/a.jar', 'libs/b.jar')runtime fileTree(dir: 'libs', include: '*.jar')}

ファイル依存関係は、公開されるディスクリプタファイルには含まれません。しかし、同じビルド内から参照された場

つまり、ファイル依存関係は、そのビルドの外部からは使用されませんが、同じビルド内のプロジェクトからは使用さファイル依存関係では、どのタスクがファイルを生成するのか宣言することができます。依存ファイルがビルドで作成
例51.11 生成されるファイルへの依存関係
build.gradle
dependencies {compile files("$buildDir/classes") {builtBy 'compile'}}task compile << {println 'compiling classes'}
task list(dependsOn: configurations.compile) << {println "classpath = ${configurations.compile.collect {File file -> file.name}}"}gradle -q list の出力> gradle -q list
compiling classes
classpath = [classes]

Page 256 of 436

51.4.5. Gradle API依存関係
DependencyHandler.gradleApi()
メソッドを使うと、そのビルドで使用しているGradleのAPIへ依存していることを宣言できます。
Gradleのカスタムタスクやプラグインを開発しているときによく使われます。
例51.12 Gradle API依存関係
build.gradle
dependencies {compile gradleApi()}

51.4.6. ローカルGroovy依存関係
DependencyHandler.localGroovy()を使うと、Gradleに同梱されているGroovyへの依存関係を宣言できます。
これもGradleのカスタムタスクやプラグインを開発しているときによく使われます。
例51.13 Gradleに同梱されているGroovyへの依存関係
build.gradle
dependencies {compile localGroovy()}

51.4.7. 推移的な依存関係の除外
コンフィギュレーション単位、または依存関係単位で、特定の推移的な依存関係を除外することができます。
例51.14 推移的な依存関係の除外
build.gradle
configurations {compile.exclude module: 'commons'all*.exclude group: 'org.gradle.test.excludes', module: 'reports'}
dependencies {compile("org.gradle.test.excludes:api:1.0") {exclude module: 'shared'}}

コンフィギュレーションに対してある依存関係を除外すると、そのコンフィギュレーション、および全ての継承コンフ

また、全てのコンフィギュレーションにまとめて除外設定を適用したい場合は、例にあるようにGroovyの展開ドット
除外設定は、organizationのみを指定することもできますし、モジュール名やその両方で指定しても構いません。
APIドキュメントのDependencyやConfigurationを参照してみてください。

Page 257 of 436

全ての推移的な依存関係が除外できるとは限りません。アプリケーションの動作に必須な依存関係もあります。

一般的には、実行時に使われることがないものや、対象環境やプラットフォームでそれが使えると保証できているよう
除外設定は、依存関係単位かコンフィギュレーション単位、どちらで設定するべきでしょうか？
ほとんどの場合は、コンフィギュレーション単位で設定することになるでしょう。
推移的な依存関係を除外したいと考える、代表的な理由を挙げてみます。

なお、これらの中には、依存関係を除外してしまうよりも優れた解決手段があるものもあります。頭に留めておいてく
ライセンス上の理由により、その依存関係を除外したい
いずれかのリモートリポジトリで、その依存関係が使用できない
実行時にその依存関係が不要

その依存関係のバージョンが競合していて欲しいバージョンの依存関係が取得できない。この場合、除外設定より「バージョン競合の解決 」やResolutionStrategyを参照してみてください。

基本的には、ほとんどのケースでコンフィギュレーション単位の除外設定を使うべきです。これにより、依存関係の宣例えば、除外ルールを適用していない別の依存関係が、除外したはずの依存関係を引っ張ってきてしまうかもしれませリファレンスには、除外設定の他の例も記載されています。 ModuleDependency やDependencyHandlerを見てみてください。

51.4.8. オプション属性

依存関係宣言の属性は、nameを除いて全てオプションです。ただ、実際にリポジトリから依存関係を見つけてくる際「リポジトリ」を参照してください。

例えば、Mavenリポジトリを使うときは、組織名、モジュール名、およびバージョンを指定する必要があります。一方
例51.15 依存関係のオプション属性
build.gradle
dependencies {runtime ":junit:4.10", ":testng"
runtime name: 'testng'}

また、依存関係定義のコレクションや属性をコンフィギュレーションに割り当てることもできます。
例51.16 依存関係定義のコレクション、配列
build.gradle
List groovy = ["org.codehaus.groovy:groovy-all:2.3.6@jar","commons-cli:commons-cli:1.0@jar","org.apache.ant:ant:1.9.3@jar"]
List hibernate = ['org.hibernate:hibernate:3.0.5@jar','somegroup:someorg:1.0@jar']dependencies {runtime groovy, hibernate}

Page 258 of 436

51.4.9. 依存するコンフィギュレーションの指定

Gradleでは、依存先のモジュールが複数のコンフィギュレーションを公開していることがあります(自分のプロジェク
特に明示しないかぎり、Gradleはその依存関係のdefaultコンフィギュレーションを使用します。

Mavenリポジトリではdefaultコンフィギュレーションが使用できる唯一のコンフィギュレーションなのでいいのです
例51.17 依存するコンフィギュレーションの指定
build.gradle

dependencies {runtime group: 'org.somegroup', name: 'somedependency', version: '1.0', configuration: 'some}

プロジェクト依存関係で同じことをするには、次のように定義する必要があります。
例51.18 依存するプロジェクトのコンフィギュレーション
build.gradle
dependencies {compile project(path: ':api', configuration: 'spi')}

51.4.10. 依存関係のレポート
Gradleには、依存関係に関するレポートを生成できるコマンドが用意されています(「プロジェクトの依存関係一覧」 参照)。

また、プロジェクトレポートプラグイン( 41章

プ ロ ジ ェ ク ト レ ポ ー ト プ ラ グ イ ン)を使えば、ビルドのタスクでそのレポートを作成することもできます。
ResolvableDependencies.getResolutionResult() .

Potential

usages

of

the
API:

ResolutionResult

Gradle1.2からは、解決した依存関係に関する情報に、プログラム的にアクセスできるAPIもあります。
先ほど述べた依存関係のレポートを作成するときも、水面下でこのAPIが使用されています。
このAPIを使えば、解決した依存関係グラフを走査したり、情報を取得したりすることが可能です。
また、近くこのAPIを更に拡張し、解決結果についてもっと情報を取得できるようにする予定です。
APIについての詳細はJavadoc(ResolvableDependencies.getResolutionResult())を参照してください。 API(ResolutionResult)の使い道として考えられるのは、自分のユースケースに適した、もっと踏み込んだレポートを作成するため依存関係グラフの中身に応じて処理を切り替えるようなビルドロジックを実装するため

51.5. 依存関係を使った作業
例えば、次のような依存関係をセットアップしたとします。

Page 259 of 436

例51.19 Configuration.copy
build.gradle
configurations {sealifealllife}dependencies {sealife "sea.mammals:orca:1.0", "sea.fish:shark:1.0", "sea.fish:tuna:1.0"
alllife configurations.sealife
alllife "air.birds:albatross:1.0"}

このセットアップにおける推移的な依存関係は、以下の通りです。
shark-1.0 -> seal-2.0, tuna-1.0
orca-1.0 -> seal-1.0
tuna-1.0 -> herring-1.0
このコンフィギュレーションを使って、宣言された依存関係やその一部にアクセスできます。
例51.20 宣言した依存関係にアクセスする
build.gradle
task dependencies << {configurations.alllife.dependencies.each { dep -> println dep.name }println()
configurations.alllife.allDependencies.each { dep -> println dep.name }println()
configurations.alllife.allDependencies.findAll { dep -> dep.name != 'orca' }.each { dep -> println dep.name }}gradle -q dependencies の出力> gradle -q dependencies
albatrossalbatross
orca
shark
tuna
albatross
shark
tuna

dependenciesはコンフィギュレーションに明示的に属しているもののみを返します。
allDependenciesは継承したコンフィギュレーションに含まれるものも返します。
コンフィギュレーションの依存関係として設定されているライブラリファイルを取得するには、次のようにします。

Page 260 of 436

例51.21 Configuration.files
build.gradle
task allFiles << {configurations.sealife.files.each { file ->println file.name}}gradle -q allFiles の出力> gradle -q allFiles
orca-1.0.jar
shark-1.0.jar
tuna-1.0.jar
herring-1.0.jar
seal-2.0.jar

コンフィギュレーションに属する依存関係のうち、一部の依存関係のみ、例えば一つの依存関係のみライブラリファイ
例51.22 フィルター付きConfiguration.files
build.gradle
task files << {configurations.sealife.files { dep -> dep.name == 'orca' }.each { file ->println file.name}}gradle -q files の出力> gradle -q files
orca-1.0.jar
seal-2.0.jar

Configuration.files メソッドは、常にそのコンフィギュレーション 全体

から全てのアーティファクトを返すので、ここでは依存関係を指定してフィルターしました。例にあるように、推移的

コンフィギュレーションはコピーすることもできます。さらに、元のコンフィギュレーションから一部の依存関係のみ
コピー用のメソッドは二つ用意されており、copy
メソッドは明示的にコンフィギュレーションに属している依存関係のみコピーします。もう一つのc o p y R e c u r s i v e
メソッドは継承元のコンフィギュレーションに含まれる依存関係もすべてコピーします。

Page 261 of 436

例51.23 Configuration.copy
build.gradle
task copy << {configurations.alllife.copyRecursive { dep -> dep.name != 'orca' }.allDependencies.each { dep -> println dep.name }println()
configurations.alllife.copy().allDependencies.each { dep -> println dep.name }}gradle -q copy の出力> gradle -q copy
albatross
shark
tuna
albatross

注意するべきなのは、コピーされたコンフィギュレーションから返される依存関係が、常にオリジナルのコンフィギュ「コピーされたサブセット」と、「コピーされなかった残りのサブセット」の間でバージョンの競合がある場合、依存
例51.24 Configuration.copy vs. Configuration.files
build.gradle
task copyVsFiles << {configurations.sealife.copyRecursive { dep -> dep.name == 'orca' }.each { file -> println file.name }println()
configurations.sealife.files { dep -> dep.name == 'orca' }.each { file -> println file.name }}gradle -q copyVsFiles の出力> gradle -q copyVsFiles
orca-1.0.jar
seal-1.0.jar
orca-1.0.jar
seal-2.0.jar

上の例では、 orca が seal-1.0 に依存しており、 shark は seal-2.0に依存しています。なので、オリジナルのコンフィギュレーションではバージョンの競合が発生しているわけです。
そのため、この依存関係はより新しいバージョンである seal-2.0に解決され、推移的な依存関係として seal-2.0 が表示されています。
一方、コピー先のコンフィギュレーションにはorcaしか含まれていません。そのためバージョンの競合は発生しておらず、推移的な依存関係として
seal-1.0が表示されているのです。
一度解決されたコンフィギュレーションは不変(immutable)です。

その状態を変更したり、コンフィギュレーション内の依存関係の状態を変更したりすると例外が発生します。一方でコPage 262 of 436

ConfigurationクラスのAPIをさらに詳しく知りたいときは、APIドキュメント(Configuration)をご参照ください。

51.6. リポジトリ
Gradleのリポジトリ管理機能は、Apache

Ivyをベースにしたもので、リポジトリのレイアウトや参照方法を自在に定義できます。さらに、Gradleにはあらかじ
リポジトリはいくつでも定義できますが、Gradleからはそれぞれが独立して取り扱われます。
あるリポジトリでモジュールのディスクリプタが見つかれば、Gradleはそのモジュールのアーティファクトを全て同じリポジトリ からダウンロードしようとします。

つまり、モジュールのメタデータと全てのアーティファクトは同じリポジトリになければなりません。しかし、一つの宣言できるリポジトリには、以下のものがあります。
表51.2 リポジトリの種類
種類

説明

Mavenセントラルリポジトリ

Mavenセントラルにある依存関係を探すための定義済みリポジトリ

Maven JCenterリポジトリ

BintrayのJCenterにある依存関係を探すための定義済みリポジトリ

Mavenローカルリポジトリ

Mavenのローカルリポジトリにある依存関係を探すための定義済みリポジトリ

Mavenリポジトリ

Mavenリポジトリ。ローカルファイルシステムまたはリモートに配置できる。

Ivyリポジトリ

Ivyリポジトリ。ローカルファイルシステムまたはリモートに配置できる。

フラットディレクトリリポジトリ

ローカルファイルシステム上のシンプルなリポジトリ。メタデータは一切サポ

51.6.1. Supported repository transport protocols
Maven and Ivy repositories support the use of various transport protocols. At the moment thefollowing protocols are supported:
表51.3 Repository transport protocols
Type

Authentication schemes

file

none

http

username/password

httpsusername/password

sftp

username/password

To define a repository use the repositories configuration block. Within the repositories
closure, a Maven repository is declared with maven. An Ivy repository is declared with ivy. The
transport protocol is part of the URL definition for a repository. The following build script
demonstrates how to create a HTTP-based Maven and Ivy repository:

Page 263 of 436

例51.25 Declaring a Maven and Ivy repositorybuild.gradle
repositories {maven {
url "http://repo.mycompany.com/maven2"}
ivy {url "http://repo.mycompany.com/repo"}}

If authentication is required for a repository, the relevant credentials can be provided. The
following example shows how to provide username/password-based authentication for SFTP
repositories:
例51.26 Providing credentials to a Maven and Ivy repositorybuild.gradle
repositories {maven {
url "sftp://repo.mycompany.com:22/maven2"
credentials {username 'user'
password 'password'
}
}
ivy {
url "sftp://repo.mycompany.com:22/repo"
credentials {username 'user'
password 'password'}}}

51.6.2. Mavenセントラルリポジトリ
Maven2のセントラルリポジトリ(http://repo1.maven.org/maven2)は、次のように簡単に追加できます。
例51.27 Mavenセントラルリポジトリを追加する
build.gradle
repositories {mavenCentral()}Warning: Be aware that the central Maven 2 repository is HTTP only and HTTPS is notsupported. If you need a public HTTPS enabled central repository, you can use the JCenter
public repository (see 「Maven JCenterリポジトリ 」).
Page 264 of 436

これで、Gradleはこのリポジトリから依存関係を探すようになります。

51.6.3. Maven JCenterリポジトリ
B

i

n

t

r

a

y

のJCenterには、Bintrayに直接公開されたアーティファクトだけでなく、ポピュラーなMaven上のOSSライブラリが全JCenter Mavenリポジトリ(https://jcenter.bintray.com)は、次のように簡単に追加できます。
例51.28 BintrayのJCenter Mavenリポジトリを追加する
build.gradle
repositories {jcenter()}

これで、GradleはJCenterリポジトリから依存関係を探すようになります。 jcenter() uses HTTPS toconnect to the repository. If you want to use HTTP you can configure jcenter():
例51.29 Using Bintrays's JCenter with HTTP
build.gradle
repositories {jcenter {url "http://jcenter.bintray.com/"}}

51.6.4. ローカルMavenリポジトリ
Mavenのローカルキャッシュをリポジトリとして使うには、次のようにします。
例51.30 Mavenのローカルキャッシュをリポジトリとして追加する
build.gradle
repositories {mavenLocal()}Gradleは、Mavenが使っているのと同じロジックでローカルキャッシュの場所を決定します。
もしローカルリポジトリの場所がsettings.xmlで定義されていれば、そこが使用されます。 USER_HOME /.m2のsettings.xmlは、 M2_HOME /confのsettings.xmlよりも優先されます。 使用できるsettings.xmlがなければ、デフォルトの USER_HOME /.m2/repository
がローカルキャッシュの場所になります。

51.6.5. Mavenリポジトリ
カスタムのMavenリポジトリを追加するには、次のようにします。

Page 265 of 436

例51.31 カスタムMavenリポジトリを追加する
build.gradle
repositories {maven {
url "http://repo.mycompany.com/maven2"}}

POMとJARなどのアーティファクトを別々の場所に配置するようなリポジトリもあります。このようなリポジトリを設
例51.32 JARファイル用の追加リポジトリを設定する
build.gradle
repositories {maven {// Look for POMs and artifacts, such as JARs, hereurl "http://repo2.mycompany.com/maven2"// Look for artifacts here if not found at the above location
artifactUrls "http://repo.mycompany.com/jars"
artifactUrls "http://repo.mycompany.com/jars2"}}

Gradleは、最初のURLを、POMとJARを探すために使用します。JARがそこで見つからなかった場合は、アーティファ

51.6.5.1. パスワードで保護されたMavenリポジトリへのアクセス

BASIC認証で保護されたMavenリポジトリにアクセスするには、リポジトリ定義でユーザー名とパスワードを指定しま
例51.33 パスワード保護されたMavenリポジトリへのアクセス
build.gradle
repositories {maven {
credentials {username 'user'
password 'password'}
url "http://repo.mycompany.com/maven2"}}

ユーザー名、パスワードは、ビルドファイルに直接指定するのではなく、gradle.propertiesに外出しすることを推奨します。

51.6.6. フラットディレクトリリポジトリ

ファイルシステム上の(フラットな)ディレクトリをリポジトリとして使用したい場合は、単に次のようにタイプしてく

Page 266 of 436

例51.34 フラットディレクトリ・リゾルバ
build.gradle
repositories {flatDir {dirs 'lib'}flatDir {dirs 'lib1', 'lib2'}}

これで、依存関係を取得するリポジトリとして複数のディレクトリが追加されました。

このフラットディレクトリ・リゾルバのみ使うのであれば、依存関係定義ですべての属性を定義する必要はありません「オプション属性 」をご参照ください。

51.6.7. Ivyリポジトリ
51.6.7.1. Defining an Ivy repository with a standard layout
例51.35 Ivyリポジトリ
build.gradle
repositories {ivy {url "http://repo.mycompany.com/repo"}}

51.6.7.2. Defining a named layout for an Ivy repository
You can specify that your repository conforms to the Ivy or Maven default layout by using a
named layout.
例51.36 Ivy repository with named layout
build.gradle
repositories {ivy {url "http://repo.mycompany.com/repo"
layout "maven"}}

Valid named layout values are 'gradle' (the default), 'maven' and 'ivy'. See
IvyArtifactRepository.layout() in the API documentation for details of these named
layouts.

51.6.7.3. Ivyリポジトリのカスタムパターンを定義する
標準的でないレイアウトのIvyリポジトリを使うには、リポジトリのパターンレイアウトを定義します。

Page 267 of 436

例51.37 パターンレイアウトを指定したIvyリポジトリ
build.gradle
repositories {ivy {url "http://repo.mycompany.com/repo"
layout "pattern", {artifact "[module]/[revision]/[type]/[artifact].[ext]"}}}

51.6.7.4. Maven互換レイアウトのIvyリポジトリ

オプションとして、パターンレイアウトを定義する際、「organisation」部分をMavenスタイルに展開し、ドットの代例えば、my.companyという組織名はmy/companyと表現されます。
例51.38 Maven互換レイアウトのIvyリポジトリ
build.gradle
repositories {ivy {url "http://repo.mycompany.com/repo"
layout "pattern", {artifact "[organisation]/[module]/[revision]/[artifact]-[revision].[ext]"
m2compatible = true}}}

Valid named layout values are 'gradle' (the default), 'maven' and 'ivy'. See
IvyArtifactRepository.layout() in the API documentation for details of these named
layouts.

51.6.7.5. アーティファクトとivyファイルの場所が異なるIvyリポジトリの設定
例51.39 Ivy repository with pattern layout
build.gradle
repositories {ivy {url "http://repo.mycompany.com/repo"
layout "pattern", {artifact "[module]/[revision]/[type]/[artifact].[ext]"}}}

To define an Ivy repository which fetches Ivy files and artifacts from different locations, you candefine separate patterns to use to locate the Ivy files and artifacts:

Page 268 of 436

Each artifact or ivy specified for a repository adds an additional pattern to use. The patterns
are used in the order that they are defined.
例51.40 Ivy repository with multiple custom patterns
build.gradle

repositories {ivy {url "http://repo.mycompany.com/repo"
layout "pattern", {artifact "3rd-party-artifacts/[organisation]/[module]/[revision]/[artifact]-[revisio
artifact "company-artifacts/[organisation]/[module]/[revision]/[artifact]-[revision]ivy "ivy-files/[organisation]/[module]/[revision]/ivy.xml"}}}

Optionally, a repository with pattern layout can have its 'organisation' part laid out in Mavenstyle, with forward slashes replacing dots as separators. For example, the organisation my.company
would then be represented as my/company.
例51.41 Ivy repository with Maven compatible layout
build.gradle
repositories {ivy {url "http://repo.mycompany.com/repo"
layout "pattern", {artifact "[organisation]/[module]/[revision]/[artifact]-[revision].[ext]"
m2compatible = true}}}

51.6.7.6. パスワードで保護されたIvyリポジトリへのアクセス

BASIC認証で保護されたIvyリポジトリへアクセスするには、リポジトリ定義の際にユーザー名とパスワードを指定しま
例51.42 パスワードで保護されたIvyリポジトリ
build.gradle
repositories {ivy {url 'http://repo.mycompany.com'
credentials {username 'user'
password 'password'}}}

Page 269 of 436

51.6.8. リポジトリを使った作業
リポジトリ定義にアクセスするには、
例51.43 リポジトリ定義へのアクセス
build.gradle
println repositories.localRepository.nameprintln repositories['localRepository'].name

リポジトリの設定を変更するには、
例51.44 リポジトリの設定変更
build.gradle
repositories {flatDir {name 'localRepository'}}
repositories {
localRepository {dirs 'lib'}}
repositories.localRepository {dirs 'lib'}

51.6.9. Ivyリゾルバについて

Gradleは、水面下でIvyを使っているおかげで、リポジトリに関しては非常に高い柔軟性を持っています。たとえば、リポジトリとの通信プロトコル(ファイルシステム、http、ssh、等々)がたくさん用意されている
The protocol sftp currently only supports username/password-based authentication.
一つ一つのリポジトリが、それぞれ独自のレイアウトを持つことができる
j u n i t : j u n i t : 3 . 8 . 2

へ依存していることを定義したとしましょう。このとき、Gradleはどのようにしてリポジトリからjunitを探すのでしょ[24]// Maven2 (Maven2())
someroot/[organisation]/[module]/[revision]/[module]-[revision].[ext]// Ivy()someroot/[organisation]/[module]/[revision]/[type]s/[artifact].[ext]// ()someroot/[artifact]-[revision].[ext]

上記のどのリポジトリも、以下のようにして参照できます。

Page 270 of 436

例51.45 カスタムリポジトリの定義
build.gradle

repositories {ivy {ivyPattern "$projectDir/repo/[organisation]/[module]-ivy-[revision].xml"
artifactPattern "$projectDir/repo/[organisation]/[module]-[revision](-[classifier]).[ext}}Ivyで(つまりGradleで)どんなリゾルバを使えるかはここで見ることができます。Gradleでは、XMLを経由することなく直接これらのAPIを操作できます。

51.7. 依存関係解決の仕組み
Gradleは、ビルドスクリプトの依存関係宣言とリポジトリ定義を読み込み、 依存関係解決と呼ばれる処理によって依存関係を全てダウンロードしようと試みます。以下に、その処理がどのように進むか、概要
必要な依存関係が指示されると、Gradleはまず、リポジトリを順に検査して、その依存関係のモジュール を解決しようとします。

モジュールディスクリプタ

ファイル(POMまたはIvyファイル)が見つかれば、リポジトリにモジュールがあると判断します。ディスクリプタフ
モジュールアーティファクト ファイルがあるかどうかでモジュールの有無を判断します。
もし、依存関係が動的バージョン(1.+のような)で指定されていれば、Gradleは動的バージョンを、リポジトリ内の最新の静的バージョン(
1.2など)に解決します。この処理は、Mavenリポジトリに対してはmaven-metadata.xml
ファイルを使って行われ、Ivyリポジトリの場合はディレクトリ内の一覧表示が使用されます。
モジュールディスクリプタが、親POMの宣言を含むPOM
ファイルだった場合、GradleはPOMの親モジュールを再帰的に解決しようとします。

全てのリポジトリでモジュールの調査が終わると、Gradleはそれらのリポジトリの中から、使うのに「最も良い」
動的バージョンに関しては、なるべく新しい静的バージョンが使用できるリポジトリが好ましい。

モジュールディスクリプタ(ivyやpomファイル)で宣言されているモジュールは、アーティファクトファイルしか早く見に行ったリポジトリのほうが、後のリポジトリよりも優先される。

依存関係が静的バージョンで宣言されており、かつモジュールディスクリプタがリポジトリにあれば、後続のリポモジュール内の全アーティファクトを、上記処理で選択したリポジトリと 同じリポジトリに取得しに行きます。

51.8. 依存関係解決処理の微調整

Gradleの依存関係管理は、ほとんどの場合、デフォルトのままでビルドに必要な依存関係を解決できます。しかし、正Gradleの依存関係解決処理は、様々な部分で調整可能です。

51.8.1. モジュールのバージョンを強制する指定した依存関係について、（推移的かどうかにかかわらず）指定したバージョンを使うよう解決処理を設定できます

依存関係は、グループ名と名前で指定します。この機能は、バージョンの競合に四苦八苦している際にとても便利です「バージョン競合の解決 」を参照してください。

Page 271 of 436

また、推移的な依存関係のメタデータが壊れている場合もこれで対処できることがあります。推移的な依存関係のメタR e s o l u t i o n S t r a t e g yの例を参照してください。また、「依存関係解決ルール」は壊れたモジュールを置き換える更に強力な機構を提供しま「バージョンのブラックリストと差し替え 」を参照してください。

51.8.2. 依存関係解決ルールを使う

依存関係解決ルールは、全ての依存関係に対して実行され、要求された依存関係を解決前に操作する強力なAPIを提供
こ の 機 能 は 試 験 的 なものですが、要求した依存関係のグループ名や名前、バージョンを変更し、解決処理中に依存関係を完全に別のモジュ依存関係解決ルールは依存関係をコントロールする非常に強力な手段で、依存関係管理における先進的なパターンを全
いくつかのパターンの概要を以下に紹介します。詳細な情報やコードサンプル等はResolutionStrategyをご参照ください。

51.8.2.1. リリース可能単位を表現する

組織によっては、いくつかのライブラリをまとめて一つのバージョンでリリースすることがあります。それらのライブ

そのようなライブラリ群は、「リリース可能単位」として構成され、一緒に使用されることが想定されています。一般
しかし、この制限は、推移的な依存関係の中で簡単に破られてしまいます。以下の例をご覧ください。
module-a depends on releasable-unit:part-one:1.0
module-b depends on releasable-unit:part-two:1.1m o d u l e - a と m o d u l e - bの両方に依存しているビルドがあれば、それぞれのモジュールがリリース可能単位を構成するライブラリの別々のバー
依存関係解決ルールを使うと、ビルドで使用するリリース可能単位を強制できます。

'org.gradle'グループに属する全てのライブラリが、あるリリース可能単位を構成していると想像してください。これら
例51.46 あるグループのライブラリ全てで一貫したバージョンを使用するよう強制する
build.gradle
configurations.all {resolutionStrategy.eachDependency { DependencyResolveDetails details ->if (details.requested.group == 'org.gradle') {details.useVersion '1.4'}}}

51.8.2.2. 独自のバージョニング体制を実装する

社内環境によっては、gradleのビルドで使用できるモジュールのバージョンリストを外部的に監視、維持していること
依存関係解決ルールはこのようなパターンを簡潔に実装できます。
ビルドスクリプトでは、使用するモジュールのグループと名前を開発者が記述しますが、バージョンだけは「
default」などのプレースホルダで宣言します。

Page 272 of 436

「default」バージョンは、依存関係解決ルールがある特定のバージョンに置換します。その際、承認されたモジュールの一
このルールの実装は、整理して社内プラグインにカプセル化し、組織内の全てのビルドで共有することもできます。
例51.47 独自のバージョニング体制を実装する
build.gradle

configurations.all {resolutionStrategy.eachDependency { DependencyResolveDetails details ->if (details.requested.version == 'default') {def version = findDefaultVersionInCatalog(details.requested.group, details.requested
details.useVersion version}}}
def findDefaultVersionInCatalog(String group, String name) {//some custom logic that resolves the default version into a specific version"1.0"}

51.8.2.3. バージョンのブラックリストと差し替え

依存関係解決ルールを使って、あるモジュールの特定のバージョンをブラックリストに指定し、バージョンを差し替え

これは、あるモジュールにおいて特定のバージョンが壊れていて使いたくないという場合に有用で、そのバージョンを一例を挙げると、どこの公開リポジトリにも存在しないライブラリに依存しているようなモジュールは「壊れたモジュ以下の例では、バージョン 1.2.1 に重要な修正が含まれていて、 1.2
ではなく必ずそちらを使いたい、という状況を想定しています。 例のルールは、単にバージョン1.2
を 見 つ け た ら 必 ず 1 . 2 . 1に差し替えられるということを保証しているだけですが、注目すべき点は、これが上の方で述べたバージョンの強制と例えばバージョン1.3もどこかで推移的に引っ張られている場合、競合解決戦略「newest」によりバージョン1.3が選例51.48 バージョンのブラックリスト指定と差し替
build.gradle

configurations.all {resolutionStrategy.eachDependency { DependencyResolveDetails details ->if (details.requested.group == 'org.software' && details.requested.name == 'some-library//prefer different version which contains some necessary fixes
details.useVersion '1.2.1'}}}

Page 273 of 436

51.8.2.4. 依存モジュールを互換性のあるモジュールに差し替える要求されたモジュールを、全く異なる別モジュールに差し替えることができる場合もあります。
例にあるのは、「groovy-all」から「groovy」への差し替えと「log4j」から「log4j-over-slf4j」 へ の 差 し 替 え で す 。
Gradle1.5から、このような置き換えも依存関係解決ルールで可能になりました。
例51.49 解決時に依存関係のグループ名や名前を変更する
build.gradle

configurations.all {resolutionStrategy.eachDependency { DependencyResolveDetails details ->if (details.requested.name == 'groovy-all') {//prefer 'groovy' over 'groovy-all':details.useTarget group: details.requested.group, name: 'groovy', version: details.r}
if (details.requested.name == 'log4j') {//prefer 'log4j-over-slf4j' over 'log4j', with fixed version:
details.useTarget "org.slf4j:log4j-over-slf4j:1.7.7"}}}

51.8.2.5. Declaring that a legacy library is replaced by a new one
A good example when a new library replaced a legacy one is the "google-collections" -> "guava"
migration. The team that created google-collections decided to change the module name from"com.google.collections:google-collections" into "com.google.guava:guava". This a legal scenario
in the industry: teams need to be able to change the names of products they maintain, including
the module coordinates. Renaming of the module coordinates has impact on conflict resolution.
To explain the impact on conflict resolution, let's consider the "google-collections" -> "guava"
scenario. It may happen that both libraries are pulled into the same dependency graph. For
example, "our" project depends on guava but some of our dependencies pull in a legacy version
of google-collections. This can cause runtime errors, for example during test or application
execution. Gradle does not automatically resolve the google-collections VS guava conflictbecause it is not considered as a "version conflict". It's because the module coordinates for both
libraries are completely different and conflict resolution is activated when "group" and "name"coordinates are the same but there are different versions available in the dependency graph (formore info, please refer to the section on conflict resolution). Traditional remedies to thisproblem are:Declare exclusion rule to avoid pulling in "google-collections" to graph. It is probably themost popular approach.
Avoid dependencies that pull in legacy libraries.
Upgrade the dependency version if the new version no longer pulls in a legacy library.
Downgrade to "google-collections". It's not recommended, just mentioned for completeness.
Traditional approaches work but they are not general enough. For example, an organisation

Page 274 of 436

wants to resolve the google-collections VS guava conflict resolution problem in all projects.
Starting from Gradle 2.2 it is possible to declare that certain module was replaced by other. This
enables organisations to include the information about module replacement in the corporate
plugin suite and resolve the problem holistically for all Gradle-powered projects in theenterprise.
例51.50 Declaring module replacementbuild.gradle

dependencies {components {module("com.google.collections:google-collections").replacedBy("com.google.guava:guava")}}

For more examples and detailed API, please refer to the DSL reference for
ComponentMetadataHandler.
What happens when we declare that "google-collections" are replaced by "guava"? Gradle canuse this information for conflict resolution. Gradle will consider every version of "guava"
newer/better than any version of "google-collections". Also, Gradle will ensure that only guava jar
is present in the classpath / resolved file list. Please note that if only "google-collections"appears in the dependency graph (e.g. no "guava") Gradle will not eagerly replace it with "guava".
Module replacement is an information that Gradle uses for resolving conflicts. If there is noconflict (e.g. only "google-collections" or only "guava" in the graph) the replacement information
is not used.
Currently it is not possible to declare that certain modules is replaced by a set of modules.
However, it is possible to declare that multiple modules are replaced by a single module.

51.8.3. Ivyの動的解決モードを有効にする

GradleのIvyレポジトリ実装は、Ivyの動的解決モードと同等のものをサポートしています。通常、Gradleは依存関係に
ivy.xmlファイルで定義されているrev属性を使用しますが、動的解決モードでは、Gradleはrev
属性の代わりにrevConstraint属性を優先して使用します。revConstraintが未定義の時はrev属性を使用します。

動的解決モードを有効にするには、リポジトリ定義に適切なオプションを設定する必要があります。いくつかの例を以DependencyResolver実装のIvyリポジトリでは使用できません。

Page 275 of 436

例51.51 動的解決モードを有効にする
build.gradle// Can enable dynamic resolve mode when you define the repository
repositories {ivy {url "http://repo.mycompany.com/repo"
resolve.dynamicMode = true}}// Can use a rule instead to enable (or disable) dynamic resolve mode for all repositories
repositories.withType(IvyArtifactRepository) {resolve.dynamicMode = true}

51.8.4. Component metadata rules
Each module (also called component ) has metadata associated with it, such as its group, name,version, dependencies, and so on. This metadata typically originates in the module's descriptor.
Metadata rules allow certain parts of a module's metadata to be manipulated from within thebuild script. They take effect after a module's descriptor has been downloaded, but before it has
been selected among all candidate versions. This makes metadata rules another instrument forcustomizing dependency resolution.
One piece of module metadata that Gradle understands is a module's status scheme . This
concept, also known from Ivy, models the different levels of maturity that a module transitions
through over time. The default status scheme, ordered from least to most mature status, is integration, milestone, release. Apart from a status scheme, a module also has a (current) status , whichmust be one of the values in its status scheme. If not specified in the (Ivy) descriptor, the statusdefaults to integration for Ivy modules and Maven snapshot modules, and release for
Maven modules that aren't snapshots.
A module's status and status scheme are taken into consideration when a latest version
selector is resolved. Specifically, latest.someStatus will resolve to the highest module version
that has status someStatus or a more mature status. For example, with the default status
scheme in place, latest.integration will select the highest module version regardless of its
status (because integration is the least mature status), whereas latest.release will selectthe highest module version with status release. Here is what this looks like in code:

Page 276 of 436

例51.52 'Latest' version selector
build.gradle
dependencies {
config1 "sea.fish:tuna:latest.integration"
config2 "sea.fish:tuna:latest.release"}task listFish << {configurations.config1.each { println it.name }println()
configurations.config2.each { println it.name}}gradle -q listFish の出力> gradle -q listFish
tuna-1.5.jar
tuna-1.4.jar

The next example demonstrates latest selectors based on a custom status scheme declared ina module metadata rule:
例51.53 Custom status schemebuild.gradle
dependencies {
config3 "air.birds:albatross:latest.silver"
components {eachComponent { ComponentMetadataDetails details ->if (details.id.group == "air.birds") {details.statusScheme = ["bronze", "silver", "gold", "platinum"]}}}}task listBirds << {configurations.config3.each { println it.name }}gradle -q listBirds の出力> gradle -q listBirds
albatross-2.0.jar

Gradle can also create component metadata rules utilizing Ivy-specific metadata for modules
resolved from an Ivy repository. Values from the Ivy descriptor are made available via the
IvyModuleDescriptor interface.

Page 277 of 436

例51.54 Ivy component metadata rulebuild.gradle
dependencies {components {eachComponent { ComponentMetadataDetails details, IvyModuleDescriptor ivyModule ->if (details.id.group == 'my.org' && ivyModule.branch == 'testing') {details.changing = true}}}}

51.8.5. Component Selection Rules
Component selection rules define how versions should be selected when multiple versions areavailable that match a given set of coordinates. Rules are applied against every available version
and allow the version to be explicitly rejected by rule. This allows Gradle to select alternate
versions when the alternate version is not known in advance.
Rules are configured via the ComponentSelectionRules object. Each rule configured will becalled with a ComponentSelection object as an argument which contains information about
the version being requested and the candidate version being considered. Calling
ComponentSelection.reject() causes the given candidate version to be explicitly rejected,
in which case the candidate will not be considered for the selector.
The following example shows a rule that disallows a particular version of a module but allows thedefault version selection rules to choose the next best candidate. If the version requested was 1.+, and versions 1.1, 1.0.1 and 1.0 were available, it would reject 1.1 and select the next newest
version available (1.0.1).
例51.55 Component selection rulebuild.gradle
configurations {rejectConfig {resolutionStrategy {componentSelection {// Accept the highest version matching the requested version that isn't '1.1'
all { ComponentSelection selection ->if (selection.candidate.group == 'org.sample' && selection.candidate.module
selection.reject("version 1.1 is broken for 'org.sample:api'")
}
}
}
}
}
}

Note that version selection is applied starting with the highest version first. The version selected
will be the first version found that all component selection rules accept. A version is considered

Page 278 of 436

accepted if a rule does not explicitly reject it.
Similarly, rules can be targeted at specific modules. Modules must be specified in the form of"group:module".
例51.56 Component selection rule with module target
build.gradle
configurations {targetConfig {resolutionStrategy {componentSelection {module("org.sample:api") { ComponentSelection selection ->if (selection.candidate.version == "1.1") {selection.reject("known bad version")
}
}
}
}
}
}

Component selection rules can also consider component metadata when selecting a version.
Possible metadata arguments that can be considered are ComponentMetadata andIvyModuleDescriptor.
例51.57 Component selection rule with metadatabuild.gradle

configurations {rejectConfig {resolutionStrategy {componentSelection {// Reject any versions with a status of 'experimental'
all { ComponentSelection selection, ComponentMetadata metadata ->if (selection.candidate.group == 'org.sample' && selection.candidate.module
if (metadata.status == 'experimental') {selection.reject("don't use experimental candidates of 'org.sample:a}}}// Accept the highest version with a branch of 'testing' or a status of 'milestoall { ComponentSelection selection, IvyModuleDescriptor descriptor, ComponentMet
if (selection.candidate.group == 'org.sample' && selection.candidate.module
if (descriptor.branch != 'testing' && metadata.status != 'milestone') {selection.reject("'org.sample:api' must have testing branch or miles
}
}
}
}
}
}
}

Note that a ComponentSelection argument is always required when declaring a component

Page 279 of 436

selection rule but the metadata arguments are optional.

51.9. 依存関係のキャッシュ

Gradleは、非常に洗練された依存関係のキャッシング機構を持っており、依存関係の解決の際、リモートまでリクエス
また、その際、依存関係解決の正確性、再現性を最大限保証できるような仕組みを備えています。
Gradleの依存関係キャッシュは、二種類のストレージで構成されています。

ダウンロードされたアーティファクトを保存する、ファイルベースのストレージ。pomファイルやivyファイルのよダウンロード済みのアーティファクトを保存するストレージパスには、SHA1のチェックサムが含まれているので、解決済みのメタデータを保存するバイナリストレージ。動的バージョン、モジュールのディスクリプタやアーティ

メタデータのキャッシュとダウンロードしたアーティファクトを別のストレージに分けることで、ファイルのみの透過

Gradleのキャッシュでは、ローカルキャッシュによって問題が隠蔽されるようなことはありませんし、多くのビルドツ

また、その実装は帯域、ストレージ双方において効率的なものです。それにより、Gradleはエンタープライズでのビル

51.9.1. Gradleにおける依存関係キャッシュの重要な機能
51.9.1.1. 分離されたメタデータ・キャッシュ

Gradleは、依存関係を解決した結果を様々な観点から記録し、バイナリ形式でメタデータ・キャッシュに保存します。
メタデータ・キャッシュに保存される情報には以下のようなものがあります。
(1.+のような)動的バージョンを具体的なバージョン(1.2など)に解決したその結果。
それぞれのモジュールの解決済みメタデータ。モジュールのアーティファクトや依存関係など。
それぞれのアーティファクトの、解決済みメタデータ。ダウンロードしたファイルへのポインタを含む。
あるモジュールやアーティファクトがリポジトリに無いことを記録し、存在しないリソースに繰り返しアクセスしに行くことを防ぐ。

メタデータ・キャッシュの全てのエントリには、リポジトリに関する記録が含まれていて、キャッシュの有効期限を制

51.9.1.2. リポジトリキャッシュの独立性

前述の通り、リポジトリにはそれぞれ独立したメタデータ・キャッシュが存在します。リポジトリはURL、種別、レイ
も し そ の リ ポ ジ ト リから、あるモジュールやアーティファクトをまだ解決したことがない場合、Gradleはリポジトリに対してモジュールを「アーティファクトの再利用 」」を参照してください)。

ビルドで指定されたどのリポジトリにも要求されたアーティファクトがない場合、たとえ別のリポジトリのキャッシュ

リポジトリの独立性を保つことで、それぞれのビルドも高度に独立したものにしているのです。これは、従来のビルド

51.9.1.3. アーティファクトの再利用

アーティファクトをダウンロードする前に、Gradleは、そのアーティファクトに結びついたshaファイルをダウンロー

チェックサムをダウンロードできれば、そして既に同じIDとチェックサムを持つアーティファクトが存在すれば、ダウチェックサムをリモートサーバーから取得できない場合、アーティファクトは常にダウンロードされます(既知のアー

Page 280 of 436

Gradleは、別のリポジトリからダウンロードされたアーティファクトだけでなく、Mavenのローカルリポジトリにある

51.9.1.4. チェックサムベースのストレージ

同じ識別子でアーティファクトを要求したのに、それぞれのリポジトリが別のバイナリを返すことがあります。良くあGradleは、SHA1チェックサムに基づいてアーティファクトをキャッシングするので、同じアーティファクトの様々な

これはつまり、あるリポジトリからアーティファクトを解決した際、別のリポジトリのファイルキャッシュが上書きさ

これを、それぞれのリポジトリごとに別個にアーティファクトファイルのキャッシュを持つことなく実現できるのです51.9.1.5. キャッシュのロック

Gradleの依存関係キャッシュは、並列に実行される複数のGradleプロセスから安全に使用できるよう、ファイルベース

このロックは、メタデータバイナリストレージの読み込みや書き込みの際には常に取得されますが、リモートからアー

51.9.2. キャッシングに関するコマンドラインオプション
51.9.2.1. オフライン- - o f f l i n e

オプションを使うと、常にキャッシュされた依存モジュールを使用するようGradleに指示できます。依存モジュールがオフラインで実行されると、Gradleは依存関係を解決するときにネットワークにアクセスしに行くことはありません。
要求されたモジュールが依存関係のキャッシュにない場合は、ビルドは失敗します。

51.9.2.2. リフレッシュ
Gradleの依存関係キャッシュが、設定されたリポジトリの実際の状態と同期が取れていないこともあります。

おそらくは最初のリポジトリ設定が間違っていたか、未変更のモジュールが間違って公開されたのでしょう。キャッシ--refresh-dependenciesオプションを使用してください。
--refresh-dependencies

オプションは、解決済みのモジュールとアーティファクトに対する全てのキャッシュエントリを無視するようGradleに

対象のリポジトリ全てに対して、新規に解決処理が実行されます。動的バージョンは再取得され、モジュールは再解決

ただ、実際にアーティファクトをダウンロードする前に、Gradleは以前ダウンロードしたものが使用できないか確認し

これは、リポジトリで公開されているSHA1と、ダウンロード済みのアーティファクトのSHA1を比較することで行われ51.9.3. 依存関係キャッシュ制御の微調整
キャッシングについて、いくつかの動作は設定でResolutionStrategyを使うことで微調整することができます。

デフォルトでは、Gradleは動的バージョンを24時間キャッシュします。動的バージョンを具体的なバージョンに解決
例51.58 動的バージョンのキャッシュ制御
build.gradle
configurations.all {resolutionStrategy.cacheDynamicVersionsFor 10, 'minutes'}

デフォルトでは、Gradleは変更性モジュールを24時間キャッシュします。変更性モジュールのメタデータとアーティ
Page 281 of 436

例51.59 変更性モジュールのキャッシュ制御
build.gradle
configurations.all {resolutionStrategy.cacheChangingModulesFor 4, 'hours'}

詳しくはAPIドキュメントでResolutionStrategyを参照してください。

51.10. 推移的依存関係を管理するための戦略
多くのプロジェクトがMavenセントラルリポジトリに依存していますが、これが時に問題になることもあります。
Mavenセントラルリポジトリはダウンする可能性もあり、またレスポンスが返るまで長い時間がかかります。

POMファイルに間違った情報を入れているプロジェクトがたくさんあります(たとえば、commons-httpclientはJUnitをruntime依存関係に設定しています)。

「ただ一つの正当な依存関係」というものが決められないようなプロジェクトもたくさんあります(つまり、POMのもしプロジェクトがMavenセントラルリポジトリに依存しているのであれば、カスタムリポジトリを追加する必要があ
まだMavenセントラルにアップロードされていない依存関係が必要になった。
You want to deal properly with invalid metadata in a Maven Central POM file.
MavenセントラルのPOMファイルに誤ったメタデータが含まれていた。

プロジェクトをビルドしたいと思う人々がいて、彼らをMavenセントラルのダウンタイムや、時折発生する長時間

使用しているライブラリをバージョン管理システムに入れているプロジェクトがありますが、それはこのあたりが理由

Gitのような分散バージョン管理システムを使っている場合は、リポジトリにライブラリを格納したくないかもしれま

これらを複合させた戦略をとることもあります。POMファイルの不良メタデータをなんとかしたい、カスタムPOMを

もちろんjarの取得だけをMaven2リポジトリやカスタムリポジトリから行うこともできますし、推移的な依存関係もそ

51.10.1. 暗黙的な推移的依存関係
The trick is to use only artifact dependencies and group them in lists. This will directly express
your first level dependencies and your transitive dependencies (see 「オプション属性 」). The
problem with this is that Gradle dependency management will see this as specifying all
dependencies as first level dependencies. The dependency reports won't show your real
dependency graph and the compile task uses all dependencies, not just the first level
dependencies. All in all, your build is less maintainable and reliable than it could be when using
client modules, and you don't gain anything.
そのトリックは、アーティファクトオンリー記法を使い、それらをリストでグループ化するというものです。
この方法でも、なにが直接の依存関係で、何が推移的な依存関係なのか、なんとか表現することはできました(「オプション属性」を参照してください)。

しかし、この方法の欠点は、Gradleの依存関係管理システムが、すべての依存関係を直接の依存関係として取り扱ってPage 282 of 436

c

o

m

p

i

l

e

タスクでも、直接的な依存関係だけでなく、すべての依存関係が使われてしまうことになります。クライアントモジュ[ 22 ]

Gradleはマルチプロジェクトの部分ビルドをサポートしています(57章

マルチプロジェクトのビルド参照)。
[

2

3

]

http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-project-relationships.html[24]

ivyパターンについてはhttp://ant.apache.org/ivy/history/latest-milestone/concept.html

で詳細な情報を知ることができます。
[25] Mavenセントラルのダウンからプロジェクトを防御したい場合は、もう少し複雑になります。
おそらく、そのためにリポジトリのプロキシをセットアップしたくなると思います。

エンタープライズ環境では珍しくないシチュエーションと言えますが、オープンソースプロジェクトの場合は、やりす

Page 283 of 436

52
アーティファクトの公開
この章は、Gradle1.0の段階で使用されている既存の公開システムについて書かれています。Gradle1.3からは、公開処理に新しい仕組みが導入されました。
この仕組みは現在試験的な段階にあり、まだ完成していませんが、Gradleの公開処理をより強力にする新しい概念、機能がいくつか取り入れ
新しい公開プラグインについては、Chapter 65, Ivy Publishing (new)およびChapter 66,
Maven

Publishing(new)に詳しく記載されています。ぜひ試用してみてください。何かあればフィードバックしてもらえると幸いです。

52.1. はじめに

この章では、プロジェクトが公開するアーティファクト(成果物)の定義方法と取り扱い(アップロードする方法など)に

52.2.
アーティファクトとコンフィギュレーション

依存関係と同じように、アーティファクトもコンフィギュレーションによってグループ化されます。実際、コンフィギ
Gradleは、プロジェクト内のすべてのコンフィギュレーションに対して、upload

タスクとbuild[ 2 7 ]タ ス ク を 提 供 し ま す 。

これらのタスクを実行すると、対象のコンフィギュレーションに属しているアーティファクトをビルドしたり、アップ
表23.5「Javaプラグイン-

依存関係のコンフィギュレーション」に、Javaプラグインが追加するコンフィギュレーションの一覧を載せています。これらのうち、アーティファクトを使
a

r

c

h

i

v

e

s

コンフィギュレーションは、プロジェクトのアーティファクトを含めるための標準のコンフィギュレーションです。J「プロジェクトライブラリについての追記事項」では、runtime

コンフィギュレーションについて詳しく解説します。また、アーティファクトを追加するための独自コンフィギュレー

Page 284 of 436

52.3. アーティファクトの宣言
52.3.1. アーカイブタスク・アーティファクト
アーカイブタスクを使ってアーティファクトを宣言できます。
例52.1 アーカイブタスクを使ってアーティファクトを宣言する
build.gradle
task myJar(type: Jar)
artifacts {archives myJar}

重要なことですが、独自のアーカイブ作成をビルドに組み込んでも、そのアーカイブが自動的になんらかのコンフィグ

52.3.2. ファイル・アーティファクト
アーティファクトは、ファイルで宣言することもできます。
例52.2 アーティファクトをファイルで宣言する
build.gradle
def someFile = file('build/somefile.txt')
artifacts {archives someFile}

Gradleは、ファイル名を元にアーティファクトのプロパティを決定します。このプロパティは、以下のようにしてカス
例52.3 アーティファクトのカスタマイズ
build.gradle
task myTask(type: MyTaskType) {destFile = file('build/somefile.txt')}
artifacts {archives(myTask.destFile) {name 'my-artifact'
type 'text'
builtBy myTask}}

ファイルでアーティファクトを宣言する際には、Mapスタイルの文法を使うこともできます。そのMapにはファイルを

Page 285 of 436

例52.4 ファイルでアーティファクトを宣言するMapスタイルの文法
build.gradle
task generate(type: MyTaskType) {destFile = file('build/somefile.txt')}
artifacts {archives file: generate.destFile, name: 'my-artifact', type: 'text', builtBy: generate}

52.4. アーティファクトの公開

先ほど、すべてのコンフィギュレーションにアップロード用のタスクが作成されることを説明しました。しかし、実際
「

リ

ポ

ジ

ト

リ

」

)が、勝手にアップロードに使用されることはありません。実際、それらのリポジトリには、ダウンロードしか許して例52.5 アップロードタスクの設定
build.gradle
repositories {flatDir {name "fileRepo"
dirs "repo"}}
uploadArchives {repositories {add project.repositories.fileRepo
ivy {credentials {username "username"password "pw"}url "http://repo.mycompany.com"}}}

この例のように、定義済みのリポジトリを参照することもできますし、新しくリポジトリ定義を作って追加することも「 I v y リ ゾ ル バ に つ い て」のときと同じように、アップロードでもすべてのIvyリポジトリリゾルバを使うことができます。

アップロード先のリポジトリ定義に複数のレイアウトパターンが含まれている場合、どのパターンに従ってファイルを
デフォルトでは、Gradleは url パラメーターを参照します。 layoutが定義されていれば、それも併せて使用します。

urlPage 286 of 436

パラメーターが未定義の場合は、定義されているartifactPatternのうち最初のものがアップロードに使用され、また、定義されているivyPatternのうち最初のものがivyファイルのアップロードに使用されます。
Mavenリポジトリへのアップロードについては、「Mavenリポジトリとの相互作用」
をご参照ください。

52.5.
プロジェクトライブラリについての追記事項

プロジェクトがライブラリとして使用される場合、そのライブラリのアーティファクトは何か、アーティファクトが依
runtimeというコンフィギュレーションを追加します。これは、公開したいアーティファクトは
r

u

n

t

i

m

e

依存関係に依存しているはずだ、という暗黙的な仮定の上での仕様ですが、もちろんこのあたりの設定は完全にカスタ

誰かがあなたのプロジェクトをライブラリとして使いたいとしましょう。そのときすべきことは、あなたのプロジェク
c o n f i g u r a t i o nというプロパティを指定できるようになっています。もしこのプロパティが指定されていなければ、
defaultコンフィギュレーションが使用されます(「依存するコンフィギュレーションの指定」を ご 参 照 く だ さ い ) 。

あるプロジェクトがライブラリとして使われるのには、二つのケースがあります。マルチプロジェクトの中からライブ「Mavenリポジトリとの相互作用」をご覧ください。

[
正確に言うと、Baseプラグインがこれらのタスクを提供します。Baseプラグインは、Javaプラグインを使うと自動的
2
7]Page 287 of 436

53
Mavenプラグイン
この章は執筆途中です。

Mavenプラグインは、Mavenリポジトリへのアーティファクトのデプロイに対するサポートを追加します。

53.1. 使用方法
Mavenプラグインを使うには、ビルドスクリプトに以下を含めます:
例53.1 Mavenプラグインの利用
build.gradle
apply plugin: 'maven'53.2. タスク
Mavenプラグインは以下のタスクを定義しています:
表53.1 Mavenプラグイン - タスク
タスク名

依存先

型

説明

install

関連するアーカイブをビルドするすべてのタスク

UploadMavenメタデータの生成を含め、関連

デフォルトではinstallタスクはarchiv

このコンフィグレーションのデフォル

ローカルリポジトリへのインストール
を参照のこと。

53.3. 依存関係管理
Mavenプラグインはいかなる依存関係のコンフィグレーションも定義していません。

Page 288 of 436

53.4. 規約プロパティ
Mavenプラグインは以下の規約プロパティを定義しています:
表53.2 Mavenプラグイン - プロパティ
プロパティ名型

デフォルト値説明

pomDirName

Stringpoms

生成されたPOMを書き出すディ

pomDirFile (read-only)

buildDir/pomDirName
生成されたPOMを書き出すディconf2ScopeMappings

Conf2ScopeMappingContainern/aGradleコンフィグレーションから「依存関係のマッピング」参照。

これらのプロパティは規約オブジェクトMavenPluginConventionが提供します。

53.5. 規約メソッド
MavenプラグインはPOM生成のためのファクトリメソッドを提供します。
これはMavenリポジトリへのアップロードを必要としないPOMが必要なときに便利です。
例53.2 スタンドアロンPOMの生成
build.gradle
task writeNewPom << {pom {project {inceptionYear '2008'
licenses {license {name 'The Apache Software License, Version 2.0'
url 'http://www.apache.org/licenses/LICENSE-2.0.txt'
distribution 'repo'}}}}.writeTo("$buildDir/newpom.xml")}

そのほか、Gradleは多言語Mavenと同じビルダー文法をサポートします。
POMオブジェクトについてもっと学ぶためには、

GradleMaven

MavenPomを参照してください。また、

MavenPluginConventionも有用です。

Page 289 of 436

53.6. Mavenリポジトリとの相互作用
53.6.1. はじめに

Gradleでは、リモートMavenリポジトリにデプロイすることも、ローカルMavenリポジトリにインストールすること
これにはすべてのMavenメタデータの操作が含まれ、Mavenスナップショットに対しても適用できます。
実際、Gradleのデプロイは、ネィティブのMaven
Antタスクを内部で利用するのと同じく、100%Maven互換です。
もしPOMがないとしたら、Mavenリポジトリへのデプロイは楽しさ半減です。
幸運なことに、GradleはPOM自身の持つ依存関係の情報を用いて、このPOMを生成してくれます

53.6.2. Mavenリポジトリへのデプロイ
プロジェクトが単にデフォルトのJARファイルを生成するだけだとしましょう。
このJARファイルをリモートMavenリポジトリにデプロイしたいとします。
例53.3 リモートMavenリポジトリへのファイルアップロード
build.gradle
apply plugin: 'maven'uploadArchives {repositories {mavenDeployer {repository(url: "file://localhost/tmp/myRepo/")}}}

これが全てです。

uploadArchives タスクを呼び出すことでPOMが生成され、アーティファクトとPOMが指定されたリポジトリにデプロイされます。
file以外のプロトコルをサポートする必要があるなら、他にも少しやるべきことがあります。
この場合、処理を委譲するネィティブMavenコードが追加のライブラリを必要とします。
どのライブラリが必要になるかは、必要なプロトコルによります。
利用可能なプロトコルと対応するライブラリは表53.3「Mavenデプロイに対するプロトコルJAR」に リ ス ト ア ッ プ さ れ て い ま す(推移的な依存関係を持つこれらのライブラリは、さらに推移的な依存関係を持ちます)。

[29]

例えば、SSHプロトコルを使うには次のようにできます:

Page 290 of 436

例53.4 SSH経由でのファイルアップロード
build.gradle
configurations {deployerJars}
repositories {mavenCentral()}dependencies {
deployerJars "org.apache.maven.wagon:wagon-ssh:2.2"}
uploadArchives {repositories.mavenDeployer {configuration = configurations.deployerJars
repository(url: "scp://repos.mycompany.com/releases") {authentication(userName: "me", password: "myPassword")}}}

Mavenデプロイヤーには多くのコンフィグレーションオプションがあります。
コンフィグレーションはGroovyビルダーで行うことができます。 このツリーのすべての要素はJava
beansです。

単純な属性を設定するためには、beanの要素にmapを渡してやります。

親要素に別のbean要素を追加するには、クロージャを使います。

上記の例では、 repository とauthentication がbean要素です。 利用可能なbean要素と対応するクラスのJavaDocへのリンクは、
表53.4「MavenDeployerのコンフィグレーション要素」 にリストアップされています。
JavaDocでは特定の要素にセットできる属性を確認できます。
Mavenではリポジトリに加えて、オプションでスナップショットリポジトリを定義できます。
スナップショットリポジトリが定義されていない場合、 リリースとスナップショットの両方がrepository
要素で指定された先にデプロイされます。 そうでない場合は、スナップショットはsnapshotRepository
要素で指定された先にデプロイされます。
表53.3 Mavenデプロイに対するプロトコルJAR
プロトコル

ライブラリ

http

org.apache.maven.wagon:wagon-http:2.2

sshorg.apache.maven.wagon:wagon-ssh:2.2

ssh-externalorg.apache.maven.wagon:wagon-ssh-external:2.2

ftp

org.apache.maven.wagon:wagon-ftp:2.2

webdavorg.apache.maven.wagon:wagon-webdav:1.0-beta-2

file

-

Page 291 of 436

表53.4 MavenDeployerのコンフィグレーション要素
要素

Javadocroot

MavenDeployer

repositoryorg.apache.maven.artifact.ant.RemoteRepository

authenticationorg.apache.maven.artifact.ant.Authentication

releasesorg.apache.maven.artifact.ant.RepositoryPolicy

snapshotsorg.apache.maven.artifact.ant.RepositoryPolicy

proxyorg.apache.maven.artifact.ant.Proxy

snapshotRepositoryorg.apache.maven.artifact.ant.RemoteRepository

53.6.3. ローカルリポジトリへのインストール
Mavenプラグインはプロジェクトにinstallタスクを追加します。

このタスクはarchives

コンフィグレーションのすべてのarchivesタスクに依存します。
これらのアーカイブはローカルMavenリポジトリにインストールされます。
もし、ローカルリポジトリの場所がMavenのsettings.xml
で再定義されていたら、このタスクはそれを反映します。

53.6.4. MavenのPOM生成
Mavenリポジトリにアーティファクトをデプロイする際、Gradleは自動的にデプロイ用のPOMを生成します。
POMにデフォルトで設定される groupId 、 artifactId 、 version 、packaging
要素の値は以下の表を参照してください。

dependency

要素は、プロジェクトで宣言されている依存関係設定から作成されます。
表53.5 Maven POM生成のためのデフォルト値
Maven要素

デフォルト値

groupId

project.groupartifactId

uploadTask.repositories.mavenDeployer.pom.artifactId (if set) orarchiveTask.baseName.

versionproject.version

packagingarchiveTask.extension

ここで、uploadTaskとarchiveTask
は、それぞれ、実際にアーカイブをアップロードするタスクと生成するタスクのことを指しています(例えば、
uploadArchivesとjar)。 archiveTask.baseNameのデフォルト値はproject.archivesBaseName
で、そのデフォルト値はproject.nameです。

archiveTask.baseNameをデフォルト以外の値に設定したときは、uploadTask.repositories.mavenDeploを同じ値に設定することを忘れないでください。
Page 292 of 436

さもないと、近いうちに、同じビルド内の他プロジェクトで生成されたPOMから、プロジェクトが誤ったartifact
IDで参照されてしまうかもしれません。

生成されたPOMは、<buildDir>/pomsに出力されます。そのPOMは、さらにMavenPom
APIでカスタマイズすることができます。

例えば、Mavenにデプロイするアーティファクトには、Gradleで生成するアーティファクトとは別のバージョンと名前
例53.5 pomのカスタマイズ
build.gradle
uploadArchives {repositories {mavenDeployer {repository(url: "file://localhost/tmp/myRepo/")pom.version = '1.0Maven'pom.artifactId = 'myMavenName'}}}

POMに追加的な内容を加えるには、pom.projectビルダーを使います。

このビルダーを使えば、Maven POMリファレンスに載っている全ての要素を追加することができます。
例53.6 ビルダースタイルでpomをカスタマイズする
build.gradle
uploadArchives {repositories {mavenDeployer {repository(url: "file://localhost/tmp/myRepo/")pom.project {licenses {license {name 'The Apache Software License, Version 2.0'
url 'http://www.apache.org/licenses/LICENSE-2.0.txt'
distribution 'repo'
}
}
}
}
}
}

注意:

groupId 、 artifactId 、 version および packaging

は、常にpomオブジェクトに直接設定するべきです。

Page 293 of 436

例53.7 自動生成された内容を変更する
build.gradle
def installer = install.repositories.mavenInstaller
def deployer = uploadArchives.repositories.mavenDeployer[installer, deployer]*.pom*.whenConfigured {pom ->pom.dependencies.find {dep -> dep.groupId == 'group3' && dep.artifactId == 'runtime' }.optio}

2つ以上のアーティファクトを公開したい場合は、すこし難しくなります。
「複数アーティファクトを含むプロジェクト」を参照してください。
Mavenインストーラー(「ローカルリポジトリへのインストール」
参照)の設定をカスタマイズするには、次のようにします。
例53.8 Mavenインストーラーのカスタマイズ
build.gradle
install {repositories.mavenInstaller {pom.version = '1.0Maven'pom.artifactId = 'myName'}}

53.6.4.1. 複数アーティファクトを含むプロジェクト
Mavenはプロジェクトあたり1つのアーティファクトしか扱うことができません。
これはMavenのPOMの構造を反映しています。

我々は、プロジェクトが2つ以上のアーティファクトを含むことが合理的であるシチュエーションも多いと考えていま
この場合、複数のPOMを生成する必要があります。

このような状況では、Mavenリポジトリに発行するそれぞれのアーティファクトを明示的に宣言する必要があります。
MavenDeployerおよびMavenInstallerが、これに対するAPIを提供します:
例53.9 複数POMの生成
build.gradle
uploadArchives {repositories {mavenDeployer {repository(url: "file://localhost/tmp/myRepo/")addFilter('api') {artifact, file ->artifact.name == 'api'}
addFilter('service') {artifact, file ->artifact.name == 'service'}pom('api').version = 'mySpecialMavenVersion'}}}

Page 294 of 436

発行するそれぞれのアーティファクトに対してfilterを宣言する必要があります。
filterではGradleアーティファクトが受け付ける論理式を定義します。
それぞれのfilterは関連付けられたPOMを持ち、コンフィグレーション可能です。
より詳しく学ぶためには、PomFilterContainerおよび関連クラスを参照してください。

53.6.4.2. 依存関係のマッピング
Mavenプラグインは、JavaプラグインとWarプラグインによって追加されたGradleコンフィグレーションとMavenスコープとの間のデフォルトのマッピングを構成します。
ほとんどの場合これに触れる必要はなく、この節は読み飛ばしていただいてかまいません。
マッピングは次のように動作します。
コンフィグレーションはただ一つのスコープにのみマップできます。
異なるコンフィグレーションは一つ、もしくは異なるスコープにマップできます。
特定のコンフィグレーション-スコープマッピングに優先度を割り当てることもできます。 詳しくは
Conf2ScopeMappingContainerを参照してください。
マッピングコンフィグレーションにアクセスするには次のようにします:
例53.10 マッピングコンフィグレーションへのアクセス
build.gradle
task mappings << {println conf2ScopeMappings.mappings}

Gradleのexcludeルールは、可能であればMavenのexcludeに変換されます。
この変換は、Gradleのexcludeルールにおいてgroupとモジュール名の両方が指定されている場合に可能となります(Ivyとは対照的に、Mavenは両方を必要とするため)。
コンフィグレーション毎のexcludeも、変換可能であればMavenのPOMに含まれます。

[29] これらは将来のリリースで標準サポートされる予定です

Page 295 of 436

54
署名プラグイン
署名プラグインは、ビルドされたファイルやアーティファクトに電子署名を行う機能を追加します。

この電子署名は、いつその署名がされたのかなどの情報だけでなく、署名されたアーティファクトを誰がビルドしたの
現在署名プラグインがサポートしているのは、PGP署名(
Mavenセントラルリポジトリに公開するのに必要な署名形式)の生成のみです。

54.1. 使用方法
署名プラグインを使うには、以下の行をビルドスクリプトに追加します。
例54.1 署名プラグインの使用
build.gradle
apply plugin: 'signing'

54.2. 署名者の資格情報
PGP署名を作成するには、キーペアが必要です(GnuPGツールを使用してキーペアを作成する手順については、GnuPGのHOWTO文書
で 見 つ け る こ と が で き ま す ) 。
署名プラグインでは、このキー情報、つまり以下の三つの情報を設定することができます。
公開鍵ID(8文字の16進数文字列)
秘密鍵を保存したキーリングファイルの絶対パス
秘密鍵を保護するパスフレーズ
これらの情報は、それぞれsigning.keyId、signing.secretKeyRingFile、signing.passwordというプロジェクトプロパティで設定する必要があります。 良いプラクティスは、ユーザーのgradle.properties
ファイル(「Gradleプロパティとシステムプロパティ」
で解説されています)にこれらを保存することです。

signing.keyId=24875D73
signing.password=secretsigning.secretKeyRingFile=/Users/me/.gnupg/secring.gpg

これらの情報をgradle.properties

Page 296 of 436

ファイルで設定するのが環境の問題で難しい場合は、手動でプロジェクトのプロパティに設定させることも可能です。

import org.gradle.plugins.signing.Sign
gradle.taskGraph.whenReady { taskGraph ->if (taskGraph.allTasks.any { it instanceof Sign }) {// Use Java 6's console to read from the console (no good for// a CI environment)
Console console = System.console()
console.printf "\n\nWe have to sign some things in this build." +"\n\nPlease enter your signing details.\n\n"def id = console.readLine("PGP Key Id: ")def file = console.readLine("PGP Secret Key Ring File (absolute path): ")def password = console.readPassword("PGP Private Key Password: ")allprojects { ext."signing.keyId" = id }allprojects { ext."signing.secretKeyRingFile" = file }allprojects { ext."signing.password" = password }console.printf "\nThanks.\n\n"}}54.3. 署名対象を指定する

どのように署名するか(つまり署名者情報の指定)だけでなく、何を署名するかというのも設定しなければなりません。
署名プラグインは、署名すべきタスクやコンフィギュレーションを指定するためのDSLを提供しています。

54.3.1. コンフィグレーションに署名するあるコンフィグレーション内のアーティファクトに対して署名をしたいというのは良くあることです。例えば、
Javaプラグインは、jarをビルドするよう定義し、そのjarをアーティファクトとしてarchives
コンフィグレーションに追加します。

署名DSLを使えば、このコンフィグレーションに含まれる全てのアーティファクトに署名するよう設定できるのです。
例54.2 コンフィグレーションに署名する
build.gradle
signing {sign configurations.archives}

これにより、「signArchives」という名前のタスク(Sign型)が追加されます。 このタスクは、archivesのアーティファクトを全て(必要なら)ビルドし、それからそれらのアーティファクト用に署名を作成します。署名ファ

Page 297 of 436

例54.3 コンフィグレーションの出力に署名する
gradle signArchives の出力> gradle signArchives:compileJava:processResources:classes:jar:signArchives
BUILD SUCCESSFUL
Total time: 1 secs

54.3.2. タスクに署名する

署名したいものが、コンフィギュレーションに含まれていないというケースもあります。このケースでは、署名するア
例54.4 タスクを署名する
build.gradle
task stuffZip (type: Zip) {baseName = "stuff"
from "src/stuff"}
signing {sign stuffZip}

これにより、「signStuffZip」という名前のタスク(Sign型)がプロジェクトに追加されます。

このタスクは、入力物を(必要なら)ビルドしてアーカイブを作成し、それからそのアーカイブに署名します。署名ファ
例54.5 タスクの出力に署名する
gradle signStuffZip の出力> gradle signStuffZip:stuffZip:signStuffZip
BUILD SUCCESSFUL
Total time: 1 secs

「署名可能」なタスクは、何らかのアーカイブを作成するものに限られます。この種類のタスクには、
TarやZip、Jar、War、Earがあります。

54.3.3. 条件付き署名

よくあるビルドのパターンに、ある特定の条件下に限ってアーティファクトに署名する、というものがあります。例え
これは、署名DSLを必要なロジックで囲めば実現できます。
Page 298 of 436

例54.6 条件付き署名
build.gradle
version = '1.0-SNAPSHOT'
ext.isReleaseVersion = !version.endsWith("SNAPSHOT")signing {required { isReleaseVersion && gradle.taskGraph.hasTask("uploadArchives") }sign configurations.archives}

In this example, we only want to require signing if we are building a release version and we aregoing to publish it. Because we are inspecting the task graph to determine if we are going to be
publishing, we must set the signing.required property to a closure to defer the evaluation.
See SigningExtension.setRequired() for more information.

54.4. 署名を公開する
署名DSLで署名対象を指定すると、生成された署名は自動的にsignatures
コンフィギュレーションと archives コンフィギュレーションに追加されます。
つまり、署名をアーティファクトと一緒に配布用リポジトリに公開したい場合は、通常通りただuploadArchives
タスクを実行すればいいということです。

54.5. POMファイルに署名する
When deploying signatures for your artifacts to a Maven repository, you will also want to sign the
published

POM

file.

The

signingpluginadds

asigning.signPom()(see:

SigningExtension.signPom()) method that can be used in the beforeDeployment() blockin your upload task configuration.
例54.7 Signing a POM for deploymentbuild.gradle
uploadArchives {repositories {mavenDeployer {beforeDeployment { MavenDeployment deployment -> signing.signPom(deployment) }}}}When signing is not required and the POM cannot be signed due to insufficient configuration(i.e. no credentials for signing) then the signPom() method will silently do nothing.

Page 299 of 436

55
Building native binaries
The Gradle support for building native binaries is currently incubating. Please be awarethat the DSL and other configuration may change in later Gradle versions.

The various native binary plugins add support for building native software components, such as
executables or shared libraries, from code written in C++, C and other languages. While many
excellent build tools exist for this space of software development, Gradle offers developers its
trademark power and flexibility together with dependency management practices more
traditionally found in the JVM development space.

55.1. Supported languages
The following source languages are currently supported:C
C++
Objective-C
Objective-C++
Assembly
Windows resources

55.2. Tool chain support
Gradle offers the ability to execute the same build using different tool chains. When you build anative binary, Gradle will attempt to locate a tool chain installed on your machine that can build
the binary. You can fine tune exactly how this works, see Section 55.14, “Tool chains” fordetails.
The following tool chains are supported:

Page 300 of 436

Operating

Tool Chain

Notes

System
Linux

GCC

Linux

Clang

Mac OS X

XCodeUses the Clang tool chain bundled with XCode.

Windows

Visual C++

Windows XP and later, Visual C++ 2010 and later.

Windows

GCC with Cywin

Windows XP and later.

32
Windows

GCC withWindows XP and later. Mingw-w64 is currently not

MinGW

supported.

The following tool chains are unofficially supported. They generally work fine, but are not tested
continuously:
Operating System

Tool Chain

Mac OS X

GCC from Macports

Mac OS X

Clang from Macports

Windows

GCC with Cywin 64

UNIX-like

GCC

UNIX-like

Clang

Notes

Windows XP and later.

55.3. Tool chain installation
Note that if you are using GCC then you currently need to install support for C++, even if
you are not building from C++ source. This caveat will be removed in a future Gradle
version.

To build native binaries, you will need to have a compatible tool chain installed:

55.3.1. Windows
To build on Windows, install a compatible version of Visual Studio. The native plugins will
discover the Visual Studio installations and select the latest version. There is no need to messaround with environment variables or batch scripts. This works fine from a Cygwin shell or the
Windows command-line.
Alternatively, you can install Cygwin with GCC or MinGW. Clang is currently not supported.

Page 301 of 436

55.3.2. OS X
To build on OS X, you should install XCode. The native plugins will discover the XCodeinstallation using the system PATH.
The native plugins also work with GCC and Clang bundled with Macports. To use one of the
Macports tool chains, you will need to make the tool chain the default using the port selectcommand and add Macports to the system PATH.

55.3.3. LinuxTo build on Linux, install a compatible version of GCC or Clang. The native plugins will discover
GCC or Clang using the system PATH.

55.4. Component model
To build native binaries using Gradle, your project should define one or more native
components . Each component represents either an executable or a library that Gradle should
build. A project can define any number of components. Gradle does not define any components
by default.
For each component, Gradle defines a source set for each language that the component can bebuilt from. A source set is essentially just a set of source directories containing source files. For
example, when you apply the c plugin and define a library called helloworld, Gradle willdefine, by default, a source set containing the C source files in the src/helloworld/c
directory. It will use these source files to build the helloworld library. This is described in moredetail below.
For each component, Gradle defines one or more binaries as output. To build a binary, Gradle
will take the source files defined for the component, compile them as appropriate for the source
language, and link the result into a binary file. For an executable component, Gradle canproduce executable binary files. For a library component, Gradle can produce both static andshared library binary files. For example, when you define a library called helloworld and build
on Linux, Gradle will, by default, produce libhelloworld.so and libhelloworld.a binaries.
In many cases, more than one binary can be produced for a component. These binaries may vary
based on the tool chain used to build, the compiler/linker flags supplied, the dependencies
provided, or additional source files provided. Each native binary produced for a component isreferred to as variant . Binary variants are discussed in detail below.

55.5. Building a library
To build either a static or shared native library, you define a library component in the libraries
container. The following sample defines a library called hello:

Page 302 of 436

Example 55.1. Defining a library component
build.gradle
libraries {
hello {}}

A library component is represented using NativeLibrarySpec. Each library component can
produce at least one shared library binary (SharedLibraryBinarySpec) and at least one static
library binary (StaticLibraryBinarySpec).

55.6. Building an executableTo build a native executable, you define an executable component in the executables
container. The following sample defines an executable called main:
Example 55.2. Defining executable components
build.gradle
executables {main {}}An executable component is represented using NativeExecutableSpec. Each executablecomponent can produce at least one executable binary (NativeExecutableBinarySpec).
For each component defined, Gradle adds a FunctionalSourceSet with the same name. Eachof these functional source sets will contain a language-specific source set for each of thelanguages supported by the project.

55.7. Tasks
For each NativeBinarySpec that can be produced by a build, a single lifecycle task isconstructed that can be used to create that binary, together with a set of other tasks that do theactual work of compiling, linking or assembling the binary.
Component TypeNative Binary Type

Lifecycle task

Location of createdbinaryNativeExecutableSpec

NativeExecutableBinarySpec${component.name}Executable${project.build

NativeLibrarySpec

SharedLibraryBinarySpec${component.name}SharedLibrary${project.build

NativeLibrarySpec

StaticLibraryBinarySpec${component.name}StaticLibrary${project.build

Page 303 of 436

55.7.1. Working with shared libraries
For each executable binary produced, the cpp plugin provides an install${binary.name}task, which creates a development install of the executable, along with the shared libraries it
requires. This allows you to run the executable without needing to install the shared libraries intheir final locations.

55.8. Finding out more about your project
Gradle provides a report that you can run from the command-line that shows some details about
the components and binaries that your project produces. To use this report, just run gradle components. Below is an example of running this report for one of the sample projects:

Page 304 of 436

Example 55.3. The components report
gradle components の出力> gradle components:components-----------------------------------------------------------Root project-----------------------------------------------------------Native library 'hello'---------------------Source sets
C++ source 'hello:cpp'
src/hello/cpp
Binaries
Shared library 'hello:sharedLibrary'build using task: :helloSharedLibraryplatform: current
build type: debug
flavor: default
tool chain: Tool chain 'clang' (Clang)shared library file: build/binaries/helloSharedLibrary/libhello.dylib
Static library 'hello:staticLibrary'build using task: :helloStaticLibraryplatform: current
build type: debug
flavor: default
tool chain: Tool chain 'clang' (Clang)static library file: build/binaries/helloStaticLibrary/libhello.a
Native executable 'main'-----------------------Source sets
C++ source 'main:cpp'
src/main/cpp
Binaries
Executable 'main:executable'build using task: :mainExecutable
platform: current
build type: debug
flavor: default
tool chain: Tool chain 'clang' (Clang)
executable file: build/binaries/mainExecutable/main

Note: currently not all plugins register their components, so some components may not be visible
BUILD SUCCESSFUL
Total time: 1 secs

Page 305 of 436

55.9. Language support
Presently, Gradle supports building native binaries from any combination of source languages
listed below. A native binary project will contain one or more named FunctionalSourceSet
instances (eg 'main', 'test', etc), each of which can contain LanguageSourceSets containing
source files, one for each language.
CC++
Objective-C
Objective-C++
Assembly
Windows resources

55.9.1. C++ sources
C++ language support is provided by means of the 'cpp' plugin.
Example 55.4. The 'cpp' pluginbuild.gradle
apply plugin: 'cpp'

C++ sources to be included in a native binary are provided via a CppSourceSet, which defines
a set of C++ source files and optionally a set of exported header files (for a library). By default,
for any named component the CppSourceSet contains .cpp source files in src/${name}/cpp,
and header files in src/${name}/headers.
While the cpp plugin defines these default locations for each CppSourceSet, it is possible toextend or override these defaults to allow for a different project layout.
Example 55.5. C++ source set
build.gradle
sources {main {
cpp {source {srcDir "src/source"
include "**/*.cpp"}}}}

For a library named 'main', header files in src/main/headers are considered the “public” or“exported” headers. Header files that should not be exported should be placed inside the src/main/cpp
directory (though be aware that such header files should always be referenced in a mannerPage 306 of 436

relative to the file including them).

55.9.2. C sources
C language support is provided by means of the 'c' plugin.
Example 55.6. The 'c' pluginbuild.gradle
apply plugin: 'c'C sources to be included in a native binary are provided via a CSourceSet, which defines a setof C source files and optionally a set of exported header files (for a library). By default, for any
named component the CSourceSet contains .c source files in src/${name}/c, and header
files in src/${name}/headers.
While the c plugin defines these default locations for each CSourceSet, it is possible to extend
or override these defaults to allow for a different project layout.
Example 55.7. C source set
build.gradle
sources {hello {c {source {srcDir "src/source"
include "**/*.c"}exportedHeaders {srcDir "src/include"}}}}

For a library named 'main', header files in src/main/headers are considered the “public” or“exported” headers. Header files that should not be exported should be placed inside the src/main/c
directory (though be aware that such header files should always be referenced in a manner
relative to the file including them).

55.9.3. Assembler sources
Assembly language support is provided by means of the 'assembler' plugin.
Example 55.8. The 'assembler' pluginbuild.gradle
apply plugin: 'assembler'

Page 307 of 436

Assembler sources to be included in a native binary are provided via a AssemblerSourceSet,
which defines a set of Assembler source files. By default, for any named component theAssemblerSourceSet contains .s source files under src/${name}/asm.

55.9.4. Objective-C sources
Objective-C language support is provided by means of the 'objective-c' plugin.
Example 55.9. The 'objective-c' pluginbuild.gradle
apply plugin: 'objective-c'

Objective-C sources to be included in a native binary are provided via a ObjectiveCSourceSet, which defines a set of Objective-C source files. By default, for any named component the
ObjectiveCSourceSet contains .m source files under src/${name}/objectiveC.

55.9.5. Objective-C++ sources
Objective-C++ language support is provided by means of the 'objective-cpp' plugin.
Example 55.10. The 'objective-cpp' pluginbuild.gradle
apply plugin: 'objective-cpp'

Objective-C++ sources to be included in a native binary are provided via a
ObjectiveCppSourceSet, which defines a set of Objective-C++ source files. By default, for any

named component the ObjectiveCppSourceSet contains .mm source files under src/${name}/objectiveCp.

55.10. Configuring the compiler, assembler
and linker
Each binary to be produced is associated with a set of compiler and linker settings, which
include command-line arguments as well as macro definitions. These settings can be applied toall binaries, an individual binary, or selectively to a group of binaries based on some criteria.

Page 308 of 436

Example 55.11. Settings that apply to all binaries
build.gradlebinaries.all {// Define a preprocessor macro for every binary
cppCompiler.define "NDEBUG"// Define toolchain-specific compiler and linker options
if (toolChain in Gcc) {cppCompiler.args "-O2", "-fno-access-control"
linker.args "-Xlinker", "-S"}if (toolChain in VisualCpp) {cppCompiler.args "/Zi"linker.args "/DEBUG"}}

Each binary is associated with a particular NativeToolChain, allowing settings to be targetedbased on this value.
It is easy to apply settings to all binaries of a particular type:
Example 55.12. Settings that apply to all shared libraries
build.gradle// For any shared library binaries built with Visual C++,// define the DLL_EXPORT macrobinaries.withType(SharedLibraryBinarySpec) {if (toolChain in VisualCpp) {cCompiler.args "/Zi"
cCompiler.define "DLL_EXPORT"}}

Furthermore, it is possible to specify settings that apply to all binaries produced for a particular executableor library component:

Page 309 of 436

Example 55.13. Settings that apply to all binaries produced for the 'main' executable component
build.gradle
executables {main {
binaries.all {if (toolChain in VisualCpp) {assembler.args "/Zi"} else {assembler.args "-g"}}}}sources {i386_masm {asm(AssemblerSourceSet) {source.srcDir "src/main/asm_i386_masm"}}
i386_gcc {asm(AssemblerSourceSet) {source.srcDir "src/main/asm_i386_gcc"}}}

The example above will apply the supplied configuration to all executable binaries built.
Similarly, settings can be specified to target binaries for a component that are of a particular
type: eg all shared libraries for the main library component.
Example 55.14. Settings that apply only to shared libraries produced for the 'main' library component
build.gradle
libraries {main {
binaries.withType(SharedLibraryBinarySpec) {// Define a preprocessor macro that only applies to shared libraries
cppCompiler.define "DLL_EXPORT"}}}

55.11. Windows Resources
When using the VisualCpp tool chain, Gradle is able to compile Window Resource (rc) files andlink them into a native binary. This functionality is provided by the 'windows-resources'
plugin.

Page 310 of 436

Example 55.15. The 'windows-resources' pluginbuild.gradle
apply plugin: 'windows-resources'

Windows resources to be included in a native binary are provided via a WindowsResourceSet,
which defines a set of Windows Resource source files. By default, for any named component theWindowsResourceSet contains .rc source files under src/${name}/rc.
As with other source types, you can configure the location of the windows resources that should
be included in the binary.
Example 55.16. Configuring the location of Windows resource sourcesbuild-resource-only-dll.gradle
sources {helloRes {rc {source {srcDirs "src/hello/rc"}
exportedHeaders {srcDirs "src/hello/headers"}}}}

You are able to construct a resource-only library by providing Windows Resource sources withno other language sources, and configure the linker as appropriate:
Example 55.17. Building a resource-only dllbuild-resource-only-dll.gradle
libraries {
helloRes {binaries.all {rcCompiler.args "/v"
linker.args "/noentry", "/machine:x86"}}}

The example above also demonstrates the mechanism of passing extra command-line arguments
to the resource compiler. The rcCompiler extension is of type PreprocessingTool.

Page 311 of 436

55.12. Library Dependencies
Dependencies for native components are binary libraries that export header files. The header
files are used during compilation, with the compiled binary dependency being used duringlinking and execution.

55.12.1. Dependencies within the same project
A set of sources may depend on header files provided by another binary component within thesame project. A common example is a native executable component that uses functions
provided by a separate native library component.
Such a library dependency can be added to a source set associated with the executablecomponent:
Example 55.18. Providing a library dependency to the source set
build.gradle
sources {main {cpp {lib libraries.hello}}}

Alternatively, a library dependency can be provided directly to the NativeExecutableBinary
for the executable.
Example 55.19. Providing a library dependency to the binary
build.gradle
executables {main {
binaries.all {// Each executable binary produced uses the 'hello' static library binary
lib libraries.hello.static}}}

55.12.2. Project Dependencies
For a component produced in a different Gradle project, the notation is similar.

Page 312 of 436

Example 55.20. Declaring project dependencies
build.gradle
project(":lib") {apply plugin: "cpp"libraries {main {}}// For any shared library binaries built with Visual C++,// define the DLL_EXPORT macrobinaries.withType(SharedLibraryBinarySpec) {if (toolChain in VisualCpp) {cppCompiler.define "DLL_EXPORT"}}}
project(":exe") {apply plugin: "cpp"executables {main {}}
sources {main {cpp {lib project: ':lib', library: 'main'}}}}55.13. Native Binary Variants
For each executable or library defined, Gradle is able to build a number of different native binary
variants. Examples of different variants include debug vs release binaries, 32-bit vs 64-bit
binaries, and binaries produced with different custom preprocessor flags.
Binaries produced by Gradle can be differentiated on build type, platform, and flavor. For eachof these 'variant dimensions', it is possible to specify a set of available values as well as target
each component at one, some or all of these. For example, a plugin may define a range of
support platforms, but you may choose to only target Windows-x86 for a particular component.

55.13.1. Build types
A build type determines various non-functional aspects of a binary, such as whether debug
information is included, or what optimisation level the binary is compiled with. Typical build
types are 'debug' and 'release', but a project is free to define any set of build types.

Page 313 of 436

Example 55.21. Defining build types
build.gradle
model {
buildTypes {debugrelease}}If no build types are defined in a project, then a single, default build type called 'debug' isadded.
For a build type, a Gradle project will typically define a set of compiler/linker flags per tool
chain.
Example 55.22. Configuring debug binaries
build.gradlebinaries.all {if (toolChain in Gcc && buildType == buildTypes.debug) {cppCompiler.args "-g"}if (toolChain in VisualCpp && buildType == buildTypes.debug) {cppCompiler.args '/Zi'
cppCompiler.define 'DEBUG'
linker.args '/DEBUG'}}At this stage, it is completely up to the build script to configure the relevant compiler/linker
flags for each build type. Future versions of Gradle will automatically include theappropriate debug flags for any 'debug' build type, and may be aware of various levels of
optimisation as well.

55.13.2. Platform
An executable or library can be built to run on different operating systems and cpu
architectures, with a variant being produced for each platform. Gradle defines each
OS/architecture combination as a NativePlatform, and a project may define any number ofplatforms. If no platforms are defined in a project, then a single, default platform 'current' isadded.

Presently, a Platform consists of a defined operating system and architecture. As wecontinue to develop the native binary support in Gradle, the concept of Platform will be
extended to include things like C-runtime version, Windows SDK, ABI, etc. SophisticatedPage 314 of 436

builds may use the extensibility of Gradle to apply additional attributes to each platform,
which can then be queried to specify particular includes, preprocessor macros or compiler
arguments for a native binary.

Example 55.23. Defining platforms
build.gradle
model {
platforms {x86 {architecture "x86"}x64 {architecture "x86_64"}
itanium {architecture "ia-64"}}}

For a given variant, Gradle will attempt to find a NativeToolChain that is able to build for thetarget platform. Available tool chains are searched in the order defined. See the tool chainssection below for more details.

55.13.3. Flavor
Each component can have a set of named flavors, and a separate binary variant can beproduced for each flavor. While the build type and target platform variant dimensions
have a defined meaning in Gradle, each project is free to define any number of flavors and apply
meaning to them in any way.
An example of component flavors might differentiate between 'demo', 'paid' and 'enterprise'
editions of the component, where the same set of sources is used to produce binaries withdifferent functions.

Page 315 of 436

Example 55.24. Defining flavors
build.gradle
model {
flavors {englishfrench}}libraries {
hello {
binaries.all {if (flavor == flavors.french) {cppCompiler.define "FRENCH"}}}}

In the example above, a library is defined with a 'english' and 'french' flavor. When compiling the'french' variant, a separate macro is defined which leads to a different binary being produced.
If no flavor is defined for a component, then a single default flavor named 'default' is used.

55.13.4. Selecting the build types, platforms and flavors for acomponent
For a default component, Gradle will attempt to create a native binary variant for each and every
combination of buildType, platform and flavor defined for the project. It is possible tooverride this on a per-component basis, by specifying the set of targetBuildTypes, targetPlatforms
and/or targetFlavors.
Example 55.25. Targeting a component at particular platforms
build.gradle
executables {main {
targetPlatforms "x86", "x64"}}

Here you can see that the TargetedNativeComponent.targetPlatforms() method is used
to select the set of platforms to target for executables.main.
A similar mechanism exists for selecting TargetedNativeComponent.targetBuildTypes()and TargetedNativeComponent.targetFlavors().

Page 316 of 436

55.13.5. Building all possible variants
When a set of build types, target platforms, and flavors is defined for a component, aNativeBinarySpec model element is created for every possible combination of these.
However, in many cases it is not possible to build a particular variant, perhaps because no tool
chain is available to build for a particular platform.
If a binary variant cannot be built for any reason, then the NativeBinarySpec associated withthat variant will not be buildable. It is possible to use this property to create a task to generate
all possible variants on a particular machine.
Example 55.26. Building all possible variants
build.gradle
task buildAllExecutables {dependsOn binaries.withType(NativeExecutableBinary).matching {it.buildable}}

55.14. Tool chains
A single build may utilize different tool chains to build variants for different platforms. To thisend, the core 'native-binary' plugins will attempt to locate and make available supported tool
chains. However, the set of tool chains for a project may also be explicitly defined, allowing
additional cross-compilers to be configured as well as allowing the install directories to be
specified.

55.14.1. Defining tool chains
The supported tool chain types are:
Gcc
Clang
VisualCpp

Page 317 of 436

Example 55.27. Defining tool chainsbuild.gradle
model {
toolChains {visualCpp(VisualCpp) {// Specify the installDir if Visual Studio cannot be located// installDir "C:/Apps/Microsoft Visual Studio 10.0"}
gcc(Gcc) {// Uncomment to use a GCC install that is not in the PATH// path "/usr/bin/gcc"}
clang(Clang)}}

Each tool chain implementation allows for a certain degree of configuration (see the API
documentation for more details).

55.14.2. Using tool chains
It is not necessary or possible to specify the tool chain that should be used to build. For a given
variant, Gradle will attempt to locate a NativeToolChain that is able to build for the target
platform. Available tool chains are searched in the order defined.

When a platform does not define an architecture or operating system, the default target of
the tool chain is assumed. So if a platform does not define a value for operatingSystem,
Gradle will find the first available tool chain that can build for the specified architecture.

The core Gradle tool chains are able to target the following architectures out of the box. In eachcase, the tool chain will target the current operating system. See the next section for information
on cross-compiling for other operating systems.
Tool Chain

Architectures

GCC

x86, x86_64

Clangx86, x86_64

Visual C++

x86, x86_64, ia-64

So for GCC running on linux, the supported target platforms are 'linux/x86' and 'linux/x86_64'.
For GCC running on Windows via Cygwin, platforms 'windows/x86' and 'windows/x86_64' aresupported. (The Cygwin POSIX runtime is not yet modelled as part of the platform, but will be in
the future.)
If no target platforms are defined for a project, then all binaries are built to target a default
platform named 'current'. This default platform does not specify any architecture or operatingSystem
value, hence using the default values of the first available tool chain.

Page 318 of 436

Gradle provides a hook that allows the build author to control the exact set of arguments passed
to a tool chain executable. This enables the build author to work around any limitations in
Gradle, or assumptions that Gradle makes. The arguments hook should be seen as a 'last-resort'mechanism, with preference given to truly modelling the underlying domain.
Example 55.28. Reconfigure tool argumentsbuild.gradle
model {
toolChains {visualCpp(VisualCpp) {eachPlatform {cppCompiler.withArguments { args ->args << "-DFRENCH"}}}
clang(Clang) {eachPlatform {cCompiler.withArguments { args ->Collections.replaceAll(args, "CUSTOM", "-DFRENCH")}
linker.withArguments { args ->args.remove "CUSTOM"}
staticLibArchiver.withArguments { args ->args.remove "CUSTOM"
}
}
}
}
}

55.14.3. Cross-compiling with GCC
Cross-compiling is possible with the Gcc and Clang tool chains, by adding support for
additional target platforms. This is done by specifying a target platform for a toolchain. For eachtarget platform a custom configuration can be specified.

Page 319 of 436

Example 55.29. Defining target platforms
build.gradle
model {
toolChains {gcc(Gcc) {target("arm"){
cppCompiler.withArguments { args ->args << "-m32"}
linker.withArguments { args ->args << "-m32"}}
target("sparc")}}
platforms {arm {architecture "arm"}sparc {
architecture "sparc"}}}

55.15. Visual Studio IDE integration
Gradle has the ability to generate Visual Studio project and solution files for the native
components defined in your build. This ability is added by the visual-studio plugin. For amulti-project build, all projects with native components should have this plugin applied.
When the visual-studio plugin is applied, a task name ${component.name}VisualStudiois created for each defined component. This task will generate a Visual Studio Solution file forthe named component. This solution will include a Visual Studio Project for that component, as
well as linking to project files for each depended-on binary.
The content of the generated visual studio files can be modified via API hooks, provided by the visualStudioextension.

Take

a

look

at

the

'visual-studio'

sample,orseeVisualStudioExtension.getProjects() and VisualStudioExtension.getSolutions()in the API documentation for more details.

55.16. CUnit support
The Gradle cunit plugin provides support for compiling and executing CUnit tests in yournative-binary project. For each NativeExecutableSpec and NativeLibrarySpec defined inyour project, Gradle will create a matching CUnitTestSuiteSpec component, named ${component.name}Tes.

Page 320 of 436

55.16.1. CUnit sources
Gradle will create a CSourceSet named 'cunit' for each CUnitTestSuiteSpec component in
the project. This source set should contain the cunit test files for the component sources. Source
files can be located in the conventional location (src/${component.name}Test/cunit) or
can be configured like any other source set.
Gradle initialises the CUnit test registry and executes the tests, utilising some generated CUnit
launcher sources. Gradle will expect and call a function with the signature void gradle_cunit_register()that you can use to configure the actual CUnit suites and tests to execute.
Example 55.30. Registering CUnit tests
suite_operators.c#include <CUnit/Basic.h>#include "gradle_cunit_register.h"#include "test_operators.h"
int suite_init(void) {return 0;}
int suite_clean(void) {return 0;}
void gradle_cunit_register() {CU_pSuite pSuiteMath = CU_add_suite("operator tests", suite_init, suite_clean);
CU_add_test(pSuiteMath, "test_plus", test_plus);
CU_add_test(pSuiteMath, "test_minus", test_minus);}

Due to this mechanism, your CUnit sources may not contain a main method since this will
clash with the method provided by Gradle.

55.16.2. Building CUnit executables
A CUnitTestSuiteSpec component has an associated NativeExecutableSpec or
NativeLibrarySpec component. For each NativeBinarySpec configured for the main
component, a matching CUnitTestSuiteBinarySpec will be configured on the test suite
component. These test suite binaries can be configured in a similar way to any other binary
instance:

Page 321 of 436

Example 55.31. Registering CUnit tests
build.gradlebinaries.withType(CUnitTestSuiteBinarySpec) {lib library: "cunit", linkage: "static"
if (flavor == flavors.failing) {cCompiler.define "PLUS_BROKEN"}}

Both the CUnit sources provided by your project and the generated launcher require thecore CUnit headers and libraries. Presently, this library dependency must be provided byyour project for each CUnitTestSuiteBinarySpec.

55.16.3. Running CUnit tests
For each CUnitTestSuiteBinarySpec, Gradle will create a task to execute this binary, which
will run all of the registered CUnit tests. Test results will be found in the ${build.dir} /test-results
directory.

Page 322 of 436

Example 55.32. Running CUnit tests
build.gradle
apply plugin: "c"apply plugin: "cunit"
model {
flavors {passing
failing}
repositories {libs(PrebuiltLibraries) {cunit {
headers.srcDir "lib/cunit/2.1-2/include"
binaries.withType(StaticLibraryBinary) {staticLibraryFile =file("lib/cunit/2.1-2/lib/" +findCUnitLibForPlatform(targetPlatform))
}
}
}
}
}
libraries {operators {}}binaries.withType(CUnitTestSuiteBinarySpec) {lib library: "cunit", linkage: "static"
if (flavor == flavors.failing) {cCompiler.define "PLUS_BROKEN"
}
}

ノ

ー

ト

:

本例のソースコードは、Gradleのバイナリ配布物またはソース配布物に含まれています。以下の場所をご参照くだsamples/native-binaries/cunit
gradle -q runFailingOperatorsTestCUnitExe の出力> gradle -q runFailingOperatorsTestCUnitExe
There were test failures:
1. /home/user/gradle/samples/native-binaries/cunit/src/operatorsTest/c/test_plus.c:6
2. /home/user/gradle/samples/native-binaries/cunit/src/operatorsTest/c/test_plus.c:7

The current support for CUnit is quite rudimentary. Plans for future integration include:
Allow tests to be declared with Javadoc-style annotations.
Improved HTML reporting, similar to that available for JUnit.
Real-time feedback for test execution.
Support for additional test frameworks.

Page 323 of 436- plus(0- plus(2Page 324 of 436

56
ビルドのライフサイクル

前述の通り、Gradleというのは言ってしまえば依存性を記述する言語です。Gradleの用語でいえば、タスクとタスク間
無 閉 路 有 向 グ ラ フ ( D A G )を構築するのです。タスクを実行するときにこのようなタスクグラフを組み立てるビルドツールもありますが、Gradl
ビルドスクリプトは、このタスクグラフを定義します。したがって、ビルドスクリプトとは、厳密にはビルド設定スクリプト だと言えるでしょう。

56.1. ビルドフェーズ
Gradleには、独立した三つのビルドフェーズがあります。
初期化

Gradleはシングルプロジェクト、マルチプロジェクトの双方をサポートします。初期化フェーズでは、どのプロジ
Projectインスタンスを生成します。
設定
プロジェクトのオブジェクトが設定されるフェーズです。ビルドに含まれる すべてのプロジェクトのビルドスクリプトが実行されます。
Gradle1.4で、「オンデマンド設定」という機能が 試験的に 導入されました。

オンデマンド設定モードでは、Gradleは全てのプロジェクトではなく、実行時に必要なプロジェクトのみ設定しま実行

設定フェーズで初期化と設定が完了したタスクのうち、実行するべきタスクを抽出して実行します。実行するタス
gradleコマンドに引き渡されたタスク名と、コマンドの実行ディレクトリから決定されます。

56.2. 設定ファイル

ビルドスクリプトの他、Gradleではビルドの「設定ファイル」を作成することができます。設定ファイルの場所はGras e t t i n g s . g r a d l eです。この設定ファイルをGradleがどのように探すのかについては、後ほど解説します。
設定ファイルは、初期化フェーズで使用されます。マルチプロジェクトの場合、settings.gradle

ファイルは必須です。ルートとなるプロジェクトに必ず配置しなければなりません。この設定ファイルにより、どのプ
57章マルチプロジェクトのビルド

参照)。シングルプロジェクトの場合は設定ファイルはなくてもかまいません。ビルドスクリプトのクラスパスにライ
6 0 章 ビ ル ド ロ ジ ッ ク の 体 系 化参照)。設定ファイルの読み込み、フェーズ実行の内部動作を、シングルプロジェクトの例を使って見てみます。
Page 325 of 436

例56.1 シングルプロジェクトのビルド
settings.gradle
println 'This is executed during the initialization phase.'build.gradle
println 'This is executed during the configuration phase.'task configured {println 'This is also executed during the configuration phase.'}task test << {println 'This is executed during the execution phase.'}task testBoth {doFirst {println 'This is executed first during the execution phase.'}
doLast {println 'This is executed last during the execution phase.'}println 'This is executed during the configuration phase as well.'}

gradle test testBoth の出力> gradle test testBoth
This is executed during the initialization phase.
This is executed during the configuration phase.
This is also executed during the configuration phase.
This is executed during the configuration phase as well.
:testThis is executed during the execution phase.
:testBoth
This is executed first during the execution phase.
This is executed last during the execution phase.
BUILD SUCCESSFUL
Total time: 1 secs

ビルドスクリプト内でのプロパティアクセスやメソッド呼び出しは、Projectインスタンスに委譲されますが、それとSettingsをご参照ください。

56.3. マルチプロジェクトのビルド

マルチプロジェクトとは、ある一つのプロジェクトをビルドしているときに、関連する別のプロジェクトも呼び出され57章マルチプロジェクトのビルド参照)。

Page 326 of 436

56.3.1. プロジェクトの配置
マルチプロジェクトは、常に、あるプロジェクトをルートにしたプロジェクトのツリー構造となります。

マルチプロジェクト・ツリーを構成するそれぞれのプロジェクトは、自分がツリー内のどこに位置しているかを示すパ

ほとんどのケースで、そのパス情報は、ファイルシステム上でのプロジェクトの物理的な位置を反映したものになるは
ただし、これは設定で変更することも可能です。

プロジェクト・ツリーは、settings.gradle

ファイルで作成します。

デフォルトでは、settings.gradle

ファイルがあるプロジェクトがルートプロジェクトになっていますが、ルートプロジェクトの位置もその設定ファイル

56.3.2. プロジェクト・ツリーの構築

設定ファイル内では、プロジェクト・ツリーを構築するためのメソッドを使用できます。これらのメソッドでは、プロ

56.3.2.1. 階層構造のレイアウト
例56.2 階層構造のレイアウト
settings.gradle
include 'project1', 'project2:child', 'project3:child1'

includeメソッドは、プロジェクトのパスを引数にとります。
このパスは、ファイルシステム上の物理的な相対パスを表したものです。

例えば、'services:api'というパスは、デフォルトでは'services/api'フォルダ(プロジェクトルートからの相対)にマッピ指定するのは、ツリーの末端となるプロジェクトだけで構いません。

つまり、'services:hotels:api'を指定しただけで3つのプロジェクトが作成されるということです('services'、'services:

56.3.2.2. フラットなレイアウト
例56.3 フラットなレイアウト
settings.gradle
includeFlat 'project3', 'project4'

i n c l u d e F l a t

メソッドは、ディレクトリ名を引数にとります。これらのディレクトリは、ルートプロジェクトのディレクトリと同じ

56.3.3. プロジェクト・ツリーの属性を変更する
設定ファイルで定義したプロジェクト・ツリーは、 プロジェクトディスクリプタと呼ばれる属性を持っています。これらの属性は設定ファイルの中でいつでも変更することができます。ディスクリプ
例56.4 プロジェクト・ツリーの属性を変更する
settings.gradle
println rootProject.nameprintln project(':projectA').name

Page 327 of 436

ディスクリプタを使用して、プロジェクト名やプロジェクトディレクトリ、プロジェクトのビルドスクリプト名を変更
例56.5 プロジェクトツリーの属性を変更する
settings.gradle
rootProject.name = 'main'
project(':projectA').projectDir = new File(settingsDir, '../my-project-a')project(':projectA').buildFileName = 'projectA.gradle'

詳細についてはProjectDescriptorをご参照ください。

56.4. 初期化

Gradleは、現在ビルドしているものがマルチプロジェクトかシングルプロジェクトか、どうやって知るのでしょう。マ[31]

Gradleは、settings.gradleのないディレクトリで実行された場合、以下のように動作します。
カレントディレクトリと同階層のディレクトリからmasterという名前のディレクトリを探す。
見つからなければ、親階層のディレクトリをたどっていって探す。
見つからなければ、シングルプロジェクトとしてビルドする。
s e t t i n g s . g r a d l eが見つかれば、Gradleはビルドを実行したプロジェクトがマルチプロジェクトに参加するよう宣言されているかど

なんのためにこのような振る舞いをするのでしょう。今からビルドするプロジェクトは、マルチプロジェクトのうちの57章マルチプロジェクトのビルド参照)。-u
オプションをつけてGradleを実行すれば、親階層をたどってsettings.gradle

を探しに行くことはありません。つまり、(settings.gradleのない)現在ビルドしているプロジェクトは、常にシングル
settings.gradleがある場合は、-uをつけても意味はありません。settings.gradleをもつプロジェクトは以下のように処理されます。
s e t t i n g s . g r a d l e
がマルチプロジェクト・ツリーを定義していない場合はシングルプロジェクトとしてビルド
s e t t i n g s . g r a d l e
がマルチプロジェクト・ツリーを定義している場合は、マルチプロジェクトとしてビルド

この設定ファイルの探索処理は、プロジェクトのディレクトリ構造が前述した階層レイアウトとフラットレイアウトの「 絶 対 パ ス に よ る タ ス ク の 実 行 」

をご参照ください。次のリリースでは、コマンドラインから設定ファイルの場所を指定してやることで、サブプロジェ

初期化フェーズでは、ビルドに参加しているすべてのプロジェクトについてProjectオブジェクトが作成されます。シGradle creates a Project object for every project taking part in the build. For a multi-project build
these are the projects specified in the Settings object (plus the root project). Each project object
has by default a name equal to the name of its top level directory, and every project except theroot project has a parent project. Any project may have child projects.

Page 328 of 436

56.5. シングルプロジェクトの設定と実行
シングルプロジェクトの場合、 初期化フェーズ完了後の処理の流れは非常にシンプルです。まず、初期化フェーズで作成されたプロジェクトのビルドスクリプトが実行され57章マルチプロジェクトのビルドを参照してください。

56.6. ライフサイクルからの通知に応答する

ビルドスクリプト内では、ビルドがそのライフサイクルに従って進行していくなかで、さまざまな通知を受けとって処

56.6.1. プロジェクトの評価

プロジェクトが評価される前またはされた後すぐに通知を受け取ることができます。これは、ビルドスクリプトが一通
以下の例は、testタスクをhasTests
プロパティを持つすべてのプロジェクトに追加するものです。
例56.6 特定プロパティを持つプロジェクトにタスクを追加する
build.gradle
allprojects {afterEvaluate { project ->if (project.hasTests) {println "Adding test task to $project"
project.task('test') << {println "Running tests for $project"}}}}

projectA.gradle
hasTests = true

gradle -q test の出力> gradle -q test
Adding test task to project ':projectA'
Running tests for project ':projectA'

この例では、Project.afterEvaluate()を使用して、プロジェクト評価後に実行されるクロージャを追加しています。

プロジェクト評価時の通知は、どんなプロジェクトに対しても受け取ることができます。次の例では、カスタムロギン
a f t e r P r o j e c t
が、プロジェクトの評価に成功しても例外で失敗しても通知される点に注目してください。

Page 329 of 436

例56.7 通知
build.gradle
gradle.afterProject {project, projectState ->if (projectState.failure) {println "Evaluation of $project FAILED"} else {println "Evaluation of $project succeeded"}}gradle -q test の出力> gradle -q test
Evaluation of root project 'buildProjectEvaluateEvents' succeeded
Evaluation of project ':projectA' succeeded
Evaluation of project ':projectB' FAILED

ProjectEvaluationListenerをGradleに追加することでも同様の処理を実現できます。

56.6.2. タスク作成

プロジェクトにタスクが作成されたときに通知を受け取ることができます。この通知は、タスクが使用される前にデフ
次の例は、作成されたタスクに、随時srcDirプロパティを追加していくものです。
例56.8 すべてのタスクにプロパティ値を設定する
build.gradle
tasks.whenTaskAdded { task ->task.ext.srcDir = 'src/main/java'}
task aprintln "source dir is $a.srcDir"

gradle -q a の出力> gradle -q asource dir is src/main/java

ActionをTaskContainerに追加することでも同様の処理を実現できます。

56.6.3. タスク実行グラフの準備
タスクの実行グラフが用意できたときに通知を受け取ることができます。この例については、「DAGによる設定」で紹介しました。
TaskExecutionGraphListenerをTaskExecutionGraphに追加することでも同様の処理を実現できます。

Page 330 of 436

56.6.4. タスクの実行タスクが実行される前または実行された後に通知を受け取ることができます。
次の例では、タスクの実行が開始されたときと終わったときにそれぞれロギングを追加しています。afterTask
が、タスクの実行に成功しても例外で失敗しても通知されていることに注目してください。
例56.9 タスク実行の開始時および終了時にロギングを行う
build.gradle
task oktask broken(dependsOn: ok) << {throw new RuntimeException('broken')}gradle.taskGraph.beforeTask { Task task ->println "executing $task ..."}
gradle.taskGraph.afterTask { Task task, TaskState state ->if (state.failure) {println "FAILED"}
else {
println "done"}}

gradle -q broken の出力> gradle -q broken
executing task ':ok' ...
done
executing task ':broken' ...
FAILED

TaskExecutionListenerをTaskExecutionGraphに追加することでも同様の処理を実現できます。

[31] Gradleは、マルチプロジェクトに含まれる一部のプロジェクトのみ部分的にビルドできる(57章
マルチプロジェクトのビルド参照)

Page 331 of 436

57
マルチプロジェクトのビルド

マルチプロジェクトはビルドツールの知恵の絞りどころであり、とてもやりがいのあるテーマです。Gradleはマルチプ
A multi-project build in gradle consists of one root project, and one or more subprojects that
may also have subprojects.

57.1. クロスプロジェクト設定
While each subproject could configure itself in complete isolation of the other subprojects, it iscommon that subprojects share common traits. It is then usually preferable to shareconfigurations among projects, so the same configuration affects several subprojects.

まず、ごく簡単な例から始めましょう。なんと言ってもGradleは汎用のビルドツールですので、扱うプロジェクトがJ
これから例として使用するプロジェクトは、海洋生物に関するものです。

57.1.1. Configuration and execution「ビルドフェーズ」 describes the phases of every Gradle build. Let's zoom into the configurationand execution phases of a multi-project build. Configuration here means executing the build.gradle
file of a project, which implies e.g. downloading all plugins that were declared using 'apply plugin'. By default, the configuration of all projects happens before any task is executed. This meansthat when a single task, from a single project is requested, all projects of multi-project build are
configured first. The reason every project needs to be configured is to support the flexibility ofaccessing and changing any part of the Gradle project model.

57.1.1.1. Configuration on demand
The Configuration injection feature and access to the complete project model are possible
because every project is configured before the execution phase. Yet, this approach may not be
the most efficient in a very large multi-project build. There are Gradle builds with a hierarchy of
hundreds of subprojects. The configuration time of huge multi-project builds may become
noticeable. Scalability is an important requirement for Gradle. Hence, starting from version 1.4 a
new incubating 'configuration on demand' mode is introduced.
Configuration on demand mode attempts to configure only projects that are relevant forrequested tasks, i.e. it only executes the build.gradle file of projects that are participating in
the build. This way, the configuration time of a large multi-project build can be reduced. In thelong term, this mode will become the default mode, possibly the only mode for Gradle build
execution. The configuration on demand feature is incubating so not every build is guaranteed
Page 332 of 436

to work correctly. The feature should work very well for multi-project builds that have decoupledprojects (「分離されたプロジェクト 」). In “configuration on demand” mode, projects are
configured as follows:
The root project is always configured. This way the typical common configuration is
supported (allprojects or subprojects script blocks).
The project in the directory where the build is executed is also configured, but only when
Gradle is executed without any tasks. This way the default tasks behave correctly when
projects are configured on demand.
The standard project dependencies are supported and makes relevant projects configured. If
project A has a compile dependency on project B then building A causes configuration ofboth projects.
The task dependencies declared via task path are supported and cause relevant projects tobe configured. Example: someTask.dependsOn(":someOtherProject:someOtherTask")
A task requested via task path from the command line (or Tooling API) causes the relevant
project to be configured. For example, building 'projectA:projectB:someTask' causes
configuration of projectB.
Eager to try out this new feature? To configure on demand with every build run see「gradle.propertiesを使用したビルド環境の構築」. To configure on demand just for a given build
please see 付録D Gradle コマンドライン.

57.1.2. 共通の振る舞いを定義する
次のプロジェクトツリーにそってサンプルを見てみましょう。 これはルートプロジェクト「water」と、サブプロジェクトの「bluewhale(シロナガスクジラ)」からなるマルチプロジェクトです。
例57.1 マルチプロジェクト・ツリー - warter & bluewhale プロジェクト
Build layout
water/
build.gradle
settings.gradle
bluewhale/

ノ

ー

ト

:

本例のソースコードは、Gradleのバイナリ配布物またはソース配布物に含まれています。以下の場所をご参照くだsamples/userguide/multiproject/firstExample/watersettings.gradle
include 'bluewhale'

で 、 b l u e w h a l e

プロジェクトのビルドスクリプトは何処にあるのでしょう。Gradleでは、ビルドスクリプトは必須ではありません。シ
waterのビルドスクリプトを見てみましょう。

Page 333 of 436

例57.2 water(親プロジェクト)のビルドスクリプト
build.gradle
Closure cl = { task -> println "I'm $task.project.name" }task hello << clproject(':bluewhale') {task hello << cl}gradle -q hello の出力> gradle -q hello
I'm water
I'm bluewhale

Gradleでは、マルチプロジェクトを構成するすべてのプロジェクトに、どのビルドスクリプトからでもアクセスするこ
p r o j e c t ( )というメソッドを使用でき、引数にプロジェクトへのパスを渡せばProjectオブジェクトを取得できます。つまり、あクロスプロジェクト設定 と呼んでいます。Gradleは、この機能を 設定のインジェクション
を利用して実現します。
w

a

t

e

r

プロジェクトのビルドスクリプトは、まだ満足できるものではありません。すべてのプロジェクトに手でこのタスクを
krill()プロジェクトをマルチプロジェクトに追加してみましょう。
例57.3 マルチプロジェクトツリー - water, bluewhaleそしてkrill
Build layout
water/
build.gradle
settings.gradle
bluewhale/
krill/ノート:

本例のソースコードは、Gradleのバイナリ配布物またはソース配布物に含まれています。以下の場所をご参照くだsamples/userguide/multiproject/addKrill/watersettings.gradle
include 'bluewhale', 'krill'waterビルドスクリプトを書き直し、一行で記述するようにします。

Page 334 of 436

例57.4 Waterプロジェクトのビルドスクリプト
build.gradle
allprojects {task hello << { task -> println "I'm $task.project.name" }}gradle -q hello の出力> gradle -q hello
I'm water
I'm bluewhale
I'm krill

素晴らしい。これはどういう原理で動いているのでしょう。プロジェクトAPIはallprojectsというプロパティを提供しており、そのプロパティには現在のプロジェクトと、そのサブプロジェクトのリストが格納
allprojects をクロージャとともに呼び出せば、クロージャの実行が allprojectsに格納されたすべてのプロジェクトに委譲されます。もちろんallprojects
をeachでループすることもできますが、記述が冗長になってしまいます。

他のビルドシステムでは、プロジェクト間の共通設定を行う方法として主に継承を使用します。後ほど紹介するようにAnother possibilty for sharing configuration is to use a common external script. See「外部のビルドスクリプトをプロジェクトに取り込む」 for more information.

57.2. サブプロジェクトの設定
プロジェクトAPIはサブプロジェクトのみにアクセスする方法も提供します。

57.2.1. 共通の振る舞いを定義する
例57.5 サブプロジェクト共通の振る舞いとすべてのプロジェクト共通の振る舞いをそれぞれ定義する
build.gradle
allprojects {task hello << {task -> println "I'm $task.project.name" }}subprojects {hello << {println "- I depend on water"}}gradle -q hello の出力> gradle -q hello
I'm water
I'm bluewhale- I depend on waterI'm krill- I depend on water

You may notice that there are two code snippets referencing the “ hello” task. The first one,

Page 335 of 436

which uses the “task” keyword, constructs the task and provides it's base configuration. The
second piece doesn't use the “task” keyword, as it is further configuring the existing “hello” task. You may only construct a task once in a project, but you may any number of code blocks
providing additional configuration.

57.2.2. 個別の振る舞いを追加する

共通の振る舞いの上に、それぞれのプロジェクト個別の振る舞いを追加することができます。普通は、プロジェクト個
bluewhaleに個別の振る舞いを追加することもできます。
例57.6 プロジェクト個別の振る舞いを定義する
build.gradle
allprojects {task hello << {task -> println "I'm $task.project.name" }}subprojects {hello << {println "- I depend on water"}}project(':bluewhale').hello << {println "- I'm the largest animal that has ever lived on this planet."}

gradle -q hello の出力> gradle -q hello
I'm water
I'm bluewhale- I depend on water- I'm the largest animal that has ever lived on this planet.
I'm krill- I depend on water

前述のとおり、プロジェクト個別の振る舞いは、普通そのプロジェクトのビルドスクリプトに記述します。リファクタ
krillプロジェクトにも振る舞いを追加してみましょう。

Page 336 of 436

例57.7 krillプロジェクトに個別の振る舞いを定義する
Build layout
water/
build.gradle
settings.gradle
bluewhale/build.gradle
krill/
build.gradle

ノ

ー

ト

:

本例のソースコードは、Gradleのバイナリ配布物またはソース配布物に含まれています。以下の場所をご参照くだsamples/userguide/multiproject/spreadSpecifics/watersettings.gradle
include 'bluewhale', 'krill'

bluewhale/build.gradle
hello.doLast {println "- I'm the largest animal that has ever lived on this planet."}

krill/build.gradle
hello.doLast {println "- The weight of my species in summer is twice as heavy as all human beings."}

build.gradle
allprojects {task hello << {task -> println "I'm $task.project.name" }}subprojects {hello << {println "- I depend on water"}}gradle -q hello の出力> gradle -q hello
I'm water
I'm bluewhale- I depend on water- I'm the largest animal that has ever lived on this planet.
I'm krill- I depend on water- The weight of my species in summer is twice as heavy as all human beings.

Page 337 of 436

57.2.3. プロジェクトのフィルタリング
設定のインジェクションが持つもっと大きな力をお見せするために、tropicalFish()
プロジェクトを追加します。このプロジェクトに、water
プロジェクトのビルドスクリプトから振る舞いを定義していきます。

57.2.3.1. 名前によるフィルタリング
例57.8 プロジェクトに振る舞いを追加する(プロジェクト名によるフィルタリング)
Build layout
water/
build.gradle
settings.gradle
bluewhale/build.gradle
krill/
build.gradle
tropicalFish/

ノ

ー

ト

:

本例のソースコードは、Gradleのバイナリ配布物またはソース配布物に含まれています。以下の場所をご参照くだsamples/userguide/multiproject/addTropical/watersettings.gradle
include 'bluewhale', 'krill', 'tropicalFish'build.gradle
allprojects {task hello << {task -> println "I'm $task.project.name" }}subprojects {hello << {println "- I depend on water"}}configure(subprojects.findAll {it.name != 'tropicalFish'}) {hello << {println '- I love to spend time in the arctic waters.'}}

gradle -q hello の出力> gradle -q hello
I'm water
I'm bluewhale- I depend on water- I love to spend time in the arctic waters.
- I'm the largest animal that has ever lived on this planet.
I'm krill- I depend on water- I love to spend time in the arctic waters.
- The weight of my species in summer is twice as heavy as all human beings.
I'm tropicalFish- I depend on water

Page 338 of 436

configure()は引数にリストを取るメソッドで、そのリストに格納されたプロジェクトに設定を適用します。

57.2.3.2. プロパティによるフィルタリング

フィルタリングには、プロジェクト名だけでなく拡張プロパティを使うこともできます。(拡張プロパティの詳細につ「拡張プロパティ 」を参照してください。)
例57.9 プロジェクトに振る舞いを追加する(プロパティによるフィルタリング)
Build layout
water/
build.gradle
settings.gradle
bluewhale/build.gradle
krill/
build.gradle
tropicalFish/build.gradle

ノ

ー

ト

:

本例のソースコードは、Gradleのバイナリ配布物またはソース配布物に含まれています。以下の場所をご参照くだsamples/userguide/multiproject/tropicalWithProperties/watersettings.gradle
include 'bluewhale', 'krill', 'tropicalFish'bluewhale/build.gradle
ext.arctic = true
hello.doLast {println "- I'm the largest animal that has ever lived on this planet."}

krill/build.gradle
ext.arctic = true
hello.doLast {println "- The weight of my species in summer is twice as heavy as all human beings."}

tropicalFish/build.gradle
ext.arctic = false

build.gradle

Page 339 of 436

allprojects {task hello << {task -> println "I'm $task.project.name" }}subprojects {hello {
doLast {println "- I depend on water"}afterEvaluate { Project project ->if (project.arctic) { doLast {println '- I love to spend time in the arctic waters.' }}}}}gradle -q hello の出力> gradle -q hello
I'm water
I'm bluewhale- I depend on water- I'm the largest animal that has ever lived on this planet.
- I love to spend time in the arctic waters.
I'm krill- I depend on water- The weight of my species in summer is twice as heavy as all human beings.
- I love to spend time in the arctic waters.
I'm tropicalFish- I depend on water

waterプロジェクトのビルドスクリプトでは、afterEvaluateという宣言文が使用されています。afterEvaluateに引き渡されたクロージャは、そのプロジェクトのビルドスクリプトが評価された 後に実行されます。サブプロジェクトのarctic
プロパティは、それぞれのプロジェクトのビルドスクリプト内でセットされているので、この方法でarctic
プロパティにアクセスする必要があるのです。このトピックは「依存関係-

なんの依存関係？」

で詳しく説明します。

57.3. マルチプロジェクトのビルド実行ルール

helloタスクをルートプロジェクトのディレクトリで実行したとき、ビルドは直感に従う、自然な形で実行されました
bluewhaleディレクトリでGradleを実行した場合、どのようにビルドが実行されるのでしょうか。
例57.10 サブプロジェクトからビルドを実行する
gradle -q hello の出力> gradle -q hello
I'm bluewhale- I depend on water- I'm the largest animal that has ever lived on this planet.
- I love to spend time in the arctic waters.

Gradleがビルドを実行するときの基本的なルールは単純なものです。この例では、Gradleはhello

タスクを探して、カレントディレクトリからプロジェクト階層を降りていき、タスクを見つけるとそれを実行するだけ

Page 340 of 436

す べ て の プ ロ ジ ェ ク ト を 常 に評価します。ビルドスクリプトに定義されているタスクオブジェクトは、すべて作成されるのです。そのあと、Gradlmarineプロジェクトのbluewhaleとkrillに新しいタスクを追加しましょう。
例57.11 プロジェクトの評価と実行
bluewhale/build.gradle
ext.arctic = true
hello << { println "- I'm the largest animal that has ever lived on this planet." }task distanceToIceberg << {println '20 nautical miles'}

krill/build.gradle
ext.arctic = true
hello << {println "- The weight of my species in summer is twice as heavy as all human beings."}
task distanceToIceberg << {println '5 nautical miles'}

gradle -q distanceToIceberg の出力> gradle -q distanceToIceberg
20 nautical miles
5 nautical miles-qオプションを外すと、出力結果は以下のようになります。:
例57.12 プロジェクトの評価と実行
gradle distanceToIceberg の出力> gradle distanceToIceberg:bluewhale:distanceToIceberg
20 nautical miles:krill:distanceToIceberg
5 nautical miles
BUILD SUCCESSFUL
Total time: 1 secs

このビルドはwaterプロジェクトのディレクトリで実行しています。waterプロジェクトもtropicalFish

プロジェクトもdistanceToIcebergという名前のタスクは持っていませんが、Gradleはそんなこと気にしません。前述

57.4. 絶対パスによるタスクの実行

いままで見てきたように、マルチプロジェクトのサブプロジェクトは、プロジェクトのディレクトリに移動して個別に「プロジェクトとタスクのパス」もご参照ください)
Page 341 of 436

例57.13 絶対パスによるタスクの実行
gradle -q :hello :krill:hello hello の出力> gradle -q :hello :krill:hello hello
I'm water
I'm krill- I depend on water- The weight of my species in summer is twice as heavy as all human beings.
- I love to spend time in the arctic waters.
I'm tropicalFish- I depend on water

ビ ル ド は t r o p i c a l F i s h
プロジェクトのディレクトリで実行されています。上記の例では、ルートプロジェクトwatar、krill
プロジェクト、そしてカレントのサブプロジェクト tropicalFish の helloがそれぞれ実行されます。

57.5. プロジェクトとタスクのパス
A project path has the following pattern: It starts with an optional colon, which denotes the root
project. The root project is the only project in a path that is not specified by its name. The rest of
a project path is a colon-separated sequence of project names, where the next project is a
subproject of the previous project.
タスクのパスは、例えば:bluewhale:helloのように、単純にプロジェクトパスにタスク名を加えるだけです。なお、カレントのプロジェクトにあるタスクは、タ以前Gradleでは、プロジェクトのパスセパレータとして /を使用していました。しかし、このセパレータ文字はdirectoryタスク(「ディレクトリの作成」

参照)が導入されたときに廃止されています。 directory タスクのタスク名に、 /が含まれるためです。

57.6. 依存関係 - なんの依存関係？

先ほどまでの例は特殊なもので、プロジェクトの間で設定情報は依存関係がありましたが、実行に関しては依存関係がPage 342 of 436

57.6.1. 実行に関する依存関係
57.6.1.1. 依存関係と実行順序
例57.14 依存関係とビルド実行順序
Build layout
messages/settings.gradle
consumer/build.gradle
producer/build.gradle

ノ

ー

ト

:

本例のソースコードは、Gradleのバイナリ配布物またはソース配布物に含まれています。以下の場所をご参照くだsamples/userguide/multiproject/dependencies/firstMessages/messages
settings.gradle
include 'consumer', 'producer'

consumer/build.gradle
task action << {println("Consuming message: ${rootProject.producerMessage}")}producer/build.gradle
task action << {println "Producing message:"
rootProject.producerMessage = 'Watch the order of execution.'}

gradle -q action の出力> gradle -q action
Consuming message: null
Producing message:

この例はうまく動作しません。依存関係が定義されていないと、Gradleはタスクをアルファベット順に実行します。
したがって、:consumer():actionが:producer():actionより先に実行されてしまうのです。 producer
プロジェクトの名前をaProducerに修正すればこの問題を解決することはできます。

Page 343 of 436

例57.15 依存関係とビルド実行順序
Build layout
messages/settings.gradle
aProducer/
build.gradle
consumer/build.gradle

settings.gradle
include 'consumer', 'aProducer'

aProducer/build.gradle
task action << {println "Producing message:"
rootProject.producerMessage = 'Watch the order of execution.'}

consumer/build.gradle
task action << {println("Consuming message: ${rootProject.producerMessage}")}

gradle -q action の出力> gradle -q action
Producing message:
Consuming message: Watch the order of execution.

ただ、このハックは簡単に破綻してしまいます。consumerディレクトリに移動して、ビルドしてみましょう。
例57.16 依存関係とビルド実行順序
gradle -q action の出力> gradle -q action
Consuming message: null問題はこの二つの“ action ”タスクが無関係であることです。

確かに、 messages

プロジェクトをビルドすればGradleはこの二つのタスクを両方とも実行します。
しかし、それは二つのタスクが同じ名前のタスクであり、両方とも実行ディレクトリ以下にあるからです。
最後の例では一方のタスクが実行ディレクトリから外れたので、片方の“action”タスクしか実行されませんでした。 このハックよりも良い方法が必要です。

Page 344 of 436

57.6.1.2. 依存関係を宣言する
例57.17 依存関係を宣言する
Build layout
messages/settings.gradle
consumer/build.gradle
producer/build.gradle

ノ

ー

ト

:

本例のソースコードは、Gradleのバイナリ配布物またはソース配布物に含まれています。以下の場所をご参照くだsamples/userguide/multiproject/dependencies/messagesWithDependencies/messages
settings.gradle
include 'consumer', 'producer'

consumer/build.gradle
task action(dependsOn: ":producer:action") << {println("Consuming message: ${rootProject.producerMessage}")}producer/build.gradle
task action << {println "Producing message:"
rootProject.producerMessage = 'Watch the order of execution.'}

gradle -q action の出力> gradle -q action
Producing message:
Consuming message: Watch the order of execution.

consumerディレクトリでビルドすると、以下のようになります。
例57.18 依存関係を宣言する
gradle -q action の出力> gradle -q action
Producing message:
Consuming message: Watch the order of execution.

consumerプロジェクトの“action”タスクは producerプロジェクトの“action”タスクに実行時依存関係 を持つことを宣言したことで、事態は改善しました。

Page 345 of 436

57.6.1.3. プロジェクトをまたぐタスク間依存関係の性質
もちろん、同じ名前のタスク間でしかプロジェクトをまたぐ依存関係は結べない、ということはありません。
タスクの名前を変えて実行してみたのが、以下の例です。
例57.19 プロジェクトにまたがるタスク間の依存関係
consumer/build.gradle
task consume(dependsOn: ':producer:produce') << {println("Consuming message: ${rootProject.producerMessage}")}producer/build.gradle
task produce << {println "Producing message:"
rootProject.producerMessage = 'Watch the order of execution.'}

gradle -q consume の出力> gradle -q consume
Producing message:
Consuming message: Watch the order of execution.

57.6.2. 評価順序の依存関係
そ ろ そ ろ 実 際 の J a v aでの例をみていきたいと思いますが、その前に、producer-consumerプロジェクトについてもう一つ例を見てみます。
例57.20 評価順序の依存関係
consumer/build.gradle
def message = rootProject.producerMessage
task consume << {println("Consuming message: " + message)}

producer/build.gradle
rootProject.producerMessage = 'Watch the order of evaluation.'

gradle -q consume の出力> gradle -q consume
Consuming message: null

デフォルトでは、プロジェクトはプロジェクト名のアルファベット順で評価されます。したがって、consumer
プロジェクトはproducerプロジェクトの前に評価され、producerプロジェクトのプロパティはconsumer

プロジェクトが読みにいった後にセットされてしまうのです。Gradleでは、このような問題に対する解決策を提供してPage 346 of 436

例57.21 評価順序の依存関係 - evaluationDependsOnconsumer/build.gradle
evaluationDependsOn(':producer')def message = rootProject.producerMessage
task consume << {println("Consuming message: " + message)}

gradle -q consume の出力> gradle -q consume
Consuming message: Watch the order of evaluation.

このevaluationDependsOn コマンドにより、producer プロジェクトがconsumerの前に評価されるようになります。
なお、この例はメカニズムを説明するためのやや不自然なものです。
この場合は実行時にタスク内でプロパティを読みにいった方が早いでしょう。
例57.22 評価順序の依存関係
consumer/build.gradle
task consume << {println("Consuming message: ${rootProject.producerMessage}")}

gradle -q consume の出力> gradle -q consume
Consuming message: Watch the order of evaluation.

評価順序の依存関係と実行時の依存関係では、大きく異なる点があります。

まず、実行の依存関係は最終的には常にタスク間の依存関係になりますが、評価順序の依存関係はプロジェクト間の依さらに、サブプロジェクトを始点にビルドを開始した場合でも、そのマルチプロジェクトに含まれる全てのプロジェク

デフォルトでは、ルートプロジェクトからトップダウンでサブプロジェクトに向かって評価されていきます。普通はそ

このデフォルトを変更して"ボトムアップ"で評価されるようにするには、かわりに"evaluationDependsOnChildre"メソッドを使ってください。

同じ階層にあるプロジェクトは、プロジェクト名のアルファベット順で評価されます。よく使われるのは、マルチプロ

57.6.3. 実生活での例

Gradleのマルチプロジェクト機能は、開発現場でのユースケースに基づいて作成されています。ここではそのようなユ[33]

この例では、 クロスプロジェクト設定

を使って、一つのビルドスクリプトですべてのプロジェクトの設定を行っています。

Page 347 of 436

例57.23 依存関係 - 実生活の例 - クロスプロジェクト設定
Build layout
webDist/settings.gradlebuild.gradledate/
src/main/java/org/gradle/sample/
DateServlet.java
hello/
src/main/java/org/gradle/sample/
HelloServlet.java

ノ

ー

ト

:

本例のソースコードは、Gradleのバイナリ配布物またはソース配布物に含まれています。以下の場所をご参照くだsamples/userguide/multiproject/dependencies/webDist
settings.gradle
include 'date', 'hello'build.gradle
allprojects {apply plugin: 'java'group = 'org.gradle.sample'
version = '1.0'}
subprojects {apply plugin: 'war'
repositories {mavenCentral()}dependencies {compile "javax.servlet:servlet-api:2.5"}}
task explodedDist(dependsOn: assemble) << {File explodedDist = mkdir("$buildDir/explodedDist")
subprojects.each {project ->project.tasks.withType(Jar).each {archiveTask ->copy {
from archiveTask.archivePathinto explodedDist}}}}

この例は、面白い依存関係を持っています。 date プロジェクトと hello
プロジェクトで定義されているタスクの 評価 は、明らかに webDist の 評価に依存しています。Webアプリのビルドロジックは、すべてwebDistによって注入されているからです。しかし、実行

Page 348 of 436

webDistはhelloとdateの成果物を使ってビルドされるからです。さらに、もう一つの依存関係があります。webDistプロジェクトの評価は、

この手の依存関係は、マルチプロジェクトのビルドではよく発生します。ビルドシステムがこのような依存関係に対応

57.7. プロジェクト依存関係あるプロジェクトが、別のプロジェクトの生成するjarをコンパイルするときのクラスパスに必要としていたらどうすれ
これは、Javaのマルチプロジェクトではいかにもよくありそうなパターンです。
「 プ ロ ジ ェ ク ト 依 存 関 係」

ですでに言及していますが、プロジェクト依存関係はこのようなケースに対応するものです。
例57.24 プロジェクト依存関係
Build layout
java/settings.gradlebuild.gradle
api/
src/main/java/org/gradle/sample/
api/
Person.java
apiImpl/PersonImpl.java
services/personService/src/
main/java/org/gradle/sample/services/
PersonService.java
test/java/org/gradle/sample/services/
PersonServiceTest.javashared/src/main/java/org/gradle/sample/shared/
Helper.java

ノ

ー

ト

:

本例のソースコードは、Gradleのバイナリ配布物またはソース配布物に含まれています。以下の場所をご参照くだsamples/userguide/multiproject/dependencies/javashared、api、personServiceの三つのプロジェクトがあります。personService
プロジェクトは他の二つのプロジェクトに依存しています。さらに、apiプロジェクトはshared
プロジェクトに依存しています。 [35]Page 349 of 436

例57.25 プロジェクト依存関係
settings.gradle
include 'api', 'shared', 'services:personService'build.gradle
subprojects {apply plugin: 'java'group = 'org.gradle.sample'
version = '1.0'
repositories {mavenCentral()}dependencies {testCompile "junit:junit:4.11"}}
project(':api') {dependencies {compile project(':shared')}}
project(':services:personService') {dependencies {compile project(':shared'), project(':api')}}

ビルドロジックはすべてルートプロジェクトのbuild.gradle に記述されています。

[37 ]プロジェクト依存関係は、実行依存の別形態といえます。まずあるプロジェクトのビルドを実行し、生成されたクラス
gradlecompile と入力してみましょう。まず shared がビルドされ、次に apiがビルドされるでしょう。プロジェクト依存はマルチプロジェクトの部分ビルドを可能にします。

Mavenを使用されてきた人なら、このことですごく満足できるでしょう。Ivyの経験をお持ちなら、もっと細かい制御

Page 350 of 436

例57.26 細かい依存関係の制御
build.gradle
subprojects {apply plugin: 'java'group = 'org.gradle.sample'
version = '1.0'}
project(':api') {configurations {spi}dependencies {compile project(':shared')}task spiJar(type: Jar) {baseName = 'api-spi'
dependsOn classes
from sourceSets.main.output
include('org/gradle/sample/api/**')}
artifacts {spi spiJar}}
project(':services:personService') {dependencies {compile project(':shared')compile project(path: ':api', configuration: 'spi')
testCompile "junit:junit:4.11", project(':api')}}

Javaプラグインは、デフォルトではすべてのクラスが含まれたjarをプロジェクトのライブラリとして追加しますが、こ
そ

れ

に

加

え

て

、apiプロジェクトのインターフェースのみが含まれたライブラリを作成しています。そしてこのライブラリを、新規

serviceをコンパイルするときはインターフェースしか要りませんが、テストをするにはapiからすべてのクラスを持っ

57.7.1. 依存プロジェクトをビルドしないようにする

部分ビルドを実行する際、依存しているプロジェクトはビルドしたくない、という場合もあるかもしれません。依存し-aオプションをつけてプロジェクトをビルドしてください。

57.8. Parallel project execution
With more and more CPU cores available on developer desktops and CI servers, it is importantthat Gradle is able to fully utilise these processing resources. More specifically, the parallel
execution attempts to:
Reduce total build time for a multi-project build where execution is IO bound or otherwise
does not consume all available CPU resources.

Page 351 of 436

Provide faster feedback for execution of small projects without awaiting completion of otherprojects.
Although Gradle already offers parallel test execution via Test.setMaxParallelForks() thefeature described in this section is parallel execution at a project level. Parallel execution is an
incubating feature. Please use it and let us know how it works for you.
Parallel project execution allows the separate projects in a decoupled multi-project build to be
executed in parallel (see also: 「分離されたプロジェクト 」). While parallel execution does notstrictly require decoupling at configuration time, the long-term goal is to provide a powerful setof features that will be available for fully decoupled projects. Such features include:「Configuration on demand」.
Configuration of projects in parallel.
Re-use of configuration for unchanged projects.
Project-level up-to-date checks.
Using pre-built artifacts in the place of building dependent projects.
How does parallel execution work? First, you need to tell Gradle to use the parallel mode. You
can use the command line argument (付録D Gradle コマンドライン) or configure your build
environment (「gradle.propertiesを使用したビルド環境の構築」). Unless you provide a specificnumber of parallel threads Gradle attempts to choose the right number based on available CPU
cores. Every parallel worker exclusively owns a given project while executing a task. This meansthat 2 tasks from the same project are never executed in parallel. Therefore only multi-projectbuilds can take advantage of parallel execution. Task dependencies are fully supported andparallel workers will start executing upstream tasks first. Bear in mind that the alphabeticalscheduling of decoupled tasks, known from the sequential execution, does not really work inparallel mode. You need to make sure the task dependencies are declared correctly to avoid
ordering issues.

57.9. 分離されたプロジェクト

Gradleでは、評価フェーズでも実行フェーズでも、あらゆるプロジェクト間でお互いにアクセスすることができるよう

これはビルドの作成者にとっては非常に強力で柔軟性のある仕様ですが、ビルド時にはGradleの方の柔軟性が制限され例を挙げると、強固に結合されたプロジェクトは、Gradleに平行ビルドさせることができませんし、依存プロジェクト
お互いのプロジェクト・モデルにアクセスしない二つのプロジェクトは、 分離された
プ ロ ジ ェ ク ト と 呼 ば れ ま す 。
分離されたプロジェクトでは、お互いのやりとりに依存関係宣言のみを使用します。つまり、プロジェクト依存(「プロジェクト依存関係」 )やタスク依存( 「タスクの依存関係」 )です。

その他のあらゆるアクセス、例えば他プロジェクトのオブジェクトを変更したり、設定値を読み込んだりといった処理
結合 させます。
プロジェクトが結合されるもっとも一般的な状況は、設定のインジェクション(「クロスプロジェクト設定」)です。 これは直ぐには分かりにくいかもしれませんが、allprojects
や s u b p r o j e c t s
キーワードのような、Gradleの特定の機能を使うと、プロジェクトは自動的に結合されます。
これらのキーワードは、build.gradle

Page 352 of 436

ファイルで別のプロジェクトを定義するのに使われるからです。

共通設定の定義しかしていないルートプロジェクトもよくありますが、Gradleがルートプロジェクトを、完全な普通のallprojectsを使用している限り、プロジェクトは他の全てのプロジェクトと結合されます。
つまり、どんな形であれ、ビルドスクリプトのロジック共有、および設定のインジェクション(allprojects
や subprojects など)は、プロジェクトを結合させるということです。

私たちは、この分離されたプロジェクトという概念を拡張し、有効活用するような機能を追加する予定です。それによIn order to make good use of cross project configuration without running into issues for paralleland 'configuration on demand' options, follow these recommendations:
Avoid a subproject's build.gradle referencing other subprojects; prefering crossconfiguration from the root project.
Avoid changing the configuration of other projects at execution time.

57.10.
マルチプロジェクトのビルドとテスティング
J a v a プ ラ グ イ ン の b u i l d

タスクは、シングルプロジェクトをコンパイル、テスト、さらに(CodeQualityプラグインを使っていれば)コードスタ
buildNeededとbuildDependentsはこの用途を助けてくれるものです。
例57.25「プロジェクト依存関係」にあるプロジェクトの構造を使いましょう。この例では:service:personserviceが:apiと:sharedの双方に依存していま

シングルプロジェクトの:apiプロジェクトで作業しているとします。:apiに変更を加えましたが、クリーン以降、まだbuildタスクは、まさにこの処理を行います。

Page 353 of 436

例57.27 シングルプロジェクトのビルドとテスト
gradle :api:build の出力> gradle :api:build:shared:compileJava:shared:processResources:shared:classes:shared:jar:api:compileJava:api:processResources:api:classes:api:jar:api:assemble:api:compileTestJava:api:processTestResources:api:testClasses:api:test:api:check:api:build
BUILD SUCCESSFUL
Total time: 1 secs

典型的な開発サイクルでは、:apiプロジェクトに何か変更を加えるたびビルドとテストを繰り返すことになります。こ-aオプションをつけてビルドすると、依存プロジェクトのライブラリを解決する際、キャッシュされたjarが使用されるの例57.28 シングルプロジェクトの部分ビルドとテスト
gradle -a :api:build の出力> gradle -a :api:build:api:compileJava:api:processResources:api:classes:api:jar:api:assemble:api:compileTestJava:api:processTestResources:api:testClasses:api:test:api:check:api:build
BUILD SUCCESSFUL
Total time: 1 secs

今、ちょうど最新のソースをバージョン管理システムから持ってきたとしましょう。:apiが依存しているプロジェクトb u i l d N e e d e d

タスクは、指定したプロジェクトだけでなく、そのプロジェクトのtestRuntime依存関係に設定されているプロジェク

Page 354 of 436

例57.29 依存プロジェクトのビルドとテスト
gradle :api:buildNeeded の出力> gradle :api:buildNeeded:shared:compileJava:shared:processResources:shared:classes:shared:jar:api:compileJava:api:processResources:api:classes:api:jar:api:assemble:api:compileTestJava:api:processTestResources:api:testClasses:api:test:api:check:api:build:shared:assemble:shared:compileTestJava:shared:processTestResources:shared:testClasses:shared:test:shared:check:shared:build:shared:buildNeeded:api:buildNeeded
BUILD SUCCESSFUL
Total time: 1 secs

さらに、:apiプロジェクトをリファクタリングする場合のことを考えてみます。:apiプロジェクトは他のプロジェクトb u i l d D e p e n d e n t s

タスクは、指定したプロジェクトだけでなく、そのプロジェクトにtestRuntimeのプロジェクト依存関係を持っている

Page 355 of 436

例57.30 依存されているプロジェクトのビルドとテスト
gradle :api:buildDependents の出力> gradle :api:buildDependents:shared:compileJava:shared:processResources:shared:classes:shared:jar:api:compileJava:api:processResources:api:classes:api:jar:api:assemble:api:compileTestJava:api:processTestResources:api:testClasses:api:test:api:check:api:build:services:personService:compileJava:services:personService:processResources:services:personService:classes:services:personService:jar:services:personService:assemble:services:personService:compileTestJava:services:personService:processTestResources:services:personService:testClasses:services:personService:test:services:personService:check:services:personService:build:services:personService:buildDependents:api:buildDependents
BUILD SUCCESSFUL
Total time: 1 secs

最後に、すべてのプロジェクトをビルド、テストしたいと思うことがあるかもしれません。ルートプロジェクトのフォ
gradle buildと実行すれば大丈夫です。すべてのプロジェクトがビルドされテストされます。

57.11. Multi Project and buildSrc「buildSrcプロジェクトのソースをビルドする」 tells us that we can place build logic to becompiled and tested in the special buildSrc directory. In a multi project build, there can only
be one buildSrc directory which must be located in the root directory.

57.12. プロパティとメソッドの継承

プロジェクトで宣言されたプロパティとメソッドは、すべての子プロジェクトに継承されます。これは設定のインジェ
なお、Gradleの設定のインジェクション

ではまだメソッドを注入することができません(将来のリリースで対応する予定です)。なので、メソッドについては継

Page 356 of 436

どうみても継承機能を敬遠しているのに、なんでそんなのを実装したのか不思議に思われるかもしれません。一つの理57.13. まとめ

この章を書くのは非常に疲れました。読むのも疲れるでしょう。最後にひとつだけ、Gradleでマルチプロジェクトを扱
allproject、subprojects、evaluationDependsOn、evaluationDependsOnChildren、そしてプロジェクト依存関係です。

[39]

この5つ、そしてGradleが設定フェーズと実行フェーズを別個に取り扱うのだということを覚えておけば、あとは多く[33]

実際のケースではhttp://lucene.apache.org/solr

を使っており、warファイルをアクセスするインデックスごとに分割する必要がありました。分散型のウェブアプリケ[ 3 5 ]

s e r v i c e s

もまたプロジェクトですが、これはただの入れ物です。このプロジェクトにはビルドスクリプトも別のプロジェクトか[
この例では、ビルドスクリプトの配置を少し簡易化しています。普通は、プロジェクトが指定するものはそのプロジェ
37][39] マジカルナンバー7±2に収まるナイスな量ですPage 357 of 436

58
カスタムタスクの作成
Gradleは2種類のタスクをサポートしています。
そのひとつは単純タスクで、アクションクロージャでタスクを定義します。

これらは6章ビルドスクリプトの基本で説明してきたものです。
このタイプのタスクに対しては、タスクのふるまいはアクションクロージャによって決まります。
このタイプのタスクはビルドスクリプトで1回限りのタスクを実装するのに適しています。

もうひとつは拡張タスクで、ふるまいがタスクの中に組み込まれており、ふるまいを制御することのできるプロパティ
これらは15章タスク詳解で説明してきたものです。
ほとんどのGradleプラグインは拡張タスクを利用します。
拡張タスクでは、単純タスクのようにふるまいを実装する必要はありません。
単にタスクを宣言し、プロパティを利用してタスクを制御するだけです。

この方法により、拡張タスクではふるまいの断片を多くの場所で再利用したり、場合によっては異なるビルドで横断的
拡張タスクのふるまいやプロパティはタスクのクラスによって定義されます。
拡張タスクを宣言するときは、タスクのタイプやクラスを指定します。
Gradleで独自のカスタムタスククラスを実装するのは簡単です。

カスタムタスククラスは、最終的にバイトコードにコンパイルされるなら、どんな言語でも好きなもので実装できます
このサンプルでは実装言語としてGroovyを使いますが、例えばJavaやScalaを使うこともできます。
G

r

a

d

l

e

APIはGroovyとの親和性が高いように設計されているので、一般論としてGroovyが一番簡単な選択肢ではありますが。

58.1. タスククラスのパッケージング
タスククラスのソースを配置できる箇所はいくつかあります。
ビルドスクリプト
タスククラスをビルドスクリプトに直接含めることができます。

この方法は、特に何もしなくてもタスククラスが自動的にコンパイルされ、ビルドスクリプトのクラスパスに追加

しかし、タスククラスがビルドスクリプトの外部からは参照できないため、タスククラスを定義しているビルドス
buildSrcプロジェクト
タスククラスのソースを

rootProjectDir /buildSrc/src/main/groovy

デ ィ レ ク ト リ に 配 置 で き ま す 。

Gradleがタスククラスのコンパイルとテストを実行し、ビルドスクリプトのクラスパス上で有効になるように取りタスククラスはビルドで利用されるすべてのビルドスクリプトから参照可能です。

しかし、ビルドの外部からは参照できないので、タスクが定義されているビルドの外部でタスククラスを再利用す

Page 358 of 436

b

u

i

l

d

S

r

c

プロジェクトを使うアプローチでは、タスクの宣言「タスクが何を実行すべきか」と、タスクの実装「タスクがそ
buildSrcプロジェクトの詳細については、60章ビルドロジックの体系化を参照してください。
スタンドアロンプロジェクト
タスククラスのために独立したプロジェクトを作ることもできます。

このプロジェクトはJARを生成して発行するので、複数のビルドで利用したり、他のユーザーと共有することができ

一般に、このJARはカスタムプラグインを含むか、関連するいくつかのタスククラスを単一のライブラリにバンドル
あるいは、その両方の組み合わせです。
サンプルでは、簡単のためにビルドスクリプト内のタスククラスからはじめます。
その後、スタンドアロンプロジェクトについて説明します。

58.2. 単純タスクの作成
カスタムタスククラスを実装するには、DefaultTaskを拡張します。
例58.1 カスタムタスクの定義
build.gradle
class GreetingTask extends DefaultTask {}このタスクは何の役にも立たないので、ふるまいを追加してみましょう。
そのためには、タスクにメソッドを追加し、TaskActionアノテーションでマークします。
タスクが実行されたときに、Gradleがこのメソッドを呼びます。
タスクのふるまいを定義するには、必ずしもメソッドを使う必要はありません。
例えば、タスクのコンストラクタでクロージャを引数として doFirst() やdoLast()を呼ぶことでふるまいを追加することもできます。
例58.2 hello worldタスク
build.gradle
task hello(type: GreetingTask)
class GreetingTask extends DefaultTask {@TaskAction
def greet() {println 'hello from GreetingTask'}}

gradle -q hello の出力> gradle -q hello
hello from GreetingTask

タスクにプロパティを追加して、カスタマイズできるようにしてみましょう。

Page 359 of 436

タスクは単純なPOGOsで、タスクを宣言するときにプロパティをセットしたり、タスクオブジェクトのメソッドを呼ここでは、greetingプロパティを追加して、greeting
タスクを宣言するときにその値をセットしています。
例58.3 カスタマイズ可能なhello worldタスク
build.gradle// Use the default greetingtask hello(type: GreetingTask)// Customize the greetingtask greeting(type: GreetingTask) {greeting = 'greetings from GreetingTask'}
class GreetingTask extends DefaultTask {String greeting = 'hello from GreetingTask'@TaskAction
def greet() {println greeting}}

gradle -q hello greeting の出力> gradle -q hello greeting
hello from GreetingTask
greetings from GreetingTask

58.3. スタンドアロンプロジェクト

それでは、タスクをスタンドアロンプロジェクトに移動して、発行したり他ユーザーと共有したりできるようにしてみこのプロジェクトは単純なGroovyプロジェクトで、タスククラスを含むJARを生成します。
プロジェクトに対する簡単なビルドスクリプトがこちらです。
例58.4 カスタムタスクのビルド
build.gradle
apply plugin: 'groovy'
dependencies {compile gradleApi()
compile localGroovy()
}

ノ

ー

ト

:

本例のソースコードは、Gradleのバイナリ配布物またはソース配布物に含まれています。以下の場所をご参照くだsamples/customPlugin/plugin

タスククラスのソースを配置する場所は規約に従いました。

Page 360 of 436

例58.5 カスタムタスク
src/main/groovy/org/gradle/GreetingTask.groovy
package org.gradle
import org.gradle.api.DefaultTask
import org.gradle.api.tasks.TaskAction
class GreetingTask extends DefaultTask {String greeting = 'hello from GreetingTask'@TaskAction
def greet() {println greeting}}

58.3.1. タスククラスを別のプロジェクトで使う

ビルドスクリプトでタスククラスを使うためには、ビルドスクリプトのクラスパスにタスククラスを追加する必要があ
これを実行するには、「ビルドスクリプトで外部ライブラリを使うときの依存関係設定」
で説明されているとおり、 buildscript{} ブロックを使います。

次のサンプルでは、タスククラスを含むJARをローカルリポジトリに発行した場合にどのようにすればよいかを示して
例58.6 カスタムタスクを別のプロジェクトで使う
build.gradlebuildscript {repositories {maven {
url uri('../repo')}}
dependencies {classpath group: 'org.gradle', name: 'customPlugin',
version: '1.0-SNAPSHOT'}}
task greeting(type: org.gradle.GreetingTask) {greeting = 'howdy!'}

58.3.2. タスククラスのテストの作成
タスククラスのテストのために、 ProjectBuilder クラスを利用してProjectのインスタンスを生成することができます。

Page 361 of 436

例58.7 カスタムタスクのテスト
src/test/groovy/org/gradle/GreetingTaskTest.groovyclass GreetingTaskTest {@Testpublic void canAddTaskToProject() {Project project = ProjectBuilder.builder().build()
def task = project.task('greeting', type: GreetingTask)
assertTrue(task instanceof GreetingTask)}}

58.4. Incremental tasks
Incremental tasks are an incubating feature.
Since the introduction of the implementation described above (early in the Gradle 1.6
release cycle), discussions within the Gradle community have produced superior ideas for
exposing the information about changes to task implementors to what is described below.
As such, the API for this feature will almost certainly change in upcoming releases.
However, please do experiment with the current implementation and share yourexperiences with the Gradle community.
The feature incubation process, which is part of the Gradle feature lifecycle (see 付録C
機能のライフサイクル ), exists for this purpose of ensuring high quality final
implementations through incorporation of early user feedback.

With Gradle, it's very simple to implement a task that gets skipped when all of it's inputs andoutputs are up to date (see 「更新されていないタスクをスキップする」). However, there aretimes when only a few input files have changed since the last execution, and you'd like to avoid
reprocessing all of the unchanged inputs. This can be particularly useful for a transformer task,that converts input files to output files on a 1:1 basis.
If you'd like to optimise your build so that only out-of-date inputs are processed, you can do sowith an incremental task .

58.4.1. Implementing an incremental task
For a task to process inputs incrementally, that task must contain an incremental task action .
This is a task action method that contains a single IncrementalTaskInputs parameter, whichindicates to Gradle that the action will process the changed inputs only.
The incremental task action may supply an IncrementalTaskInputs.outOfDate() action forprocessing any input file that is out-of-date, and a IncrementalTaskInputs.removed()
action that executes for any input file that has been removed since the previous execution.

Page 362 of 436

例58.8 Defining an incremental task actionbuild.gradle
class IncrementalReverseTask extends DefaultTask {@InputDirectory
def File inputDir@OutputDirectory
def File outputDir@Inputdef inputProperty@TaskAction
void execute(IncrementalTaskInputs inputs) {println inputs.incremental ? "CHANGED inputs considered out of date": "ALL inputs considered out of date"
inputs.outOfDate { change ->println "out of date: ${change.file.name}"
def targetFile = new File(outputDir, change.file.name)targetFile.text = change.file.text.reverse()}
inputs.removed { change ->println "removed: ${change.file.name}"
def targetFile = new File(outputDir, change.file.name)targetFile.delete()
}
}
}

ノ

ー

ト

:

本例のソースコードは、Gradleのバイナリ配布物またはソース配布物に含まれています。以下の場所をご参照くだsamples/userguide/tasks/incrementalTask

For a simple transformer task like this, the task action simply needs to generate output files forany out-of-date inputs, and delete output files for any removed inputs.
A task may only contain a single incremental task action.

58.4.2. Which inputs are considered out of date?
When Gradle has history of a previous task execution, and the only changes to the task
execution context since that execution are to input files, then Gradle is able to determine which
input

files

need

to

be

reprocessed

by

the

task.

In

this

case,

the

IncrementalTaskInputs.outOfDate() action will be executed for any input file that wasadded or modified , and the IncrementalTaskInputs.removed() action will be executed forany removed input file.
However, there are many cases where Gradle is unable to determine which input files need to be
reprocessed. Examples include:
There is no history available from a previous execution.

Page 363 of 436

You are building with a different version of Gradle. Currently, Gradle does not use task history
from a different version.
An upToDateWhen criteria added to the task returns false.
An input property has changed since the previous execution.
One or more output files have changed since the previous execution.
In any of these cases, Gradle will consider all of the input files to be outOfDate. The
IncrementalTaskInputs.outOfDate() action will be executed for every input file, and theIncrementalTaskInputs.removed() action will not be executed at all.
You can check if Gradle was able to determine the incremental changes to input files with
IncrementalTaskInputs.isIncremental().

58.4.3. An incremental task in action
Given the incremental task implementation above, we can explore the various change scenarios
by example. Note that the various mutation tasks ('updateInputs', 'removeInput', etc) are only
present for demonstration purposes: these would not normally be part of your build script.
First, consider the IncrementalReverseTask executed against a set of inputs for the first time.
In this case, all inputs will be considered “out of date”:
例58.9 Running the incremental task for the first timebuild.gradle
task incrementalReverse(type: IncrementalReverseTask) {inputDir = file('inputs')
outputDir = file("$buildDir/outputs")
inputProperty = project.properties['taskInputProperty'] ?: "original"}

Build layout
incrementalTask/build.gradle
inputs/
1.txt
2.txt
3.txt

gradle -q incrementalReverse の出力> gradle -q incrementalReverse
ALL inputs considered out of dateout of date: 1.txt
out of date: 2.txt
out of date: 3.txt

Naturally when the task is executed again with no changes, then the entire task is up to date andno files are reported to the task action:

Page 364 of 436

例58.10 Running the incremental task with unchanged inputs
gradle -q incrementalReverse の出力> gradle -q incrementalReverse

When an input file is modified in some way or a new input file is added, then re-executing thetask results in those files being reported to IncrementalTaskInputs.outOfDate():例58.11 Running the incremental task with updated input files
build.gradle
task updateInputs() << {file('inputs/1.txt').text = "Changed content for existing file 1."
file('inputs/4.txt').text = "Content for new file 4."}gradle -q updateInputs incrementalReverse の出力> gradle -q updateInputs incrementalReverse
CHANGED inputs considered out of dateout of date: 1.txt
out of date: 4.txt

When an existing input file is removed, then re-executing the task results in that file being
reported to IncrementalTaskInputs.removed():例58.12 Running the incremental task with an input file removed
build.gradle
task removeInput() << {file('inputs/3.txt').delete()}

gradle -q removeInput incrementalReverse の出力> gradle -q removeInput incrementalReverse
CHANGED inputs considered out of dateremoved: 3.txt

When an output file is deleted (or modified), then Gradle is unable to determine which input files
are

out

of

date.

In

this

case,

all

input

files

are

reportedtotheIncrementalTaskInputs.outOfDate() action, and no input files are reported to theIncrementalTaskInputs.removed() action:

Page 365 of 436

例58.13 Running the incremental task with an output file removed
build.gradle
task removeOutput() << {file("$buildDir/outputs/1.txt").delete()}

gradle -q removeOutput incrementalReverse の出力> gradle -q removeOutput incrementalReverse
ALL inputs considered out of dateout of date: 1.txt
out of date: 2.txt
out of date: 3.txt

When a task input property is modified, Gradle is unable to determine how this property
impacted the task outputs, so all input files are assumed to be out of date. So similar to thechangedoutputfile

example,

all

input

files

are

reportedtotheIncrementalTaskInputs.outOfDate() action, and no input files are reported to theIncrementalTaskInputs.removed() action:
例58.14 Running the incremental task with an input property changed
gradle -q -PtaskInputProperty=changed incrementalReverse の出力> gradle -q -PtaskInputProperty=changed incrementalReverse
ALL inputs considered out of dateout of date: 1.txt
out of date: 2.txt
out of date: 3.txt

Page 366 of 436

59
カスタムプラグインの作成

Gradleプラグインは再利用可能なビルドロジックの断片をパッケージとしてまとめ、異なるプロジェクトやビルドで横Gradleは独自のカスタムプラグインの実装手段を提供していますので、独自のビルドロジックを再利用し、他のユーザ

カスタムプラグインは、最終的にバイトコードへコンパイルできるなら、どんな言語でもお好みの言語で実装すること
このサンプルでは実装言語としてGroovyを使います。
かわりにJavaやScalaを使うこともできますので、お好きにどうぞ。

59.1. プラグインのパッケージング
プラグインのソースを配置できる場所はいくつかあります。
ビルドスクリプト
ビルドスクリプトの中にプラグインのソースを直接含めることができます。

この方法は、特になにもしなくてもプラグインが自動的にコンパイルされ、ビルドスクリプトのクラスパスに追加

しかし、プラグインはビルドスクリプトの外部から参照できないため、プラグインが定義されているビルドスクリ
buildSrcプロジェクト
プラグインのソースを rootProjectDir /buildSrc/src/main/groovy
デ ィ レ ク ト リ に 配 置 で き ま す 。

Gradleがプラグインのコンパイルとテストを行い、ビルドスクリプトのクラスパスで有効になるようにしてくれま
プラグインは、ビルドで利用されるすべてのビルドスクリプトから参照可能です。

しかし、ビルドの外部からは参照できないので、プラグインが定義されているビルドの外部から再利用することはbuildSrcプロジェクトの詳細については、60章ビルドロジックの体系化を参照してください。
スタンドアロンプロジェクト
プラグイン用に独立したプロジェクトを作ることができます。

このプロジェクトはJARを生成して発行するので、複数のビルドで利用したり、他のユーザーと共有することができ

一般的に、このJARはカスタムプラグイン、ないしは関連するいくつかのタスククラスのバンドルする場合がありま
あるいは、その両方の組み合わせです。
このサンプルでは、簡単のためにビルドスクリプト内のプラグインからはじめます。
その後、スタンドアロンプロジェクトの作り方をみてみましょう。

Page 367 of 436

59.2. シンプルなプラグインの作成
カスタムプラグインを作るには、 Plugin の実装を作成する必要があります。

Gradleはプラグインのインスタンスを生成し、プロジェクトでプラグインが利用されるときにプラグインインスタンス
Plugin.apply()メソッドを呼びます。

プロジェクトオブジェクトがパラメータとして渡され、必要に応じてプラグインがプロジェクトを構成するのに使えま
次のサンプルは、プロジェクトにhelloタスクを追加するgreetingプラグインを含んでいます。
例59.1 カスタムプラグイン
build.gradle
apply plugin: GreetingPluginclass GreetingPlugin implements Plugin<Project> {void apply(Project project) {project.task('hello') << {println "Hello from the GreetingPlugin"}}}gradle -q hello の出力> gradle -q hello
Hello from the GreetingPlugin

注意すべきは、指定されたプラグインが適用されるプロジェクト毎に、新しいプラグインのインスタンスが生成される
note that the Plugin class is a generic type. This example has it receiving the Plugin type as a
type parameter. It's possible to write unusual custom plugins that take different type parameters,
but this will be unlikely (until someone figures out more creative things to do here).

59.3. ビルドから入力を得る
プロジェクトにシンプルなextensionオブジェクトを追加してみましょう
ここでは、プロジェクトにextensionオブジェクトgreetingを追加し、greetingタスクを構成可能にしています。

Page 368 of 436

例59.2 カスタムプラグインのextension
build.gradle
apply plugin: GreetingPlugin
greeting.message = 'Hi from Gradle'class GreetingPlugin implements Plugin<Project> {void apply(Project project) {// Add the 'greeting' extension object
project.extensions.create("greeting", GreetingPluginExtension)// Add a task that uses the configuration
project.task('hello') << {println project.greeting.message}}}
class GreetingPluginExtension {def String message = 'Hello from GreetingPlugin'}gradle -q hello の出力> gradle -q hello
Hi from Gradle

この例では、GreetingPluginExtensionはmessageフィールドを持つPOGO(plain old Groovy
object)です。 extensionオブジェクトはgreetingという名前でプラグインリストに追加されます。
このオブジェクトは、extensionオブジェクトと同じ名前のプロジェクトプロパティとして有効になります。
しばしば、ひとつのプラグインに対していくつかの関連したプロパティを指定する必要がある場合があります。
Gradleはそれぞれのextensionオブジェクトに対してコンフィグレーションクロージャブロックを追加するので、グループの設定をまとめて行うことができます。
次のサンプルは、これがどのように働くのかを示しています。

Page 369 of 436

例59.3 コンフィグレーションクロージャ付きのカスタムプラグイン
build.gradle
apply plugin: GreetingPlugin
greeting {message = 'Hi'
greeter = 'Gradle'}class GreetingPlugin implements Plugin<Project> {void apply(Project project) {project.extensions.create("greeting", GreetingPluginExtension)
project.task('hello') << {println "${project.greeting.message} from ${project.greeting.greeter}"}}}class GreetingPluginExtension {String message
String greeter}

gradle -q hello の出力> gradle -q hello
Hi from Gradle

こ の 例 で は 、 g r e e t i n g
クロージャ内にいくつかの設定をグループ化してまとめることができています。
ビルドスクリプトにおけるクロージャブロックの名前( greeting)は、extensionオブジェクトの名前と一致している必要があります。

そして、クロージャが実行されると、Groovyの標準のクロージャ委譲機能に基づいて、extensionオブジェクトのフィ

59.4.
カスタムタスクやプラグインでファイルを扱う

カスタムタスクやプラグインを開発するとき、ファイルロケーションの入力コンフィグレーションを柔軟に行えるようこれを実現するにあたり、ファイルに対する値の解決をなるべく遅らせるためにProject.file()
メソッドを活用できます

Page 370 of 436

例59.4 ファイルプロパティの遅延評価
build.gradle
class GreetingToFileTask extends DefaultTask {def destination
File getDestination() {project.file(destination)}@TaskAction
def greet() {def file = getDestination()file.parentFile.mkdirs()
file.write "Hello!"}}
task greet(type: GreetingToFileTask) {destination = { project.greetingFile }}task sayGreeting(dependsOn: greet) << {println file(greetingFile).text}
ext.greetingFile = "$buildDir/hello.txt"

gradle -q sayGreeting の出力> gradle -q sayGreeting
Hello!

この例では、 greetタスクの destination プロパティをクロージャで定義したので、クロージャの戻り値をfileオブジェクトに変換することが必要になる直前にProject.file()
メ ソ ッ ド に よ っ て 評 価 さ れ ま す 。
上記のサンプルでは、タスクで値を利用するコンフィグレーションを行った後でgreetingFile
プロパティの値を指定していることに気づくでしょう。

この種の遅延評価は、ファイルプロパティを設定する際に任意の値を受け入れ、そしてプロパティの読み出し時に値を59.5. スタンドアロンプロジェクト

それでは、プラグインをスタンドアロンプロジェクトに移動して、発行して他のユーザーと共有できるようにしましょこのプロジェクトは、プラグインクラスを含むJARを発行する単なるGroovyプロジェクトです。
プロジェクトに対するシンプルなビルドスクリプトはこのようになります。
Groovyプラグインを適用して、コンパイル時の依存関係としてGradle APIを追加しています。

Page 371 of 436

例59.5 カスタムプラグインに対するビルド
build.gradle
apply plugin: 'groovy'
dependencies {compile gradleApi()
compile localGroovy()
}

ノ

ー

ト

:

本例のソースコードは、Gradleのバイナリ配布物またはソース配布物に含まれています。以下の場所をご参照くだsamples/customPlugin/plugin

GradleはどのようにしてPluginの実装を探すのでしょうか？ その答えは、JARのMETA-INF/gradle-plugins
デ

ィ

レ

ク

ト

リ

に

、

プラグインのIDに対応するプロパティファイルを提供する必要があるということです。
例59.6 カスタムプラグインに対するワイヤリング
src/main/resources/META-INF/gradle-plugins/org.samples.greeting.properties
implementation-class=org.gradle.GreetingPlugin

プロパティファイルの名前がプラグインIDと一致していてリソースフォルダに配置されていること、
implementation-classプロパティにPluginの実装クラスを指定していることに注意してください。

59.5.1. Creating a plugin id
Plugin ids are fully qualified in a manner similar to Java packages (i.e. a reverse domain name).
This helps to avoid collisions and provides a way to group plugins with similar ownership.
Your plugin id should be a combination of components that reflect namespace (a reasonable
pointer to you or your organization) and the name of the plugin it provides. For example if you
had a Github account named “foo” and your plugin was named “bar”, a suitable plugin id
might be com.github.foo.bar. Similarly, if the plugin was developed at the baz organization,
the plugin id might be org.baz.bar.
Plugin ids should conform to the following:
May contain any alphanumeric character, '.', and '-'.
Must contain at least one '.' character separating the namespace from the name of the plugin.
Conventionally use a lowercase reverse domain name convention for the namespace.
Conventionally use only lowercase characters in the name.
org.gradle and com.gradleware namespaces may not be used.
Cannot start or end with a '.' character.
Cannot contain consecutive '.' characters (i.e. '..').

Page 372 of 436

Although there are conventional similarities between plugin ids and package names, package
names are generally more detailed than is necessary for a plugin id. For instance, it might seemreasonable to add “gradle” as a component of your plugin id, but since plugin ids are onlyused for Gradle plugins, this would be superfluous. Generally, a namespace that identifies
ownership and a name are all that are needed for a good plugin id.

59.5.2. Publishing your plugin
If you are publishing your plugin internally for use within your organization, you can publish it
like any other code artifact. See the ivy and maven chapters on publishing artifacts.
If you are interested in publishing your plugin to be used by the wider Gradle community, you
can publish it to the Gradle plugin portal. This site provides the ability to search for and gather
information about plugins contributed by the Gradle community. See the instructions here on
how to make your plugin available on this site.

59.5.3. 別のプロジェクトでプラグインを使う

ビルドスクリプトでプラグインを使うためには、ビルドスクリプトのクラスパスにプラグインクラスを追加する必要が

このために、「ビルドスクリプトで外部ライブラリを使うときの依存関係設定」で説明したように、buildscript {ブ ロ ッ ク が 使 え ま す
次のサンプルは、プラグインを含むJARがローカルリポジトリに発行済みのときにこれを行う方法を示しています:
例59.7 別のプロジェクトでカスタムプラグインを使う
build.gradlebuildscript {repositories {maven {
url uri('../repo')}}
dependencies {classpath group: 'org.gradle', name: 'customPlugin',
version: '1.0-SNAPSHOT'}}
apply plugin: 'org.samples.greeting'

Alternatively, if your plugin is published to the plugin portal, you can use the incubating plugins
DSL (see 「Applying plugins with the plugins DSL」) to apply the plugin:
例59.8 Applying a community plugin with the plugins DSL
build.gradleplugins {id "com.jfrog.bintray" version "0.4.1"}

Page 373 of 436

59.5.4. プラグインに対するテストの作成
プラグイン実装をテストするときには、Projectインスタンスを生成するために ProjectBuilder
クラスが利用できます。
例59.9 カスタムプラグインのテスト
src/test/groovy/org/gradle/GreetingPluginTest.groovyclass GreetingPluginTest {@Testpublic void greeterPluginAddsGreetingTaskToProject() {Project project = ProjectBuilder.builder().build()
project.apply plugin: 'org.samples.greeting'assertTrue(project.tasks.hello instanceof GreetingTask)}}

59.5.5. Using the Java Gradle Plugin development plugin
You can use the incubating Java Gradle Plugin development plugin to eliminate some of theboilerplate declarations in your build script and provide some basic validations of plugin
metadata. This plugin will automatically apply the Java plugin, add the gradleApi()
dependency to the compile configuration, and perform plugin metadata validations as part of
the jar task execution.
例59.10 Using the Java Gradle Plugin Development pluginbuild.gradle
apply plugin: 'java-gradle-plugin'59.6. 複数のドメインオブジェクトの管理

Gradleはオブジェクトのコレクションを管理するためのユーティリティクラスを提供しており、それらはGradleビルド

Page 374 of 436

例59.11 ドメインオブジェクトの管理
build.gradle
apply plugin: DocumentationPlugin
books {
quickStart {sourceFile = file('src/docs/quick-start')}
userGuide {}developerGuide {}}task books << {books.each { book ->println "$book.name -> $book.sourceFile"}}class DocumentationPlugin implements Plugin<Project> {void apply(Project project) {def books = project.container(Book)
books.all {sourceFile = project.file("src/docs/$name")}
project.extensions.books = books}}
class Book {final String name
File sourceFile
Book(String name) {this.name = name}}gradle -q books の出力> gradle -q books
developerGuide -> /home/user/gradle/samples/userguide/organizeBuildLogic/customPluginWithDomainO
quickStart -> /home/user/gradle/samples/userguide/organizeBuildLogic/customPluginWithDomainObjec
userGuide -> /home/user/gradle/samples/userguide/organizeBuildLogic/customPluginWithDomainObject

Project.container()メソッドは、
オブジェクトの管理やコンフィグレーションに便利な多くのメソッドを提供する
NamedDomainObjectContainerのインスタンスを生成します。
のメソッドでタイプを扱うためには、

project.container

オブジェクトのユニークかつ固定の名前を提供する“name”プロパティを公開しなければなりません。

project.container(Class)

メソッドおよびそのバリエーションは、
単一のstringを引数として取るクラスのコンストラクタの実行を試みることで新しいインスタンスを生成します。
このとき、引数はオブジェクトの名前となることが期待されます。
Page 375 of 436

カスタムのインスタンス化戦略を可能にするproject.container
メソッドのバリエーションについては、上記のリンクを参照してください。

Page 376 of 436

60
ビルドロジックの体系化

Gradleでは、様々な方法でビルドロジックを体系化できます。最初は、すべてのビルドロジックがタスクのクロージャ
[

4

1

]

Gradleでは、決まったディレクトリにクラスを放り込んでおけば自動的にコンパイルしてクラスパスに追加してくれる
ビルドロジックを体系化する方法について、いくつか例を挙げます。
POGOs。plainoldGroovyObjects(POGOs)をビルドスクリプト内で直接宣言して使用できます。結局のところビルドスクリプトはGroovyで書くわけですから
プ ロ パ テ ィ と メ ソ ッ ド の 継 承。マルチプロジェクトでは、すべてのサブプロジェクトが親プロジェクトからプロパティとメソッドを継承します
設 定 の イ ン ジ ェ ク シ ョ ン。マルチプロジェクトでは、あるプロジェクト(普通ルートプロジェクトですが)が別のプロジェクトにプロパティと
b u i l d S r c プ ロ ジ ェ ク ト。ビルドスクリプトで使いたいクラスのソースを決まったディレクトリに入れておけば、Gradleは自動的にそのク
共

有

ス

ク

リ

プ

ト

。外部のスクリプトファイルに共通で使う設定を定義して、それをいろいろなプロジェクトのビルドスクリプトで
カ

ス

タ

ム

タ

ス

ク

。ビルドロジックをカスタムタスクにすれば、いろんな場所でそのロジックを再利用できます。
カ ス タ ム プ ラ グ イ ン。ビルドロジックをカスタムプラグインにすれば、いろんなプロジェクトでそのプラグインを適用することができ
buildSrcプロジェクトや外部ライブラリにそのプラグインを含めれば簡単に追加できます。
外部ビルドの実行。現在のビルドから、外部の別のビルドを呼び出すことができます。
外部ライブラリ。外部のライブラリを直接ビルドで使うことができます。

60.1. プロパティとメソッドの継承

プロジェクト内で定義されたプロパティとメソッドは、そのプロジェクトのサブプロジェクトでもすべて使用できます

Page 377 of 436

例60.1 プロパティとメソッドの継承を使う
build.gradle// Define an extra property
ext.srcDirName = 'src/java'// Define a method
def getSrcDir(project) {return project.file(srcDirName)}

child/build.gradle
task show << {// Use inherited property
println 'srcDirName: ' + srcDirName// Use inherited method
File srcDir = getSrcDir(project)
println 'srcDir: ' + rootProject.relativePath(srcDir)}

gradle -q show の出力> gradle -q show
srcDirName: src/java
srcDir: child/src/java

60.2. 設定のインジェクション
「クロスプロジェクト設定」や「サブプロジェクトの設定」

で紹介した設定のインジェクションを使って、複数のプロジェクトにプロパティとメソッドを注入できます。設定のイ

Page 378 of 436

例60.2 プロパティとメソッドのインジェクション
build.gradle
subprojects {// Define a new property
ext.srcDirName = 'src/java'// Define a method using a closure as the method body
ext.srcDir = { file(srcDirName) }// Define a task
task show << {println 'project: ' + project.path
println 'srcDirName: ' + srcDirName
File srcDir = srcDir()
println 'srcDir: ' + rootProject.relativePath(srcDir)}}// Inject special case configuration into a particular projectproject(':child2') {ext.srcDirName = "$srcDirName/legacy"}

child1/build.gradle// Use injected property and method. Here, we override the injected value
srcDirName = 'java'
def dir = srcDir()

gradle -q show の出力> gradle -q show
project: :child1
srcDirName: java
srcDir: child1/java
project: :child2
srcDirName: src/java/legacy
srcDir: child2/src/java/legacy

60.3. buildSrc
プロジェクトのソースをビルドする
Gradleは実行されたときに buildSrc というディレクトリがないか確認します。
そして、中のコードを自動的にコンパイル、テストして、ビルドスクリプトのクラスパスに追加してくれるのです。

何かを設定する必要は一切ありません。このディレクトリは、カスタムタスクやプラグインを追加するのに適していま
マルチプロジェクトのビルドでは、ルートプロジェクトに一つだけbuildSrc
ディレクトリを作成できます。
buildSrcプロジェクトには、次のビルドスクリプトがデフォルトで適用されます。

Page 379 of 436

図60.1 デフォルトのbuildSrcビルドスクリプト
apply plugin: 'groovy'
dependencies {compile gradleApi()
compile localGroovy()}

つまり、Java/Groovyプロジェクトのレイアウト規約(表23.4「Javaプラグイン-

デフォルトプロジェクトレイアウト」
参照)に従って、このディレクトリにソースコードを置くだけでいいということです。
さらに柔軟性が必要なときは、自分で build.gradle を用意することもできます。

上記のデフォルトビルドスクリプトは、この場合でも適用されます。つまり、必要なものだけを追加で定義できるのでAPIへの依存関係は、デフォルトのビルドスクリプトで宣言されているため、ここでは宣言する必要がありません。
例60.3 カスタムbuildSrcビルドスクリプト
buildSrc/build.gradle
repositories {mavenCentral()}dependencies {testCompile 'junit:junit:4.11'}

buildSrc

プロジェクトは、マルチプロジェクトにすることができます。このプロジェクトは、普通のGradleマルチプロジェクト
ただし、実際のビルドのクラスパスに置きたい全てのプロジェクトを、buildSrcルートプロジェクトの
r

u

n

t

i

m

e

依存関係にしなければなりません。これは、エクスポートしたい全てのプロジェクトの設定に、以下のコードを追加す
例60.4 buildSrcルートプロジェクトにサブプロジェクトを追加する
buildSrc/build.gradle
rootProject.dependencies {runtime project(path)
}

ノ

ー

ト

:

本例のソースコードは、Gradleのバイナリ配布物またはソース配布物に含まれています。以下の場所をご参照くだsamples/multiProjectBuildSrc

Page 380 of 436

60.4.
別のGradleビルドを、現在のビルドから呼び出して実G r a d l e B u i l d

で別のビルドを呼び出して実行することができます。そのとき、呼び出すビルドのディレクトリやビルドスクリプトに例60.5 別のビルドを呼び出す
build.gradle
task build(type: GradleBuild) {buildFile = 'other.gradle'tasks = ['hello']}

other.gradle
task hello << {println "hello from the other build."}

gradle -q build の出力> gradle -q build
hello from the other build.

60.5.
ビルドスクリプトで外部ライブラリを使うときの依存関

ビルドスクリプトを実行するときに外部のライブラリを使いたいなら、そのライブラリをビルドスクリプトのクラスパ
b u i l d s c r i p t ( )メソッドにクロージャを渡し、その中でビルドスクリプトのクラスパスを設定できます。
例60.6 ビルドスクリプトのクラスパスを宣言する
build.gradlebuildscript {repositories {mavenCentral()}dependencies {classpath group: 'commons-codec', name: 'commons-codec', version: '1.2'}}

buildscript()メソッドに渡すクロージャは、ScriptHandlerのインスタンスにパラメータなどを設定するものです。ビルドスクリプトのクラスパスを追加するには、
c l a s s p a t hPage 381 of 436

で依存関係を宣言しましょう。形式はJavaでコンパイル時のクラスパスを宣言するときなどと同じです。
「 依 存 関 係 の 定 義 方 法」に記載されているタイプの依存関係は、「プロジェクトへの依存」を除けばすべて使えます。

外部ライブラリのクラスをビルドスクリプトのクラスパスを追加すれば、他のクラスと同じようにスクリプト内で使え
例60.7 外部ライブラリをビルドスクリプトで使用する
build.gradle
import org.apache.commons.codec.binary.Base64
buildscript {repositories {mavenCentral()}dependencies {classpath group: 'commons-codec', name: 'commons-codec', version: '1.2'}}
task encode << {def byte[] encodedString = new Base64().encode('hello world\n'.getBytes())
println new String(encodedString)}

gradle -q encode の出力> gradle -q encodeaGVsbG8gd29ybGQK

マルチプロジェクトの場合、プロジェクトのビルドスクリプトでクラスパスを宣言すれば、そのサブプロジェクトすべ

60.6. Antオプショナルタスクの依存関係

何でかよく分からないのですが、Antのオプショナルタスクでは先ほどの方法で追加した外部ライブラリを拾ってくれ

Page 382 of 436

例60.8 Ant optional dependencies
build.gradle
configurations {ftpAntTask}
dependencies {ftpAntTask("org.apache.ant:ant-commons-net:1.9.3") {module("commons-net:commons-net:1.4.1") {dependencies "oro:oro:2.0.8:jar"}}}task ftp << {ant {taskdef(name: 'ftp',
classname: 'org.apache.tools.ant.taskdefs.optional.net.FTP',
classpath: configurations.ftpAntTask.asPath)
ftp(server: "ftp.apache.org", userid: "anonymous", password: "me@myorg.com") {fileset(dir: "htdocs/manual")}}}This is also a good example for the usage of client modules. The POM file in Maven Central forthe ant-commons-net task does not provide the right information for this use case.

これはクライアントモジュールのいい使用例でもあります。mavenのセントラルリポジトリにあるant-commons-net
pom.xmlは、このユースケースのための正しい情報を提供していません。

60.7. まとめ

Gradleは、ビルドロジックを体系化するための様々な方法を提供しています。自分の分野に合った方法を選択して、不[41] 一つの単純なクラスから、複雑なクラスまで

Page 383 of 436

61
初期化スクリプト

Gradleは、実行環境に合わせてビルドをカスタマイズするためのパワフルな仕組みを提供しています。また、この仕組
Note that this is completely different from the “init” task provided by the “build-init”
incubating plugin (see Chapter 47, Build Init Plugin).

61.1. 基本的な使い方
初期化スクリプト( init

scripts)は、Gradleで使う他のスクリプトと似たものですが、ビルドの開始前に実行されます。使用する場面としては次のよ
企業内で適用される設定、たとえば、カスタムプラグインのダウンロード先などを設定する。

実行環境に依るプロパティをセットする。たとえば、開発者のマシンとインテグレーションサーバーで異なるプロ
ビルド時に要求される、ユーザーの個人情報をセットする。リポジトリやデータベースの認証情報など。
マシン固有の情報を定義する。JDKのインストール場所など。
ビルドのリスナーを登録する。Gradleのイベントをリスンしたい外部ツールにとって便利かもしれません。

ビルドのロガーを登録する。Gradleがイベントを記録する方法をカスタマイズしたいことがあるかもしれません。
初期化スクリプトの主な制限は、buildSrc
プロジェクトにアクセスできないことです（この機能の詳細は「buildSrc
プロジェクトのソースをビルドする」を参照してください）。

61.2. 初期化スクリプトを使う
初期化スクリプトを使うには、いくつかの方法があります。
コマンドラインでファイルを指定する。 -I か --init-script

オプションに初期化スクリプトのパスを渡します。このオプションを複数並べて、初期化スクリプトを追加していinit.gradleという名前のファイルを USER_HOME /.gradle/ディレクトリに置く。
.gradleという拡張子のファイルを USER_HOME /.gradle/init.d/ディレクトリに置く。
.gradleという拡張子のファイルを GRADLE_HOME /init.d/

ディレクトリ、つまりGradleのディストリビューションの中に置く。この機能により、独自のビルドロジックとプ
G r a d l e ラ ッ パ ー
機能を組み合わせれば、企業内のすべてのビルドで独自のビルドロジックを使えるようにもできます。

複数の初期化スクリプトが見つかった場合、そのすべてが上で記載した順番で実行されます。同じディレクトリのスク

Page 384 of 436

61.3. 初期化スクリプトを記述する
Gradleのビルドスクリプトと同様、初期化スクリプトもGroovyスクリプトです。すべての初期化スクリプトに
G

r

a

d

l

e

のインスタンスが割り当てられ、初期化スクリプト内でのプロパティアクセス、メソッドコールはすべてこのGradleインスタンスに委譲されます。
また、すべての初期化スクリプトはScriptインターフェースを実装しています。

61.3.1. 初期化スクリプトでプロジェクトを設定する

初期化スクリプトを使ってプロジェクトの設定を変更することができます。これは、マルチプロジェクトでプロジェク
前に、初期化スクリプトで追加的な設定を行うための方法を示すものです。このサンプルでは、ある環境でのみ使用する特例61.1 プロジェクト評価前に初期化スクリプトで追加的な設定を行う
build.gradle
repositories {mavenCentral()}task showRepos << {println "All repos:"println repositories.collect { it.name }}init.gradle
allprojects {repositories {mavenLocal()}}

gradle --init-script init.gradle -q showRepos の出力> gradle --init-script init.gradle -q showRepos
All repos:[MavenLocal, MavenRepo]

61.4. 初期化スクリプトの外部依存関係「ビルドスクリプトで外部ライブラリを使うときの依存関係設定」

でビルドスクリプトに依存関係を追加する方法が解説されていますが、初期化スクリプトでも似たような方法で依存関i n i t s c r i p t ( )メソッドに初期化スクリプトのクラスパスを宣言したクロージャを引き渡してください。

Page 385 of 436

例61.2 初期化スクリプトの外部依存関係定義
init.gradle
initscript {repositories {mavenCentral()}dependencies {classpath group: 'org.apache.commons', name: 'commons-math', version: '2.0'}}

initscript()に渡したクロージャは、ScriptHandler
インスタンスを設定します。これは、たとえば、Javaのコンパイルクラスパスを宣言するのと同じ方法です。
「 依 存 関 係 の 定 義 方 法」に載っている依存関係は、プロジェクト依存関係を除いてすべて使うことができます。

このようにして初期化スクリプトのクラスパスを宣言すれば、初期化スクリプト内でどんなクラスでもインポートでき
例61.3 外部依存関係を持つ初期化スクリプト
init.gradle
import org.apache.commons.math.fraction.Fraction
initscript {repositories {mavenCentral()}dependencies {classpath group: 'org.apache.commons', name: 'commons-math', version: '2.0'}}
println Fraction.ONE_FIFTH.multiply(2)gradle --init-script init.gradle -q doNothing の出力> gradle --init-script init.gradle -q doNothing
2 / 5

61.5. Init script plugins
Similar to a Gradle build script or a Gradle settings file, plugins can be applied on init scripts.

Page 386 of 436

例61.4 Using plugins in init scripts
init.gradle
apply plugin:EnterpriseRepositoryPluginclass EnterpriseRepositoryPlugin implements Plugin<Gradle> {private static String ENTERPRISE_REPOSITORY_URL = "https://repo.gradle.org/gradle/repo"
void apply(Gradle gradle) {// ONLY USE ENTERPRISE REPO FOR DEPENDENCIES
gradle.allprojects{ project ->project.repositories {// Remove all repositories not pointing to the enterprise repository url
all { ArtifactRepository repo ->if (!(repo instanceof MavenArtifactRepository) ||repo.url.toString() != ENTERPRISE_REPOSITORY_URL) {project.logger.lifecycle "Repository ${repo.url} removed. Only $ENTERPRI
remove repo}}// add the enterprise repository
maven {
name "STANDARD_ENTERPRISE_REPO"
url ENTERPRISE_REPOSITORY_URL
}
}
}
}
}

build.gradle
repositories{
mavenCentral()}task showRepositories << {repositories.each{println "repository: ${it.name} ('${it.url}')"}}gradle -q -I init.gradle showRepositories の出力> gradle -q -I init.gradle showRepositories
repository: STANDARD_ENTERPRISE_REPO ('https://repo.gradle.org/gradle/repo')

The plugin in the init script ensures that only a specified repository is used when running thebuild.
When applying plugins within the init script, Gradle instantiates the plugin and calls the plugin
instance's Plugin.apply() method. The gradle object is passed as a parameter, which can beused to configure all aspects of a build. Of course, the applied plugin can be resolved as anexternal dependency as described in 「初期化スクリプトの外部依存関係」

Page 387 of 436

62Gradleラッパー
Gradleラッパー（以後ラッパーとします）は、Gradleのビルドを実行する方法として推奨されているものです。
ラッパーは、バッチスクリプト（Windows用）とシェルスクリプト（その他のOS用）で提供されます。

このラッパーを使ってGradleビルドを実行すると、Gradleが自動的にダウンロードされ、それを使ってビルドが実行さラッパーは、バージョン管理システムにチェックインする べきです。ラッパーと一緒にプロジェクトを配布することで、前もってGradleをインストールすることなく、誰もがすぐプ

さらにいいことに、ラッパーを使ってもらうことで、ビルドに使用されるGradleのバージョンをプロジェクトが想定しもちろん、ラッパーは継続的インテグレーション
サーバーで作業するときも非常に便利です。サーバーでビルドの設定を行う必要がないからです。
ラッパーを自分のプロジェクトにインストールするには、 Wrapper
タスクをビルドスクリプトに追加、設定してから、タスクを実行します。
例62.1 ラッパータスク
build.gradle
task wrapper(type: Wrapper) {gradleVersion = '2.0'}

このタスクを実行すると、(wrapperタスクのデフォルト設定が使われていれば、)プロジェクトディレクトリで以下の例62.2 ラッパーにより生成されるファイル
Build layout
simple/gradlew
gradlew.bat
gradle/wrapper/
gradle-wrapper.jar
gradle-wrapper.properties

これらのファイルは、すべてバージョン管理システムに格納する べきです。この作業は一回だけ行えば大丈夫です。これらのファイルがプロジェクトに追加されたら、以後のビルドはこの
gradlew コマンドで行ってください。

gradlew コマンドは、 gradle コマンドと 全く同じように使うことができます。

Gradleを新しいバージョンに変更する場合でも、wrapperタスクを再実行する必要はありません。 gradle-wrapper
ファイルの、関係するエントリを変更するだけです。

Page 388 of 436

ただ、例えばgradle-wrapperの機能が改良された場合などは、wrapperファイルを再作成してください。

62.1. 設定
g

r

a

d

l

e

w

を実行すると、ラッパーはまず、指定されたディストリビューションが利用できるかどうか確認します。
利用できなければディストリビューションを新しくダウンロードし、利用可能ならgradlew
コマンドに指定された引数を、そのディストリビューションのgradle
コマンドにそのまま渡して実行します。
W

r

a

p

p

e

r

タスクを設定する際は、使いたいGradleのバージョンを指定することができます。その場合、作成される
g

r

a

d

l

e

w

コマンドはGradleリポジトリから適切なディストリビューションを選んでダウンロードします。
または、GradleのディストリビューションをダウンロードするURLを直接指定することもできます。この場合は、gradlew コマンドはディストリビューションのダウンロードにそのURLを使用します。

Gradleのバージョンもダウンロード先も指定しなかった場合は、ラッパーファイルを作成したGradleのバージョンがダ
For the details on how to configure the wrapper, see the Wrapper class in the API
documentation.
ラッパーの詳細な設定方法についてはWrapperを参照してください。
g

r

a

d

l

e

w

コマンドでプロジェクトをビルドする際、ダウンロード処理を一切走らせたくない場合は、ラッパーの設定で指定した
相対パスもサポートされています。gradle-wrapper.properties
からの相対パスでディストリビューションファイルを指定することができます。

ラッパーを使ってビルドする場合、マシンにインストールされているGradleディストリビューションがあっても無視さ62.2. Unixファイルパーミッション
Wrapperタスクは、生成したgradlew*NIXコマンドを実行できるよう、適切なファイルパーミッションを追加します。

Subversionはちゃんとこのファイルパーミッションを保存してくれますが、他のバージョン管理システムではどのよう確実を期すならsh gradlewで実行してください。

Page 389 of 436

63
Embedding Gradle
63.1. Introduction to the Tooling API
The 1.0 milestone 3 release brought a new API called the tooling API, which you can use for
embedding Gradle into your own custom software. This API allows you to execute and monitor
builds, and to query Gradle about the details of a build. The main audience for this API will be
IDEs, CI servers, other UI authors, or integration testing of your Gradle plugins. However, it isopen for anyone who needs to embed Gradle in their application.
A fundamental characteristic of the tooling API is that it operates in a version independent way.
This means that you can use the same API to work with different target versions of Gradle. The
tooling API is Gradle wrapper aware and, by default, uses the same target Gradle version as thatused by the wrapper-powered project.
Some features that the tooling API provides today:
You can query Gradle for the details of a build, including the project hierarchy and the
project dependencies, external dependencies (including source and Javadoc jars), source
directories and tasks of each project.
You can execute a build and listen to stdout and stderr logging and progress (e.g. the stuff
shown in the 'status bar' when you run on the command line).
Tooling API can download and install the appropriate Gradle version, similar to the wrapper.
Bear in mind that the tooling API is wrapper aware so you should not need to configure a
Gradle distribution directly.
The implementation is lightweight, with only a small number of dependencies. It is also awell-behaved library, and makes no assumptions about your classloader structure or logging
configuration. This makes the API easy to bundle in your application.
In the future we may support other interesting features:
Performance. The API gives us the opportunity to do lots of caching, static analysis andpreemptive work, to make things faster for the user.
Better progress monitoring and build cancellation. For example, allowing test execution to bemonitored.
Notifications when things in the build change, so that UIs and models can be updated. For
example, your Eclipse or IDEA project will update immediately, in the background.
Validating and prompting for user supplied configuration.
Prompting for and managing user credentials.

Page 390 of 436

63.2. Tooling API and the Gradle Build
DaemonPlease take a look at 19章Gradleデーモン . The Tooling API uses the daemon all the time. In fact,
you cannot officially use the Tooling API without the daemon. This means that subsequent calls
to the Tooling API, be it model building requests or task executing requests can be executed in
the same long-living process. 19章Gradleデーモン contains more details about the daemon,
specifically information on situations when new daemons are forked.

63.3. Quickstart
As the tooling API is an interface for developers, the Javadoc is the main documentation for it.
This is exactly our intention - we don't expect this chapter to grow very much. Instead we will
add more code samples and improve the Javadoc documentation. The main entry point to thetooling API is the GradleConnector. You can navigate from there to find code samples andother instructions. Another very important set of resources are the samples that live in “$gradleHome/samples”. These samples also specify all of the required dependencies for the Tooling API, along withthe suggested repositories to obtain the jars from.

Page 391 of 436

64Comparing Builds
Build comparison support is an incubating feature. This means that it is incomplete and not
yet at regular Gradle production quality. This also means that this Gradle User Guide
chapter is a work in progress.

Gradle provides support for comparing the outcomes (e.g. the produced binary archives) of twobuilds. There are several reasons why you may want to compare the outcomes of two builds. You
may want to compare:
A build with a newer version of Gradle than it's currently using (i.e. upgrading the Gradle
version).
A Gradle build with a build executed by another tool such as Apache Ant, Apache Maven or
something else (i.e. migrating to Gradle).
The same Gradle build, with the same version, before and after a change to the build (i.e.
testing build changes).
By comparing builds in these scenarios you can make an informed decision about the Gradle
upgrade, migration to Gradle or build change by understanding the differences in the outcomes.
The comparison process produces a HTML report outlining which outcomes were found to be
identical and identifying the differences between non-identical outcomes.

64.1. Definition of terms
The following are the terms used for build comparison and their definitions.
“Build”
In the context of build comparison, a build is not necessarily a Gradle build. It can be any
invokable “process” that produces observable “outcomes”. At least one of the builds in acomparison will be a Gradle build.
“Build Outcome”
Something that happens in an observable manner during a build, such as the creation of a zip
file or test execution. These are the things that are compared.
“Source Build”
The build that comparisons are being made against, typically the build in its “current”
state. In other words, the left hand side of the comparison.
Page 392 of 436

“Target Build”
The build that is being compared to the source build, typically the “proposed” build. In
other words, the right hand side of the comparison.
“Host Build”
The Gradle build that executes the comparison process. It may be the same project as either
the “target” or “source” build or may be a completely separate project. It does not need
to be the same Gradle version as the “source” or “target” builds. The host build must be
run with Gradle 1.2 or newer.
“Compared Build Outcome”
Build outcomes that are intended to be logically equivalent in the “source” and “target”
builds, and are therefore meaningfully comparable.
“Uncompared Build Outcome”
A build outcome is uncompared if a logical equivalent from the other build cannot be found(e.g. a build produces a zip file that the other build does not).
“Unknown Build Outcome”
A build outcome that cannot be understood by the host build. This can occur when thesource or target build is a newer Gradle version than the host build and that Gradle version
exposes new outcome types. Unknown build outcomes can be compared in so far as they canbe identified to be logically equivalent to an unknown build outcome in the other build, but
no meaningful comparison of what the build outcome actually is can be performed. Using thelatest Gradle version for the host build will avoid encountering unknown build outcomes.

64.2. Current Capabilities
As this is an incubating feature, a limited set of the eventual functionality has been implemented
at this time.

64.2.1. Supported builds
Only support for comparing Gradle builds is available at this time. Both the source and target
build must execute with Gradle newer or equal to version 1.0. The host build must be at leastversion 1.2.
Future versions will provide support for executing builds from other build systems such as
Apache Ant or Apache Maven, as well as support for executing arbitrary processes (e.g. shell
script based builds)

64.2.2. Supported build outcomes
Only support for comparing build outcomes that are zip archives is supported at this time. This
includes jar, war and ear archives.
Future versions will provide support for comparing outcomes such as test execution (i.e. whichtests were executed, which tests failed, etc.)
Page 393 of 436

64.3. Comparing Gradle Builds
The compare-gradle-builds plugin can be used to facilitate a comparison between two
Gradle builds. The plugin adds a CompareGradleBuilds task named “compareGradleBuilds” to the project. The configuration of this task specifies what is to be compared. By default, it isconfigured to compare the current build with itself using the current Gradle version by executing
the tasks: “clean assemble”.

apply plugin: 'compare-gradle-builds'

This task can be configured to change what is compared.

compareGradleBuilds {sourceBuild {
projectDir "/projects/project-a"
gradleVersion "1.1"}
targetBuild {
projectDir "/projects/project-b"
gradleVersion "1.2"}}

The example above specifies a comparison between two different projects using two different
Gradle versions.

64.3.1. Trying Gradle upgrades
You can use the build comparison functionality to very quickly try a new Gradle version with yourbuild.
To try your current build with a different Gradle version, simply add the following to the build.gradleof the root project .

apply plugin: 'compare-gradle-builds'
compareGradleBuilds {targetBuild.gradleVersion = "«gradle version»"}

Then simply execute the compareGradleBuilds task. You will see the console output of the“source” and “target” builds as they are executing.

Page 394 of 436

64.3.2. The comparison “result”
If there are any differences between the compared outcomes , the task will fail. The location of
the HTML report providing insight into the comparison will be given. If all compared outcomesare found to be identical, and there are no uncompared outcomes, and there are no unknown
build outcomes, the task will succeed.
You can configure the task to not fail on compared outcome differences by setting the ignoreFailuresproperty to true.

compareGradleBuilds {ignoreFailures = true}

64.3.3. Which archives are compared?
For an archive to be a candidate for comparison, it must be added as an artifact of the archives
configuration. Take a look at 52章アーティファクトの公開 for more information on how to
configure and add artifacts.
The archive must also have been produced by a Zip, Jar, War, Ear task. Future versions ofGradle will support increased flexibility in this area.

Page 395 of 436

65
Ivy Publishing (new)This chapter describes the new incubating Ivy publishing support provided by the “ivy-publish” plugin. Eventually this new publishing support will replace publishing via the Uploadtask.
If you are looking for documentation on the original Ivy publishing support using the Upload
task please see 52章アーティファクトの公開 .

This chapter describes how to publish build artifacts in the Apache Ivy format, usually to arepository for consumption by other builds or projects. What is published is one or more artifacts
created by the build, and an Ivy module descriptor (normally ivy.xml) that describes theartifacts and the dependencies of the artifacts, if any.
A published Ivy module can be consumed by Gradle (see 51章依存関係の管理 ) and other toolsthat understand the Ivy format.

65.1. The “ivy-publish” Plugin
The ability to publish in the Ivy format is provided by the “ ivy-publish” plugin.
The “publishing” plugin creates an extension on the project named “ publishing” oftype PublishingExtension. This extension provides a container of named publications and acontainer of named repositories. The “ivy-publish” plugin works with IvyPublication
publications and IvyArtifactRepository repositories.
Example 65.1. Applying the “ivy-publish” pluginbuild.gradle
apply plugin: 'ivy-publish'

Applying the “ivy-publish” plugin does the following:
Applies the “publishing” plugin
Establishes a rule to automatically create a GenerateIvyDescriptor task for each
IvyPublication added (see Section 65.2, “Publications”).
Establishes a rule to automatically create a PublishToIvyRepository task for the
Page 396 of 436

combination of each IvyPublication added (see Section 65.2, “Publications”), witheach IvyArtifactRepository added (see Section 65.3, “Repositories”).

65.2. Publications
If you are not familiar with project artifacts and configurations, you should read 52章
アーティファクトの公開 , which introduces these concepts. This chapter also describes“publishing artifacts” using a different mechanism than what is described in this chapter.
The publishing functionality described here will eventually supersede that functionality.

Publication objects describe the structure/configuration of a publication to be created.
Publications are published to repositories via tasks, and the configuration of the publication
object determines exactly what is published. All of the publications of a project are defined in
the PublishingExtension.getPublications() container. Each publication has a uniquename within the project.
For the “ivy-publish” plugin to have any effect, an IvyPublication must be added to theset of publications. This publication determines which artifacts are actually published as well as
the details included in the associated Ivy module descriptor file. A publication can be configured
by adding components, customizing artifacts, and by modifying the generated module descriptor
file directly.

65.2.1. Publishing a Software Component
The simplest way to publish a Gradle project to an Ivy repository is to specify aSoftwareComponent to publish. The components presently available for publication are:Table 65.1. Software Components
Name

Provided By

Artifacts

Dependencies

javaJava Plugin

Generated jar file

Dependencies from 'runtime' configuration

web

War Plugin

Generated war file

No dependencies

In the following example, artifacts and runtime dependencies are taken from the `java`
component, which is added by the Java Plugin.
Example 65.2. Publishing a Java module to Ivy
build.gradle
publications {ivyJava(IvyPublication) {from components.java}}

Page 397 of 436

65.2.2. Publishing custom artifacts
It is also possible to explicitly configure artifacts to be included in the publication. Artifacts arecommonly supplied as raw files, or as instances of AbstractArchiveTask (e.g. Jar, Zip).
For each custom artifact, it is possible to specify the name, extension, type, classifier and conf
values

to

use

for

publication.

Note

that

each

artifacts

must

have

a

uniquename/classifier/extension combination.
Configure custom artifacts as follows:
Example 65.3. Publishing additional artifact to Ivy
build.gradle
task sourceJar(type: Jar) {from sourceSets.main.javaclassifier "source"}
publishing {publications {ivy(IvyPublication) {from components.java
artifact(sourceJar) {type "source"
conf "runtime"}}}}

See the IvyPublication class in the API documentation for more detailed information on how
artifacts can be customized.

65.2.3. Identity values for the published project
The generated Ivy module descriptor file contains an <info> element that identifies the module.
The default identity values are derived from the following:organisation - Project.getGroup()
module - Project.getName()
revision - Project.getVersion()status - Project.getStatus()branch - (not set)
Overriding the default identity values is easy: simply specify the organisation, module or revisionattributes when configuring the IvyPublication. The status and branch attributes can be
set via the descriptor property (see IvyModuleDescriptorSpec). The descriptor property
can also be used to add additional custom elements as children of the <info> element.

Page 398 of 436

Example 65.4. customizing the publication identity
build.gradle
publishing {publications {ivy(IvyPublication) {organisation 'org.gradle.sample'
module 'project1-sample'
revision '1.1'
descriptor.status = 'milestone'
descriptor.branch = 'testing'descriptor.extraInfo 'http://my.namespace', 'myElement', 'Some value'
from components.java}}}

Gradle will handle any valid Unicode character fororganisation, module and revision (as well as artifact
name, extension and classifier). The only values that are
explicitly prohibited are '\', '/' and any ISO control
character. The supplied values are validated early during
publication.

Certain repositories are notable to handle all supported
characters. For example, the':' character cannot be used
as an identifier whenpublishing to a65.2.4. Modifying the generated
module descriptor

filesystem-backed repository
on Windows.

At times, the module descriptor file generated from the
project information will need to be tweaked before publishing. The “ ivy-publish” pluginprovides a hook to allow such modification.
Example 65.5. Customizing the module descriptor filebuild.gradle
publications {ivyCustom(IvyPublication) {descriptor.withXml {asNode().info[0].appendNode('description','A demonstration of ivy descriptor customization')}}}In this example we are simply adding a 'description' element to the generated Ivy dependency
descriptor, but this hook allows you to modify any aspect of the generated descriptor. For
example, you could replace the version range for a dependency with the actual version used to
produce the build.
See IvyModuleDescriptorSpec.withXml() in the API documentation for more information.
It is possible to modify virtually any aspect of the created descriptor should you need to. This

Page 399 of 436

means that it is also possible to modify the descriptor in such a way that it is no longer a valid Ivy
module descriptor, so care must be taken when using this feature.
The identifier (organisation, module, revision) of the published module is an exception; thesevalues cannot be modified in the descriptor using the `withXML` hook.

65.2.5. Publishing multiple modules
Sometimes it's useful to publish multiple modules from your Gradle build, without creating aseparate Gradle subproject. An example is publishing a separate API and implementation jar foryour library. With Gradle this is simple:
Example 65.6. Publishing multiple modules from a single projectbuild.gradle
task apiJar(type: Jar) {baseName "publishing-api"
from sourceSets.main.output
exclude '**/impl/**'}publishing {publications {impl(IvyPublication) {organisation 'org.gradle.sample.impl'
module 'project2-impl'
revision '2.3'
from components.java}
api(IvyPublication) {organisation 'org.gradle.sample'
module 'project2-api'
revision '2'}}}

If a project defines multiple publications then Gradle will publish each of these to the defined
repositories. Each publication must be given a unique identity as described above.

65.3. Repositories
Publications are published to repositories. The repositories to publish to are defined by the
PublishingExtension.getRepositories() container.

Page 400 of 436

Example 65.7. Declaring repositories to publish tobuild.gradle
repositories {ivy {// change to point to your repo, e.g. http://my.org/repo
url "$buildDir/repo"}}

The DSL used to declare repositories for publishing is the same DSL that is used to declarerepositories for dependencies (RepositoryHandler). However, in the context of Ivy publication
only the repositories created by the ivy() methods can be used as publication destinations.
You cannot publish an IvyPublication to a Maven repository for example.

65.4. Performing a publish
The “ivy-publish” plugin automatically creates a PublishToIvyRepository task for each
IvyPublication and IvyArtifactRepository combination in the publishing.publications
and publishing.repositories containers respectively.
The created task is named “publish« PUBNAME »PublicationTo« REPONAME »Repository”,
which is “publishIvyJavaPublicationToIvyRepository” for this example. This task is oftype PublishToIvyRepository.

Page 401 of 436

Example 65.8. Choosing a particular publication to publish
build.gradle
apply plugin: 'java'
apply plugin: 'ivy-publish'
group = 'org.gradle.sample'
version = '1.0'
publishing {publications {ivyJava(IvyPublication) {from components.java}}
repositories {ivy {// change to point to your repo, e.g. http://my.org/repo
url "$buildDir/repo"}}}

gradle publishIvyJavaPublicationToIvyRepository の出力> gradle publishIvyJavaPublicationToIvyRepository:generateDescriptorFileForIvyJavaPublication:compileJava UP-TO-DATE:processResources UP-TO-DATE:classes UP-TO-DATE:jar:publishIvyJavaPublicationToIvyRepository
BUILD SUCCESSFUL
Total time: 1 secs

65.4.1. The “publish” lifecycle task
The “publish” plugin (that the “ivy-publish” plugin implicitly applies) adds a lifecycle
task that can be used to publish all publications to all applicable repositories named “publish”.
In more concrete terms, executing this task will execute all PublishToIvyRepository tasks inthe project. This is usually the most convenient way to perform a publish.

Page 402 of 436

Example 65.9. Publishing all publications via the “publish” lifecycle task
gradle publish の出力> gradle publish:generateDescriptorFileForIvyJavaPublication:compileJava UP-TO-DATE:processResources UP-TO-DATE:classes UP-TO-DATE:jar:publishIvyJavaPublicationToIvyRepository:publish
BUILD SUCCESSFUL
Total time: 1 secs

65.5. Generating the Ivy module descriptor
file without publishing
At times it is useful to generate the Ivy module descriptor file (normally ivy.xml) without
publishing your module to an Ivy repository. Since descriptor file generation is performed by aseparate task, this is very easy to do.
The “ivy-publish” plugin creates one GenerateIvyDescriptor task for each registered
IvyPublication, named “generateDescriptorFileFor« PUBNAME »Publication”, which
will be “generateDescriptorFileForIvyJavaPublication” for the previous example ofthe “ivyJava” publication.
You can specify where the generated Ivy file will be located by setting the destination
property on the generated task. By default this file is written to “build/publications/« PUBNAME »/ivy.xml”.
Example 65.10. Generating the Ivy module descriptor filebuild.gradle
model {
tasks.generateDescriptorFileForIvyCustomPublication {destination = file("$buildDir/generated-ivy.xml")}}

gradle generateDescriptorFileForIvyCustomPublication の出力> gradle generateDescriptorFileForIvyCustomPublication:generateDescriptorFileForIvyCustomPublication
BUILD SUCCESSFUL
Total time: 1 secs

Page 403 of 436

The “ivy-publish” plugin leverages some experimental support for late plugin
configuration, and the GenerateIvyDescriptor task will not be constructed until the
publishing extension is configured. The simplest way to ensure that the publishing plugin is
configured when you attempt to access the GenerateIvyDescriptor task is to place theaccess inside a model block, as the example above demonstrates.
The same applies to any attempt to access publication-specific tasks like
PublishToIvyRepository. These tasks should be referenced from within a model block.

65.6. Complete example
The following example demonstrates publishing with a multi-project build. Each project
publishes a Java component and a configured additional source artifact. The descriptor file iscustomized to include the project description for each project.

Page 404 of 436

Example 65.11. Publishing a Java modulebuild.gradle
subprojects {apply plugin: 'java'
apply plugin: 'ivy-publish'
version = '1.0'
group = 'org.gradle.sample'
repositories {mavenCentral()}task sourceJar(type: Jar) {from sourceSets.main.javaclassifier "source"}}
project(":project1") {description = "The first project"dependencies {compile 'junit:junit:4.11', project(':project2')}}
project(":project2") {description = "The second project"dependencies {compile 'commons-collections:commons-collections:3.1'}}
subprojects {publishing {repositories {ivy {// change to point to your repo, e.g. http://my.org/repo
url "${rootProject.buildDir}/repo"}}
publications {ivy(IvyPublication) {from components.java
artifact(sourceJar) {type "source"
conf "runtime"}
descriptor.withXml {asNode().info[0].appendNode('description', description)
}
}
}
}
}

The result is that the following artifacts will be published for each project:

Page 405 of 436

The Ivy module descriptor file: “ivy-1.0.xml”.
The primary “jar” artifact for the Java component: “project1-1.0.jar”.
The source “jar” artifact that has been explicitly configured: “project1-1.0-source.jar”.
When project1 is published, the module descriptor (i.e. the ivy.xml file) that is produced will
look like:
Example 65.12. Example generated ivy.xml
output-ivy.xml

Note that «PUBLICATION-TIME-STAMP»
in this example Ivy module<?xml version="1.0" encoding="UTF-8"?>
descriptor will be the<ivy-module version="2.0"><info organisation="org.gradle.sample" module="project1"
revisionof="1.0"
statustimestampwhenthe="integration" p<description>The first project</description>
descriptor was generated.
</info><configurations><conf name="default" visibility="public" extends="runtime"/><conf name="runtime" visibility="public"/></configurations><publications><artifact name="project1" type="jar" ext="jar" conf="runtime"/><artifact name="project1" type="source" ext="jar" conf="runtime" m:classifier="source" xmlns</publications><dependencies><dependency org="junit" name="junit" rev="4.11" conf="runtime-&gt;default"/><dependency org="org.gradle.sample" name="project2" rev="1.0" conf="runtime-&gt;default"/></dependencies></ivy-module>

65.7. Future features
The “ivy-publish” plugin functionality as described above is incomplete, as the feature is
still incubating. In upcoming Gradle releases, the functionality will be expanded to include (butnot limited to):Convenient customization of module attributes (module, organisation etc.)
Convenient customization of dependencies reported in module descriptor.
Multiple discrete publications per project

Page 406 of 436

66
Maven Publishing (new)This chapter describes the new incubating Maven publishing support provided by the “maven-publish” plugin. Eventually this new publishing support will replace publishing via the Uploadtask.
If you are looking for documentation on the original Maven publishing support using the Upload
task please see 52章アーティファクトの公開 .

This chapter describes how to publish build artifacts to an Apache Maven Repository. A module
published to a Maven repository can be consumed by Maven, Gradle (see 51章依存関係の管理 )and other tools that understand the Maven repository format.

66.1. The “maven-publish” Plugin
The ability to publish in the Maven format is provided by the “ maven-publish” plugin.
The “publishing” plugin creates an extension on the project named “ publishing” oftype PublishingExtension. This extension provides a container of named publications and acontainer

of

named

repositories.

The“ maven-publish ”

plugin

works

with

MavenPublication publications and MavenArtifactRepository repositories.
Example 66.1. Applying the 'maven-publish' pluginbuild.gradle
apply plugin: 'maven-publish'

Applying the “maven-publish” plugin does the following:
Applies the “publishing” plugin
Establishes a rule to automatically create a GenerateMavenPom task for each
MavenPublication added (see Section 66.2, “Publications”).
Establishes a rule to automatically create a PublishToMavenRepository task for the
combination of each MavenPublication added (see Section 66.2, “Publications”), witheach MavenArtifactRepository added (see Section 66.3, “Repositories”).
Establishes a rule to automatically create a PublishToMavenLocal task for each

Page 407 of 436

MavenPublication added (seeSection 66.2, “Publications”).

66.2. Publications
If you are not familiar with project artifacts and configurations, you should read the 52章
アーティファクトの公開 that introduces these concepts. This chapter also describes“publishing artifacts” using a different mechanism than what is described in this chapter.
The publishing functionality described here will eventually supersede that functionality.

Publication objects describe the structure/configuration of a publication to be created.
Publications are published to repositories via tasks, and the configuration of the publication
object determines exactly what is published. All of the publications of a project are defined in
the PublishingExtension.getPublications() container. Each publication has a uniquename within the project.
For the “maven-publish” plugin to have any effect, a MavenPublication must be added tothe set of publications. This publication determines which artifacts are actually published as wellas the details included in the associated POM file. A publication can be configured by adding
components, customizing artifacts, and by modifying the generated POM file directly.

66.2.1. Publishing a Software Component
The simplest way to publish a Gradle project to a Maven repository is to specify aSoftwareComponent to publish. The components presently available for publication are:Table 66.1. Software Components
Name

Provided By

Artifacts

Dependencies

java

23章

Generated jar

Dependencies from 'runtime'

Javaプラグイン

file

configuration

26章War

Generated war

No dependencies

プラグイン

file

web

In the following example, artifacts and runtime dependencies are taken from the `java`
component, which is added by the Java Plugin.
Example 66.2. Adding a MavenPublication for a Java component
build.gradle
publishing {publications {mavenJava(MavenPublication) {from components.java}}}

Page 408 of 436

66.2.2. Publishing custom artifacts
It is also possible to explicitly configure artifacts to be included in the publication. Artifacts arecommonly supplied as raw files, or as instances of AbstractArchiveTask (e.g. Jar, Zip).
For each custom artifact, it is possible to specify the extension and classifier values to use
for publication. Note that only one of the published artifacts can have an empty classifier, and allother artifacts must have a unique classifier/extension combination.
Configure custom artifacts as follows:
Example 66.3. Adding additional artifact to a MavenPublicationbuild.gradle
task sourceJar(type: Jar) {from sourceSets.main.allJava}
publishing {publications {mavenJava(MavenPublication) {from components.java
artifact sourceJar {classifier "sources"}}}}

See the MavenPublication class in the API documentation for more information about how
artifacts can be customized.

66.2.3. Identity values in the generated POM
The attributes of the generated POM file will contain identity values derived from the following
project properties:groupId - Project.getGroup()
artifactId - Project.getName()version - Project.getVersion()
Overriding the default identity values is easy: simply specify the groupId, artifactId or version
attributes when configuring the MavenPublication.

Page 409 of 436

Example 66.4. customizing the publication identity
build.gradle
publishing {publications {maven(MavenPublication) {groupId 'org.gradle.sample'
artifactId 'project1-sample'
version '1.1'
from components.java}}}

Maven restricts 'groupId' and 'artifactId' to a limited
character set ([A-Za-z0-9_\\-.]+) and Gradle enforces
this restriction. For 'version' (as well as artifact 'extension'and 'classifier'), Gradle will handle any valid Unicodecharacter.
The only Unicode values that are explicitly prohibited are'\', '/' and any ISO control character. Supplied values arevalidated early in publication.

Certain repositories will not
be able to handle all
supported characters. For
example, the ':' charactercannot be used as an
identifier when publishing toa filesystem-backed
repository on Windows.

66.2.4. Modifying the generated POM
The generated POM file may need to be tweaked before publishing. The “ maven-publish”
plugin provides a hook to allow such modification.
Example 66.5. Modifying the POM filebuild.gradle
publications {mavenCustom(MavenPublication) {pom.withXml {asNode().appendNode('description','A demonstration of maven POM customization')}}}In this example we are adding a 'description' element for the generated POM. With this hook,
you can modify any aspect of the POM. For example, you could replace the version range for adependency with the actual version used to produce the build.
See MavenPom.withXml() in the API documentation for more information.
It is possible to modify virtually any aspect of the created POM should you need to. This meansthat it is also possible to modify the POM in such a way that it is no longer a valid Maven Pom, so
care must be taken when using this feature.

Page 410 of 436

The identifier (groupId, artifactId, version) of the published module is an exception; these values
cannot be modified in the POM using the `withXML` hook.

66.2.5. Publishing multiple modules
Sometimes it's useful to publish multiple modules from your Gradle build, without creating aseparate Gradle subproject. An example is publishing a separate API and implementation jar foryour library. With Gradle this is simple:
Example 66.6. Publishing multiple modules from a single projectbuild.gradle
task apiJar(type: Jar) {baseName "publishing-api"
from sourceSets.main.output
exclude '**/impl/**'}publishing {publications {impl(MavenPublication) {groupId 'org.gradle.sample.impl'
artifactId 'project2-impl'
version '2.3'
from components.java}
api(MavenPublication) {groupId 'org.gradle.sample'
artifactId 'project2-api'
version '2'
artifact apiJar}}}

If a project defines multiple publications then Gradle will publish each of these to the defined
repositories. Each publication must be given a unique identity as described above.

66.3. Repositories
Publications are published to repositories. The repositories to publish to are defined by the
PublishingExtension.getRepositories() container.

Page 411 of 436

Example 66.7. Declaring repositories to publish tobuild.gradle
publishing {repositories {maven {// change to point to your repo, e.g. http://my.org/repo
url "$buildDir/repo"}}}

The DSL used to declare repositories for publication is the same DSL that is used to declarerepositories to consume dependencies from, RepositoryHandler. However, in the context ofMaven publication only MavenArtifactRepository repositories can be used for publication.

66.4. Performing a publish
The “maven-publish” plugin automatically creates a PublishToMavenRepository task foreach MavenPublication and MavenArtifactRepository combination in the publishing.publications
and publishing.repositories containers respectively.
The created task is named “publish« PUBNAME »PublicationTo« REPONAME »Repository”.

Page 412 of 436

Example 66.8. Publishing a project to a Maven repositorybuild.gradle
apply plugin: 'java'
apply plugin: 'maven-publish'
group = 'org.gradle.sample'
version = '1.0'
publishing {publications {mavenJava(MavenPublication) {from components.java}}}
publishing {repositories {maven {// change to point to your repo, e.g. http://my.org/repo
url "$buildDir/repo"}}}

gradle publish の出力> gradle publish:generatePomFileForMavenJavaPublication:compileJava:processResources UP-TO-DATE:classes:jar:publishMavenJavaPublicationToMavenRepository:publish
BUILD SUCCESSFUL
Total time: 1 secs

In this example, a task named “publishMavenJavaPublicationToMavenRepository” iscreated, which is of type PublishToMavenRepository. This task is wired into the publish
lifecycle task. Executing “gradle publish” builds the POM file and all of the artifacts to be
published, and transfers them to the repository.

66.5. Publishing to Maven Local
For integration with a local Maven installation, it is sometimes useful to publish the module into
the local .m2 repository. In Maven parlance, this is referred to as 'installing' the module. The “maven-publish” plugin makes this easy to do by automatically creating a PublishToMavenLocal task foreach MavenPublication in the publishing.publications container. Each of these tasks is
wired into the publishToMavenLocal lifecycle task. You do not need to have `mavenLocal` inyour `publishing.repositories` section.

Page 413 of 436

The created task is named “publish« PUBNAME »PublicationToMavenLocal”.
Example 66.9. Publish a project to the Maven local repository
gradle publishToMavenLocal の出力> gradle publishToMavenLocal:generatePomFileForMavenJavaPublication:compileJava:processResources UP-TO-DATE:classes:jar:publishMavenJavaPublicationToMavenLocal:publishToMavenLocal
BUILD SUCCESSFUL
Total time: 1 secs

The resulting task in this example is named “publishMavenJavaPublicationToMavenLocal”. This task is wired into the publishToMavenLocal lifecycle task. Executing “gradle publishToMavenLoca” builds the POM file and all of the artifacts to be published, and “installs” them into the local
Maven repository.

66.6. Generating the POM file without
publishing
At times it is useful to generate a Maven POM file for a module without actually publishing. Since
POM generation is performed by a separate task, it is very easy to do so.
The task for generating the POM file is of type GenerateMavenPom, and it is given a name basedon the name of the publication: “generatePomFileFor« PUBNAME »Publication”. So in theexample below, where the publication is named “mavenCustom”, the task will be named “generatePomFile”.
Example 66.10. Generate a POM file without publishingbuild.gradle
model {
tasks.generatePomFileForMavenCustomPublication {destination = file("$buildDir/generated-pom.xml")}}

gradle generatePomFileForMavenCustomPublication の出力> gradle generatePomFileForMavenCustomPublication:generatePomFileForMavenCustomPublication
BUILD SUCCESSFUL
Total time: 1 secs

Page 414 of 436

All details of the publishing model are still considered in POM generation, including components`, custom artifacts, and any modifications made via pom.withXml.

The “maven-publish” plugin leverages some experimental support for late plugin
configuration, and any GenerateMavenPom tasks will not be constructed until the
publishing extension is configured. The simplest way to ensure that the publishing plugin is
configured when you attempt to access the GenerateMavenPom task is to place the accessinside a model block, as the example above demonstrates.
The same applies to any attempt to access publication-specific tasks like
PublishToMavenRepository. These tasks should be referenced from within a model
block.

Page 415 of 436

A
Gradleサンプル集

Gradleの配布物には、スタンドアローンで動作するサンプルが含まれています。以下にその一覧を掲載しました。これ
GRADLE_HOME /samples ディレクトリに入っています。
表A.1 配布物に入っているサンプル
サンプル

説明

announce

アナウンスプラグインを使うプロジェクト

application

アプリケーションプラグインを使うプロジェクト

buildDashboard

A project which uses the build-dashboard plugin

codeQuality

A project which uses the various code quality plugins.

customBuildLanguage

ビルドDSLへカスタム要素を追加するデモです。カスタムプラグイン

customDistribution

Gradleのカスタムディストリビューションを作る方法、およびそのデ

customPlugin

カスタムプラグインやカスタムタスクの実装、テスト、公開および使

ear/earCustomized/ear

中身をカスタマイズしたWebアプリケーションearプロジェクト

ear/earWithWar

Webアプリケーションearプロジェクト

groovy/customizedLayout

ソースコードのレイアウトをカスタマイズしたGroovyプロジェクト

groovy/mixedJavaAndGroovy

JavaとGroovyのソースが混ざって含まれているプロジェクト

groovy/multiproject

複数のGroovyプロジェクトで構成されたビルド。特定のソースファイ

groovy/quickstart

Groovyクイックスタートサンプル

java/base

基本的なJavaプロジェクト

java/customizedLayout

ソースコードのレイアウトをカスタマイズしたJavaプロジェクト

Page 416 of 436

java/multiproject

複数のJavaプロジェクトを使ってアプリケーションを組み立てるデモ

java/quickstart

Javaクイックスタートプロジェクト

java/withIntegrationTests

ソースセットを使って、Javaプロジェクトに結合テスト・スイートを

javaGradlePlugin

This example demonstrates the use of the java gradle plugin devel
the plugin metadata during jar execution.

maven/pomGeneration

Mavenリポジトリにデプロイ、インストールするデモ。メインのJARにmaven/quickstart

Mavenリポジトリにアーティファクトをデプロイ、インストールする

osgi

OSGiバンドルをビルドするプロジェクト

scala/customizedLayout

ソースコードのレイアウトをカスタマイズしたScalaプロジェクト

scala/fsc

Fast Scala Compiler (fsc)を使ったScalaプロジェクト

scala/mixedJavaAndScala

ScalaとJavaのソースが混ざって含まれているプロジェクト

scala/quickstart

Scalaクイックスタートプロジェクト

scala/zinc

Scala project using the Zinc based Scala compiler.

testing/testReport

Generates an HTML test report that includes the test results from a

toolingApi/customModel

A sample of how a plugin can expose its own custom tooling mode

toolingApi/eclipse

Tooling APIを使ってEclipseのプロジェクトモデルを構築するアプリケ

toolingApi/idea

IntellJ IDEAで必要な情報を、Tooling APIを使って抽出するアプリケー

toolingApi/model

An application that uses the tooling API to build the model for a Gr

toolingApi/runBuild

An application that uses the tooling API to run a Gradle task.

userguide/distribution

A project which uses the distribution plugin

userguide/javaLibraryDistribution

A project which uses the Java library distribution plugin

webApplication/customized

中身をカスタマイズしたWARをビルドするWebアプリケーションプロ

Page 417 of 436

webApplication/quickstart

Webアプリケーション クイックスタートプロジェクト

A.1. サンプル customBuildLanguage

ビルドDSLへカスタム要素を追加するデモです。カスタムプラグインを使ってビルドロジックを体系化するデモでもあり

このビルドは、二種類のプロジェクトから構成されています。「製品」プロジェクトと「製品モジュール」プロジェクト「製品」は複数の「製品モジュール」から構成されており、ひとつの「製品モジュール」は複数のプロジェクトに含まれつまり、「製品モジュール」とプロジェクトが、多対多の関係になっているのです。

各「製品」は、「製品モジュール」の実行時クラスパスを固めたZIPファイルを作成します。さらに、ZIPファイルには「製品」プロジェクトのビルドスクリプト（basicEdition/build.gradleなど）では、独自のカスタム要素が使用されています。ビルドスクリプトで、product{}という要素が使われていることに注目してください。これがカスタム要素です。

プロジェクトのビルドスクリプトには、要素の宣言しか含まれていません。処理の大半はbuildSrc/src/main/grooにある二つのカスタムプラグインで記述されています。

A.2. サンプル customDistribution

Gradleのカスタムディストリビューションを作る方法、およびそのディストリビューションをGradleラッパーで使う方
このサンプルには次のプロジェクトが含まれています。
p

l

u

g

i

n

ディレクトリに入っているプロジェクトで、カスタムプラグインを実装してディストリビューションにバンドルしてconsumer
ディレクトリに入っているプロジェクトで、そのカスタムディストリビューションを使用しています。

A.3. サンプル customPlugin
カスタムプラグインやカスタムタスクの実装、テスト、公開および使用方法を示す、いくつかのサンプルプロジェクト
このサンプルには、以下のプロジェクトが含まれています。
pluginディレクトリのプロジェクトで、プラグインを実装して公開しています。
consumerディレクトリのプロジェクトで、そのプラグインを使用しています。

A.4. サンプル java/multiproject
複数のJavaプロジェクトを使ってアプリケーションを組み立てるデモ

Page 418 of 436

このビルドはクライアント・サーバー型のアプリケーションを作成するもので、配布物になるのは二つのアーカイブですサードパーティ製のアプリケーションをコンパイルするためのAPIを含むJARとクライアントのランタイムが入ったZIPフ
そして、Webサービスを提供するサーバーWARファイルを作成します。

Page 419 of 436

B
陥りがちな罠
B.1. Groovyスクリプトの変数
Gradleユーザーにとって、Groovyがスクリプトの変数をどう扱うか理解しておくことは大事なことです。

Groovyには、二種類のスクリプト変数があります。一つがローカルスコープのもので、もう一つがスクリプトスコープ

Page 420 of 436

例B.1 変数のスコープ：ローカルスコープとスクリプトスコープ
scope.groovy
String localScope1 = 'localScope1'
def localScope2 = 'localScope2'
scriptScope = 'scriptScope'
println localScope1
println localScope2
println scriptScope
closure = {println localScope1
println localScope2
println scriptScope}def method() {try {localScope1} catch (MissingPropertyException e) {println 'localScope1NotAvailable'}
try {
localScope2} catch(MissingPropertyException e) {println 'localScope2NotAvailable'}
println scriptScope}
closure.call()method()gradle の出力> gradle
localScope1
localScope2
scriptScope
localScope1
localScope2
scriptScope
localScope1NotAvailable
localScope2NotAvailable
scriptScope型修飾のついた変数は、クロージャ内からは見えていますが、メソッドからは見えていません。これは、Groovyコミュ[44]

B.2. 設定フェーズと実行フェーズ
Gradleが設定フェーズと実行フェーズを区別していることは常に頭に入れておきましょう。とても重要なことです。(
56章ビルドのライフサイクル参照)

Page 421 of 436

例B.2 設定フェーズと実行フェーズの区別
build.gradle
def classesDir = file('build/classes')classesDir.mkdirs()
task clean(type: Delete) {delete 'build'}task compile(dependsOn: 'clean') << {if (!classesDir.isDirectory()) {println 'The class directory does not exist. I can not operate'// do something}// do something}

gradle -q compile の出力> gradle -q compile
The class directory does not exist. I can not operate

ディレクトリの作成は設定フェーズで起こっていて、実行フェーズでclean
タスクがそのディレクトリを削除してしまっています。

[44]

これらの議論のうちの一つを、ここで見ることができます。

http://groovy.329449.n5.nabble.com/script-scoping-question-td355887.html

Page 422 of 436

C
機能のライフサイクル

Gradleプロジェクトは現在も活発に開発、改善されており、新しいバージョンが定期的に、また頻繁にリリースされて新しい機能および修正を頻繁にリリースすることで、それらの新機能が素早くユーザーにより確認され、実際の現場で得

それと同時に、APIや機能の安定性もとても重要であり、これもGradleプラットフォームの大事な価値の一つだと考えて新機能は、設計上の選択により開発プロセスに組み入れられ、自動テストされ、「後方互換性ポリシー」に従って正式採用されるようになっています。
Gradleの機能ライフサイクルは、これらの目的を達成するために設計されました。

また、機能ライフサイクルは、ある機能が今どんなステータスにあるのか、ユーザーに明確に伝えることにも寄与します
機能という用語は、たいていの場合APIやDSLのメソッドやプロパティを指しますが、それだけにとどまりません。
コマンドライン引数や実行モード(例えばBuild Deamon)などもその一つです。

C.1. 状態
機能の状態は、以下の四つのうちいずれかとなります。
非公開
試験的
公開
非推奨

C.1.1. 非公開

非公開の機能は、広く使われることは想定しておらず、Gradleが内部的に使うためのものです。これらの機能は、いつ
従って、これらの機能を使うことは推奨しません。

また、非公開機能はドキュメント化もされません。もしユーザーガイドやDSLリファレンス、APIリファレンスに載って非公開機能は、公開機能に昇格する可能性があります。

C.1.2. 試験的
試

験

的

な

状態にあると書かれた機能は、正式に公開される前に、実際の運用で発生したフィードバックを受け付けている状態のも

これらの機能は、機能が変更されるリスクを受け入れられるユーザーに向けて公開されているもので、そういったユーザ

試験的な機能は、試験的でなくなるまでは将来のバージョンのGradleで変更されるかもしれません。変更された場合は新機能の試験期間は、その範囲や複雑性、機能の性質によって様々です。

試験的な機能は、試験的であるとはっきり明示されます。ソースコードでは全ての試験的なメソッド、プロパティ、クラPage 423 of 436

I n c u b a t i n g

アノテーションで注釈されます。これはDSLリファレンスやAPIリファレンスにマークする際も使用されます。試験的機

C.1.3. 公開
非公開でない機能のデフォルトのステータスが 公開 です。

ユーザーガイド、DSLリファレンス、APIリファレンスにおける全ての記載内容は、明示的に試験的とか非推奨などと書機能は、試験的な状態から公開機能へと言わば 昇格します。試験的だった機能が公開状態に昇格した場合は、そのバージョンのリリースノートで通知します。
公開状態の機能は、非推奨とならない限り 決して
削除されたり意図的に変更されたりすることはありません。
全ての公開機能は上位互換性ポリシーの対象となります。

C.1.4. 非推奨
Gradleの発展に伴って、いくつかの機能は別のものに取って代わられたり、不適切になったりすることがあります。
そのような機能は、 非推奨 とされた後、やがてはGradleから削除されます。
非推奨の機能は、上位互換性ポリシーに従い、削除されるまで決して変更されることはありません。

非推奨の機能は、非推奨であるとはっきり明示されます。ソースコードでは全ての非推奨メソッド、プロパティ、クラス@java.lang.Deprecatedアノテーションで注釈されます。これはDSLリファレンスやAPIリファレンスにも反映されます。ほとんどの場合、非推

非推奨機能の使用は避けるべきです。リリースノートには、そのリリースで非推奨となった機能が全て記載されていますC.2. 後方互換性ポリシー
Gradleはメジャーバージョン間( 1.x 、 2.x など)で上位互換性を保持します。
一度Gradleのリリースに導入されたり昇格したりした公開機能は、非推奨にならない限り決して変更されません。
機能がいったん非推奨になると、次からのメジャーリリースでは削除される可能性があります。
非推奨機能がメジャーバージョンをまたいでサポートされる場合もありますが、必ずそうとは限りません。

Page 424 of 436

D
Gradle コマンドライン
The gradle コマンドには次の使用方法があります:
gradle [option...] [task...]コマンドライン・オプションは下記のgradleコマンドリストに示されている物が利用可能です。
-?, -h, --help
ヘルプのメッセージを参照-a, --no-rebuild
プロジェクトの依存関係をリビルドしません。
--all
タスク実行時の応答の詳細状況を表示をします。 「タスクの一覧」を参照。
-b, --build-file
ビルド対象のgradleファイルを指定します。「ビルドスクリプトを指定して実行する」参照。
-c, --settings-file
設定ファイルを指定します。
--continue
タスクを失敗しても、実行処理を継続します。
--configure-on-demand (incubating)
Only relevant projects are configured in this build run. This means faster builds for large
multi-projects. See 「Configuration on demand」.
-D, --system-prop
JVMの環境変数を設定します,

例えば-Dmyprop=myvalue。

「Gradleプロパティとシステムプロパティ」を参照。
-d, --debug
デバックモードのログ出力(スタックトレースを含みます)。18章ロギング参照。
-g, --gradle-user-homeGradleのユーザディレクトリを指定します。デフォルトはユーザディレクトリ配下の.gradleになります。
--gui
Gradle GUIを起動します。12章GradleのGUIを使う参照。
Page 425 of 436

-I, --init-script
初期化スクリプトを指定します。61章初期化スクリプト参照。
-i, --info
ログレベルをinfoに指定します。18章ロギング参照。
-m, --dry-run
タスクを実行しない形でビルドを走らせます。「空実行」参照。
--no-color
コンソールの出力をカラフルにしない指定。
--offline
ネットワークにアクセスしない形でビルドを実行する指定です。
「キャッシングに関するコマンドラインオプション 」参照。
-P, --project-prop
ルートプロジェクトに、プロジェクトプロパティを設定します。例えば-Pmyprop=myvalue。

「Gradleプロパティとシステムプロパティ」参照。
-p, --project-dir
Gradleの実行ディレクトリを指定します。デフォルトはカレントディレクトリです。
「ビルドスクリプトを指定して実行する」参照。
--parallel (incubating)
Build projects in parallel. Gradle will attempt to determine the optimal number of executor
threads to use. This option should only be used with decoupled projects (see
「分離されたプロジェクト 」).
--parallel-threads (incubating)

Build projects in parallel, using the specified number of executor threads. For example--parallel-threads=. This option should only be used with decoupled projects (see 「分離されたプロジェクト 」).
--profileProfilesコマンドはビルド実行時に buildDir /reports/profile
ディレクトリにタスクの実行時間をレポート出力します。 「ビルドのプロファイリング」参照。
--project-cache-dir
プロジェクトのキャッシュディレクトリを指定します。

デフォルトは.gradle

ディレクトリ上のルートプロジェクトディレクトリになります。 「キャッシング 」参照。
-q, --quiet
ログ出力をエラーのみにします。18章ロギング参照。
--recompile-scripts
ビルドキャッシュファイルを無視してリコンパイルを強制する指定です。 「キャッシング 」参照。
--refresh-dependencies
依存状態をリフレッシュします。 「キャッシングに関するコマンドラインオプション 」参照。

Page 426 of 436

--rerun-tasks
タスク最適化を無視する指定です。
-S, --full-stacktrace
例外発生時にフルスタックトレースを出力します。18章ロギング参照。
-s, --stacktrace
ユーザ例外のスタックトレースを出力します。(例えばコンパイルエラー) 18章ロギング参照。
-u, --no-search-upwards
親ディレクトリの settings.gradle ファイルを探しません。
-v, --version
バージョン情報を表示します。
-x, --exclude-task
除外タスクを指定します。「タスクを除外してビルドする」参照。
gradle -hコマンドを実行するとき上記の情報は表示されます。

D.1. デーモン コマンドラインオプション:
19章Gradleデーモン のリンクはデーモンに関しての情報を多く含みます。 例えば、デフォルトで--daemon
指定をつける方法等--daemonGradle デーモンの状態でビルドを実行します。 既存のデーモンが未実行 または 忙しければ 19章
Gradleデーモン 新しいデーモンプロセスを実行します。
--foreground
G

r

a

d

l

e

daemonをフォアグラウンドの状態で実行します。容易にビルド時の例外をモニターできるので、デバックやトラブルシューティングに役立ちます。
--no-daemon
対象のビルドを実行させる為にGradleデーモンを使いません。
デーモンモードで実行することをデフォルトにしていれば、時々有用です。
--stopGradleデーモンが実行されていれば停止します。

実行しているバージョンのGradleの--stop

で停止させてください。

D.2. システムプロパティ
システムプロパティの設定には以下の gradle コマンドが利用可能です。
ただしコマンドラインオプションのシステムプロパティの指定が優先されることに注意

Page 427 of 436

gradle.user.home
Gradleユーザディレクトリの指定「gradle.propertiesを使用したビルド環境の構築」にGradleの設定で利用可能なシステムプロパティの情報が記載されています。

D.3. 環境変数
環境変数の設定には以下のgradleコマンドが利用可能です。
ただしコマンドラインオプションの環境変数の指定が優先されることに注意
GRADLE_OPTS
JVMを始めるために使用するコマンドライン引数を指定します。

Gradleの実行のために使用させるのに役立つことができます。例えば GRADLE_OPTS="-Dorg.gradle.daemon=tの指定は--daemon をコマンドラインで指定する事無く実行させることが出来ます。

「gradle.propertiesを使用したビルド環境の構築」に
環境変数を使う事無しに、デーモンモードでの設定をする情報が記載されています。
例えばより維持可能でより明示的な方法で。
GRADLE_USER_HOME
Gradleのユーザディレクトリを指定します
JAVA_HOME
Specifies the JDK installation directory to use.

Page 428 of 436

E
IDE対応の現状と、IDEによらない開発支援
E.1. IntelliJ
Gradleは主にIdea

IntelliJとそのすばらしいGroovyプラグインを利用して開発されています。

Gradleのビルドスクリプト[46 ]の開発にも、このIDEのサポートを利用することができます。

IntelliJは任意のファイルパターンをGroovyスクリプトとして解釈することができます。
Gradleの場合はbuild.gradleやsettings.gradleのようなパターンを定義できます。
こ れ は 非 常 に 役 に 立 ち ま す 。

Gradleクラスに対するコンテンツアシストを提示するためのGradleバイナリに対するクラスパスの設定は行われません
プロジェクトのクラスパスに、GradleのJAR(配布物に含まれています)を追加するとよいでしょう。

実際にはそこにあるべきものではないのですが、これを行うことでGradleスクリプトの開発に対するIDEのすばらしいサ

もちろん、ビルドスクリプトのための追加のライブラリを使うならば、それはプロジェクトのクラスパスを汚染すること
われわれは、将来においてIntelliJが *.gradle ファイルを特別に扱い、それらに特化したクラスパスの定義が可能になることを希望しています。

E.2. Eclipse
EclipseにはGroovyプラグインがあります。
我々はその現状や、Gradleをどうサポートできるのかを把握していません。
ユーザーガイドの次の版ではもう少し詳しい記述を追加したいと思っています。

E.3. IDEサポートなしでGradleを使う
我々にできるのは、

throw

new

のような記述のタイプ量を節約して

org.gradle.api.tasks.StopExecutionException()
代わりにthrownew

StopExecutionException()とだけタイプすればよいようにすることです。
Gradleスクリプトの実行前に一連のimport文を自動的に追加することでこれを実現しています。
以下はスクリプトに追加されるimportの一覧です。
図E.1 Gradleがimportするパッケージ
import org.gradle.*
import org.gradle.api.*
import org.gradle.api.artifacts.*
import org.gradle.api.artifacts.cache.*import org.gradle.api.artifacts.component.*
import org.gradle.api.artifacts.dsl.*
import org.gradle.api.artifacts.ivy.*
import org.gradle.api.artifacts.maven.*

Page 429 of 436

import org.gradle.api.artifacts.query.*
import org.gradle.api.artifacts.repositories.*
import org.gradle.api.artifacts.result.*
import org.gradle.api.component.*
import org.gradle.api.distribution.*
import org.gradle.api.distribution.plugins.*
import org.gradle.api.dsl.*
import org.gradle.api.execution.*
import org.gradle.api.file.*
import org.gradle.api.initialization.*
import org.gradle.api.initialization.dsl.*
import org.gradle.api.invocation.*
import org.gradle.api.java.archives.*
import org.gradle.api.jvm.*
import org.gradle.api.logging.*
import org.gradle.api.platform.jvm.*
import org.gradle.api.plugins.*
import org.gradle.api.plugins.announce.*
import org.gradle.api.plugins.antlr.*
import org.gradle.api.plugins.buildcomparison.gradle.*
import org.gradle.api.plugins.jetty.*
import org.gradle.api.plugins.osgi.*
import org.gradle.api.plugins.quality.*
import org.gradle.api.plugins.scala.*
import org.gradle.api.plugins.sonar.*
import org.gradle.api.plugins.sonar.model.*import org.gradle.api.publish.*import org.gradle.api.publish.ivy.*
import org.gradle.api.publish.ivy.plugins.*
import org.gradle.api.publish.ivy.tasks.*
import org.gradle.api.publish.maven.*
import org.gradle.api.publish.maven.plugins.*
import org.gradle.api.publish.maven.tasks.*
import org.gradle.api.publish.plugins.*
import org.gradle.api.reporting.*
import org.gradle.api.reporting.components.*
import org.gradle.api.reporting.dependencies.*
import org.gradle.api.reporting.plugins.*
import org.gradle.api.resources.*
import org.gradle.api.specs.*
import org.gradle.api.tasks.*
import org.gradle.api.tasks.ant.*
import org.gradle.api.tasks.application.*
import org.gradle.api.tasks.bundling.*
import org.gradle.api.tasks.compile.*
import org.gradle.api.tasks.diagnostics.*
import org.gradle.api.tasks.incremental.*
import org.gradle.api.tasks.javadoc.*
import org.gradle.api.tasks.scala.*
import org.gradle.api.tasks.testing.*
import org.gradle.api.tasks.testing.junit.*
import org.gradle.api.tasks.testing.testng.*
import org.gradle.api.tasks.util.*import org.gradle.api.tasks.wrapper.*import org.gradle.buildinit.plugins.*
import org.gradle.buildinit.tasks.*
import org.gradle.external.javadoc.*
import org.gradle.ide.cdt.*
import org.gradle.ide.cdt.tasks.*
import org.gradle.ide.visualstudio.*import org.gradle.ide.visualstudio.plugins.*

Page 430 of 436

import org.gradle.ide.visualstudio.tasks.*
import org.gradle.jvm.*
import org.gradle.jvm.plugins.*
import org.gradle.jvm.toolchain.*import org.gradle.language.*
import org.gradle.language.assembler.*import org.gradle.language.assembler.plugins.*
import org.gradle.language.assembler.tasks.*
import org.gradle.language.base.*
import org.gradle.language.base.artifact.*
import org.gradle.language.base.plugins.*
import org.gradle.language.c.*import org.gradle.language.c.plugins.*
import org.gradle.language.c.tasks.*
import org.gradle.language.cpp.*
import org.gradle.language.cpp.plugins.*
import org.gradle.language.cpp.tasks.*
import org.gradle.language.java.*
import org.gradle.language.java.artifact.*
import org.gradle.language.java.plugins.*
import org.gradle.language.jvm.*
import org.gradle.language.jvm.plugins.*
import org.gradle.language.jvm.tasks.*
import org.gradle.language.nativebase.tasks.*
import org.gradle.language.objectivec.*
import org.gradle.language.objectivec.plugins.*
import org.gradle.language.objectivec.tasks.*
import org.gradle.language.objectivecpp.*
import org.gradle.language.objectivecpp.plugins.*
import org.gradle.language.objectivecpp.tasks.*
import org.gradle.language.rc.*
import org.gradle.language.rc.plugins.*
import org.gradle.language.rc.tasks.*
import org.gradle.nativeplatform.*
import org.gradle.nativeplatform.platform.*
import org.gradle.nativeplatform.plugins.*
import org.gradle.nativeplatform.sourceset.*import org.gradle.nativeplatform.tasks.*
import org.gradle.nativeplatform.test.*
import org.gradle.nativeplatform.test.cunit.*
import org.gradle.nativeplatform.test.cunit.plugins.*
import org.gradle.nativeplatform.test.cunit.tasks.*
import org.gradle.nativeplatform.test.plugins.*
import org.gradle.nativeplatform.test.tasks.*
import org.gradle.nativeplatform.toolchain.*import org.gradle.nativeplatform.toolchain.plugins.*
import org.gradle.platform.base.*
import org.gradle.platform.base.binary.*
import org.gradle.platform.base.component.*
import org.gradle.platform.base.test.*
import org.gradle.plugin.use.*
import org.gradle.plugins.ear.*
import org.gradle.plugins.ear.descriptor.*
import org.gradle.plugins.ide.api.*
import org.gradle.plugins.ide.eclipse.*
import org.gradle.plugins.ide.idea.*
import org.gradle.plugins.javascript.base.*
import org.gradle.plugins.javascript.coffeescript.*
import org.gradle.plugins.javascript.envjs.*
import org.gradle.plugins.javascript.envjs.browser.*import org.gradle.plugins.javascript.envjs.http.*

Page 431 of 436

import org.gradle.plugins.javascript.envjs.http.simple.*
import org.gradle.plugins.javascript.jshint.*
import org.gradle.plugins.javascript.rhino.*
import org.gradle.plugins.javascript.rhino.worker.*
import org.gradle.plugins.signing.*
import org.gradle.plugins.signing.signatory.*
import org.gradle.plugins.signing.signatory.pgp.*
import org.gradle.plugins.signing.type.*
import org.gradle.plugins.signing.type.pgp.*
import org.gradle.process.*
import org.gradle.sonar.runner.*import org.gradle.sonar.runner.plugins.*
import org.gradle.sonar.runner.tasks.*

Page 432 of 436

import org.gradle.testing.jacoco.plugins.*
import org.gradle.testing.jacoco.tasks.*
import org.gradle.util.*[46] GradleはGradleでビルドされている

Page 433 of 436

Gradle User GuideA
アーティファクト / Artifact??

B
ビルドスクリプト / Build Script??

C
コンフィグレーション / Configuration
See 依存関係の構成 / Dependency Configuration.
コンフィグレーション注入 / Configuration Injection
??

D
DAG
See 無閉路有向グラフ / Directed Acyclic Graph.
依存関係 / Dependency
See 外部依存関係 / External Dependency.
See プロジェクト依存関係 / Project Dependency.
??
依存関係の構成 / Dependency Configuration??
依存関係の解決 / Dependency Resolution??
無閉路有向グラフ / Directed Acyclic Graph
無閉路有向グラフとは循環を持たない有向グラフである。
Gradleでは実行対象となる各タスクはグラフ内のノードとして表現される。

他のタスクに対するdependsOnによる関連は、(既にグラフに存在していなければ)このタスクをノードとして追加しそれら2つのノード間に方向性を伴った辺を作成する。
あらゆるdependsOn関連は循環を持たないことが検証される。
あるノードから開始して、辺を順にたどり、元のノードにたどり着く道があってはならない。

ドメイン特化言語 / Domain Specific Language
ドメイン特化言語とは、特定の問題領域や特定の問題表現技法と解決技法に特化したプログラム言語ないしは言語に対する仕様である。

その概念は新しいものではなく、特定用途のプログラム言語や、あらゆる種類のモデリング・仕様記述言語は常に存在する。
しかし、ドメイン特化モデリングの興隆によって、この用語は有名になりつつある。
DSL
See ドメイン特化言語 / Domain Specific Language.

E
外部依存関係 / External Dependency??
拡張オブジェクト / Extension Object??

I
初期スクリプト / Init Script
ビルド自体が開始する前に実行されるスクリプト。Gradleおよびビルドそのものをカスタマイズすることが可能。
初期化スクリプト / Initialization Script
See 初期スクリプト / Init Script.

P
プラグイン / Plugin??
プロジェクト / Project??
プロジェクト依存関係 / Project Dependency??
発行 / Publication??

R
リポジトリ / Repository??

S
ソースセット / Source Set??

Tタスク / Task??
推移的依存関係 / Transitive Dependency??