Gradleの紹介

1概要

Gradle は、Javaベースのプロジェクトをビルドするために特別に設計されたGroovyベースのビルド管理システムです。

インストール手順はhttps://gradle.org/install/[here]にあります。

2ビルディングブロック - プロジェクトとタスク

  • Gradleでは、ビルドは1つ以上のプロジェクトで構成され、各プロジェクトは1つ以上のタスクで構成されています。

Gradleのプロジェクトは、 jar war 、さらには zip ファイルを組み立てることができます。

  • タスクは単一の作業です** これにはクラスのコンパイル、またはJava/Webアーカイブの作成と公開が含まれます。

単純なタスクは次のように定義できます。

task hello {
    doLast {
        println 'Baeldung'
    }
}

build.gradle が存在するのと同じ場所から gradle -q hello コマンドを使用して上記のタスクを実行すると、コンソールに出力が表示されます。

2.1. タスク

GradleのビルドスクリプトはGroovyに他なりません。

task toLower {
    doLast {
        String someString = 'HELLO FROM BAELDUNG'
        println "Original: "+ someString
        println "Lower case: " + someString.toLowerCase()
    }
}

他のタスクに依存するタスクを定義できます。タスク依存関係は、タスク定義に dependsOn:taskName 引数を渡すことで定義できます。

task helloGradle {
    doLast {
        println 'Hello Gradle!'
    }
}

task fromBaeldung(dependsOn: helloGradle) {
    doLast {
        println "I'm from Baeldung"
    }
}

2.2. タスクに行動を追加する

タスクを定義し、いくつかの追加の動作でそれを強化することができます。

task helloBaeldung {
    doLast {
        println 'I will be executed second'
    }
}

helloBaeldung.doFirst {
    println 'I will be executed first'
}

helloBaeldung.doLast {
    println 'I will be executed third'
}

helloBaeldung {
    doLast {
        println 'I will be executed fourth'
    }
}

doFirst doLast はそれぞれアクションリストの最上部と最下部にアクションを追加し、 は単一のタスク内で複数回定義できます

2.3. タスクプロパティの追加

プロパティを定義することもできます。

task ourTask {
    ext.theProperty = "theValue"
}

ここでは、 "theValue" ourTask タスクの theProperty として設定しています。

3プラグインを管理する

Gradleには、 script、 、および__binaryの2種類のプラグインがあります。

追加機能の恩恵を受けるには、すべてのプラグインは2つのフェーズを経る必要があります: resolving applying.

  • Resolving は、正しいバージョンのプラグインjarを見つけてそれをプロジェクトの classpath に追加することを意味します。

  • Applying プラグインはプロジェクト Plugin.apply(T) __ を実行しています。

3.1. スクリプトプラグインの適用

__aplugin.gradleでは、タスクを定義できます。

task fromPlugin {
    doLast {
        println "I'm from plugin"
    }
}

このプラグインをプロジェクトの build.gradle ファイルに適用する場合は、次の行を build.gradle に追加するだけです。

apply from: 'aplugin.gradle'

さて、 gradle tasks コマンドを実行すると、タスクリストに fromPlugin タスクが表示されるはずです。

3.2. プラグインDSL を使用したバイナリプラグインの適用

コアバイナリプラグインを追加する場合は、ショートネームまたはプラグインIDを追加できます。

plugins {
    id 'application'
}

これで、 application pluginからの run タスクが、任意の runnable jarを実行するためのプロジェクトで使用可能になります。コミュニティプラグインを適用するには、完全修飾プラグインIDを指定する必要があります。

plugins {
    id "org.shipkit.bintray" version "0.9.116"
}

これで、 Shipkit タスクが gradle tasks リストに表示されるはずです。

プラグインDSLの制限は以下のとおりです。

  • plugins ブロック内のGroovyコードをサポートしていません

  • plugins ブロックはプロジェクトのビルドの最上位ステートメントにする必要があります

スクリプト(その前には buildscripts \ {} ブロックしか使用できません) ** プラグインDSLはスクリプトプラグイン settings.gradle に書くことはできません

ファイルまたはinitスクリプト内

プラグインDSLはまだインキュベート中です。 DSLやその他の設定は、それ以降のGradleバージョンでは変わるかもしれません。

3.3. プラグインを適用するための従来の手順

“ apply plugin” を使ってプラグインを適用することもできます。

apply plugin: 'war'

コミュニティプラグインを追加する必要がある場合は、 buildscript \ {} blockを使用してビルドクラスパスに外部jarを追加する必要があります。

その後、 私たちはビルドスクリプトでプラグインを適用することができますが 既存の plugins \ {} block の後にのみ:

buildscript {
    repositories {
        maven {
            url "https://plugins.gradle.org/m2/"
        }
    }
    dependencies {
        classpath "org.shipkit:shipkit:0.9.117"
    }
}
apply plugin: "org.shipkit.bintray-release"

4依存関係管理

Gradleは非常に柔軟な依存管理システムをサポートしており、利用可能なさまざまなアプローチと互換性があります。

Gradleの依存関係管理のベストプラクティスは、バージョン管理、動的バージョン管理、バージョンの競合の解決、および推移的な依存関係の管理です。

4.1. 依存関係の設定

依存関係はさまざまな構成に分類されます。 設定は名前を持ち、それらはお互いを拡張することができます

Javaプラグインを適用すると、依存関係をグループ化するための compile、testCompile、runtime の設定が利用可能になります。 ** __default c onfigurationは“ runtime”を拡張したものです。

4.2. 依存関係を宣言する

いくつかの異なる方法でいくつかの依存関係(SpringとHibernate)を追加する例を見てみましょう。

