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]にあります。