build.gradle は maven でいう pom.xml みたいなファイルでビルドの設定が Groovy という言語で内部DSLっぽく書かれている

基本的に Java のプロジェクトをビルドするという前提で書いている。

build.gradle で作れるような機能を固めて別出ししたものを読み込む記述。

build.gradle を書くということは各有名所プラグインの使い方を覚えることと等しい。

apply plugin: 'java'
apply plugin: 'eclipse'

このようになんのことわりもなしにさらりと記述されているのは Gradle の標準プラグインである。

第22章 標準Gradleプラグイン

ライブラリ等をどこのリポジトリから持ってくるかという話。

repositories {
    mavenCentral()
}

こう書くことが多く、これは maven の標準リポジトリということである。 ほぼこれで問題ない。

これは maven の dependencies と同様でそのソースに必要なライブラリ

それがいつ必要になるのかと合わせて記述することで選択的にダウンロード、クラスパスのセットを行ってくれる。

implementation はこのビルドするプロジェクトが直接的に関係する依存性のみ解決するという挙動になる。

dependencies {
    implementation('a.b.c:hoge-piyo-fuga')
}

ライブラリは依存性が複雑であるが、最終的には1つのツリーとして表現される。 なので、自分は明示してないのだが、自分が使っているライブラリを読み込んでくれているという状況はありうる。 ということで実際には依存してるのだが依存関係を書かずとも使えるという状況になる。 このような読み込み方は以前は compile と記述していたらしく、古めの Gradle の記事ではちらほら出てくる。

implementation はそのようなビルドパスの構築をしませんよという書き方になる。 なので、依存するものは明示的に書けよということである。

逆に言うと依存される側はすべて内部で閉じるか、外部に対してその機能のインターフェースを提供しろという設計になる。

以前の compile と呼ばれていた記述は現在 api と呼ばれている。

dependencies {
    api('a.b.c:hoge-piyo-fuga')
}

これで依存先の依存先をプロジェクトで使うことができる。 これは依存先をちょっと使うみたいなことではなくて、依存先の環境を含めでなにかやらないといけないようなライブラリを読み込む場合に記述することになるだろう。ということでなまえが api ということになっているのだろう。

オプションで指定する

--build-file