dependencies {
    compile group:
      'org.springframework', name: 'spring-core', version: '4.3.5.RELEASE'
    compile 'org.springframework:spring-core:4.3.5.RELEASE',
            'org.springframework:spring-aop:4.3.5.RELEASE'
    compile(
       [group: 'org.springframework', name: 'spring-core', version: '4.3.5.RELEASE'],
       [group: 'org.springframework', name: 'spring-aop', version: '4.3.5.RELEASE']    )
    testCompile('org.hibernate:hibernate-core:5.2.12.Final') {
        transitive = true
    }
    runtime(group: 'org.hibernate', name: 'hibernate-core', version: '5.2.12.Final') {
        transitive = false
    }
}

compile testCompile 、および runtime のさまざまな構成で依存関係をさまざまな形式で宣言しています。

時には、複数のアーティファクトを持つ依存関係が必要になります。そのような場合は、アーティファクトのみの表記法 @ extensionName (または展開された形式では ext )を追加して、目的のアーティファクトをダウンロードできます。

runtime "org.codehaus.groovy:groovy-all:[email protected]"
runtime group: 'org.codehaus.groovy', name: 'groovy-all', version: '2.4.11', ext: 'jar'

ここでは、依存関係なしでjarアーティファクトのみをダウンロードするための @ jar 表記を追加しました。

ローカルファイルに依存関係を追加するには、次のようにします。

compile files('libs/joda-time-2.2.jar', 'libs/junit-4.12.jar')
compile fileTree(dir: 'libs', include: '** .jar')
  • 推移的な依存関係を避けたい場合は、 設定レベルまたは依存レベル** で実行できます。

configurations {
    testCompile.exclude module: 'junit'
}

testCompile("org.springframework.batch:spring-batch-test:3.0.7.RELEASE"){
    exclude module: 'junit'
}

5マルチプロジェクトビルド

5.1. ライフサイクルを構築する

初期化段階で、Gradleはどのプロジェクトがマルチプロジェクトビルドに参加するかを決定します。

これは通常、プロジェクトのルートにある settings.gradle ファイルに記載されています。 Gradleは参加プロジェクトのインスタンスも作成します。

設定段階では、作成されたプロジェクトインスタンスはすべてGradle機能設定に基づいて設定されます。

この機能では、特定のタスクの実行に必要なプロジェクトのみが構成されています。このようにして、大規模なマルチプロジェクトビルドでの設定時間が大幅に短縮されます。この機能はまだインキュベーション中です。

最後に、 実行段階で、作成および設定されたタスクのサブセットが実行されます これら3つの段階を認識するために settings.gradle および build.gradle ファイルにコードを含めることができます。

settings.gradle 内:

println 'At initialization phase.'

build.gradle で:

println 'At configuration phase.'

task configured { println 'Also at the configuration phase.' }

task execFirstTest { doLast { println 'During the execution phase.' } }

task execSecondTest {
    doFirst { println 'At first during the execution phase.' }
    doLast { println 'At last during the execution phase.' }
    println 'At configuration phase.'
}

5.2. マルチプロジェクトビルドを作成する

ルートフォルダで gradle init コマンドを実行して、 settings.gradle ファイルと build.gradle ファイルの両方のスケルトンを作成できます。

一般的な設定はすべてルートビルドスクリプトに保存されます。

allprojects {
    repositories {
        mavenCentral()
    }
}

subprojects {
    version = '1.0'
}

設定ファイルには、ルートプロジェクト名とサブプロジェクト名を含める必要があります。

rootProject.name = 'multi-project-builds'
include 'greeting-library','greeter'

マルチプロジェクトビルドのデモを行うには、 greeting-library greeter という名前のサブプロジェクトフォルダーをいくつか用意する必要があります。各サブプロジェクトには、それぞれの依存関係やその他の必要な構成を構成するための個別のビルドスクリプトが必要です。

greeter プロジェクトを greeting-library に依存させたい場合は、依存関係を greeter のビルドスクリプトに含める必要があります。

dependencies {
    compile project(':greeting-library')
}

6. Gradle Wrapperを使う

GradleプロジェクトにLinux用の gradlew ファイルとWindows用の gradlew.bat ファイルがある場合、プロジェクトをビルドするためにGradleをインストールする必要はありません。

Windowsで gradlew build を、Linuxで ./gradlew build を実行すると、 gradlew ファイルで指定されたGradleディストリビューションが自動的にダウンロードされます。

Gradleラッパーをプロジェクトに追加したい場合は、

gradle wrapper --gradle-version 4.2.1

コマンドはプロジェクトのルートから実行する必要があります。これにより、Gradleラッパーをプロジェクトに結び付けるために必要なすべてのファイルとフォルダーが作成されます。もう1つの方法は、ラッパータスクをビルドスクリプトに追加することです。

task wrapper(type: Wrapper) {
    gradleVersion = '4.2.1'
}

今度は wrapper タスクを実行する必要があり、タスクは私たちのプロジェクトをラッパーに結び付けます。 gradlew ファイルの他に、 wrapper フォルダーがjarファイルとプロパティファイルを含む gradle フォルダー内に生成されます。

Gradleの新しいバージョンに切り替えたい場合は、 gradle-wrapper.properties のエントリを変更するだけで済みます。

7. 結論

この記事では、Gradleを見て、バージョンの競合の解消と他動的な依存関係の管理に関して、他の既存のビルドツールよりも優れた柔軟性があることを確認しました。

この記事のソースコードはhttps://github.com/eugenp/tutorials/tree/master/gradle[over on GitHub]にあります。

"