第7章 Javaクイックスタート

The Java plugin adds quite a few tasks to your project. However, there are only a handful of tasks that you will need to use to build the project. The most commonly used task is the build task, which does a full build of the project. When you run gradle build, Gradle will compile and test your code, and create a JAR file containing your main classes and resources:

Javaプラグインはかなり多くのタスクをプロジェクトに追加します。しかし、プロジェクトをビルドするのに必要なタスクはほんの一握りです。最もよく使われるのはプロジェクトのフルビルドを行うbuildタスクです。gradle buildを実行すると、Gradleはコードをコンパイルしてテストし、メインクラスやリソースを含んだJARファイルを生成します：

> gradle build
:compileJava
:processResources
:classes
:jar
:assemble
:compileTestJava
:processTestResources
:testClasses
:test
:check
:build

BUILD SUCCESSFUL

Total time: 1 secs

Some other useful tasks are:

他にも便利なタスクがあります：

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 the public Maven repository:

Javaプロジェクトは外部のJARファイルに依存することが普通です。プロジェクトで使うこういったJARファイルを参照するため、Gradleにそれらの場所を伝える必要があります。Gradleでは、JARファイルのようなアーティファクトはリポジトリに置かれます。リポジトリは、プロジェクトが依存するものを取得したり、プロジェクトのアーティファクトを公開したり、あるいはその両方のために利用することができます。この例では、公開Mavenリポジトリを使います：

repositories {
    mavenCentral()
}

Let's add some dependencies. Here, we will declare that our production classes have a compile-time dependency on commons collections, and that our test classes have a compile-time dependency on junit:

依存関係をいくつか追加してみましょう。製品クラスはコンパイル時にcommonsコレクションに依存し、テストクラスはコンパイル時にjunitに依存することを宣言します：

dependencies {
    compile group: 'commons-collections', name: 'commons-collections', version: '3.2'
    testCompile group: 'junit', name: 'junit', version: '4.+'
}

You can find out more in 8章依存関係管理の基本 .

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

The Java plugin adds a number of properties to your project. These properties have default values which are usually sufficient to get started. It's easy to change these values if they don't suit. Let's look at this for our sample. Here we will specify the version number for our Java project, along with the Java version our source is written in. We also add some attributes to the JAR manifest.

Javaプラグインは多くのプロパティをプロジェクトに追加します。こういったプロパティには普通、十分適切なデフォルト値が設定されています。不適切な場合、これらの値を変更するのは簡単です。では、実例を見てみましょう。ここでは、ソースの書かれたJavaバージョンとともに、Javaプロジェクトのバージョン番号を指定しています。また、JAR manifestにいくつか属性を追加しています。

sourceCompatibility = 1.5
version = '1.0'
jar {
    manifest {
        attributes 'Implementation-Title': 'Gradle Quickstart',
                   'Implementation-Version': version
    }
}

The tasks which the Java plugin adds are regular tasks, exactly the same as if they were declared in the build file. This means you can use any of the mechanisms shown in earlier chapters to customize these tasks. For example, you can set the properties of a task, add behaviour to a task, change the dependencies of a task, or replace a task entirely. In our sample, we will configure the test task, which is of type Test, to add a system property when the tests are executed:

Javaプラグインが追加するタスクはごく普通のタスクで、ビルドファイルで宣言されるものとまったく同等のものです。つまり、これらのタスクは、ここまでの章で説明したあらゆるメカニズムを使ってカスタマイズすることが可能だということです。例えば、タスクのプロパティを設定したり、タスクに振る舞いを追加したり、タスクの依存関係を変更したり、あるはタスク全体を完全に置き換えることすら可能です。以下の例では、Test型であるtestタスクを設定して、テスト実行時のシステムプロパティを追加しています：

test {
    systemProperties 'property': 'value'
}

Usually the JAR file needs to be published somewhere. To do this, you need to tell Gradle where to publish the JAR file. In Gradle, artifacts such as JAR files are published to repositories. In our sample, we will publish to a local directory. You can also publish to a remote location, or multiple locations.

通常は、JARファイルをどこかに公開する必要があるでしょう。このため、GradleにJARファイルの公開先を教える必要があります。Gradleでは、JARファイルのようなアーティファクトはリポジトリに置かれます。以下の例ではローカルディレクトリに公開します。リモートな場所や、複数の場所に公開することも可能です。

uploadArchives {
    repositories {
       flatDir {
           dirs 'repos'
       }
    }
}

To publish the JAR file, run gradle uploadArchives.

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

To create the Eclipse-specific descriptor files, like .project, you need to add another plugin to your build file:

.projectのようなEclipse固有の設定ファイルを生成するには、別のプラグインをビルドファイルに追加する必要があります：

apply plugin: 'eclipse'

Now execute gradle eclipse command to generate Eclipse project files. More information about the eclipse task can be found in 38章Eclipse プラグイン.

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

Here's the complete build file for our sample:

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

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'
       }
    }
}

To define a multi-project build, you need to create a settings file. The settings file lives in the root directory of the source tree, and specifies which projects to include in the build. It must be called settings.gradle. For this example, we are using a simple hierarchical layout. Here is the corresponding settings file:

マルチプロジェクトのビルドを定義するためには、settingsファイルを作成する必要があります。settingsファイルはソースツリーのルートディレクトリに置かれ、このビルドにどのプロジェクトが含まれるかを指定します。名前はsettings.gradleでなければなりません。この例では、シンプルな階層レイアウトを使っています。対応するsettingsファイルは以下のようになります：

include "shared", "api", "services:webservice", "services:shared"

You can find out more about the settings file in 57章マルチプロジェクトのビルド.

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

For most multi-project builds, there is some configuration which is common to all projects. In our sample, we will define this common configuration in the root project, using a technique called configuration injection. Here, the root project is like a container and the subprojects method iterates over the elements of this container - the projects in this instance - and injects the specified configuration. This way we can easily define the manifest content for all archives, and some common dependencies:

大抵のマルチプロジェクトビルドでは、すべてのプロジェクトに共通な設定があります。この例では、設定のインジェクションと呼ばれる技法を使い、こういった共通設定をルートプロジェクトで定義します。ここでは、ルートプロジェクトはコンテナのようなもので、subprojectsメソッドはコンテナの全要素、すなわちこの実例の中の全プロジェクト、に対して反復しつつ指定された設定をインジェクトします。このようにして、全アーカイブのmanifestコンテンツや共通の依存関係を簡単に定義できます：

subprojects {
    apply plugin: 'java'
    apply plugin: 'eclipse-wtp'

    repositories {
       mavenCentral()
    }

    dependencies {
        testCompile 'junit:junit:4.11'
    }

    version = '1.0'

    jar {
        manifest.attributes provider: 'gradle'
    }
}

Notice that our sample applies the Java plugin to each subproject. This means the tasks and configuration properties we have seen in the previous section are available in each subproject. So, you can compile, test, and JAR all the projects by running gradle build from the root project directory.

この例で、各サブプロジェクトにJavaプラグインが適用されていることに注意してください。 これは、前の節で述べたタスクや設定プロパティが各サブプロジェクトでも利用可能であることを意味しています。 そんなわけで、ルートプロジェクトディレクトリからgradle buildを実行することによって、 すべてのプロジェクトをコンパイルし、テストし、JARを生成できるのです。

Also note that these plugins are only applied within the subprojects section, not at the root level, so the root build will not expect to find Java source files in the root project, only in the subprojects.

You can add dependencies between projects in the same build, so that, for example, the JAR file of one project is used to compile another project. In the api build file we will add a dependency on the shared project. Due to this dependency, Gradle will ensure that project shared always gets built before project api.

同じビルド内のプロジェクト間の依存関係を追加することもできます。したがって例えば、一つのプロジェクトのJARファイルを別のプロジェクトのコンパイルのために利用することもできます。ここでは、apiのビルドファイルにsharedプロジェクトが作るJARへの依存関係を追加します。この依存関係のため、Gradleはsharedプロジェクトがapiプロジェクトより前にビルドされることを確実にします。

dependencies {
    compile project(':shared')
}

See 「依存プロジェクトをビルドしないようにするDisabling the build of dependency projects」 for how to disable this functionality.

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

We also add a distribution, that gets shipped to the client:

顧客に出荷する配布物も追加しておきましょう：

task dist(type: Zip) {
    dependsOn spiJar
    from 'src/dist'
    into('libs') {
        from spiJar.archivePath
        from configurations.runtime
    }
}

artifacts {
   archives dist
}