Gradle：依存関係の管理

依存関係管理は、ビルドシステムの中で最も重要な機能の1つです。 AndroidプロジェクトのメインビルドシステムとしてGradleが登場したことで、依存関係管理の部分に大きな変化があり、JARファイルを手動でコピーし、失敗したプロジェクト構成をめぐるタンバリンとの長いダンスの時代は終わりました。







この記事では、Gradleの依存関係管理の基本について説明し、詳細な実用例、小さなライフハック、およびドキュメント内の適切な場所へのリンクを提供します。

リポジトリ

ご存じのように、Gradleには独自のリポジトリがなく、MavenおよびIvyリポジトリを依存関係のソースとして使用します。 同時に、リポジトリを操作するためのインターフェースは基本的なレベルで違いはありません。パラメーターの違いについては、 IvyArtifactRepositoryリンクとMavenArtifactRepositoryリンクからさらに学ぶことができます 。 「http」、「https」、または「file」プロトコルをURLとして使用できることに注意してください。 リポジトリが記録される順序は、リポジトリで依存関係が検索される順序に影響します。

// build.gradle repositories { maven { url "http://example.com" } ivy { url "http://example.com" } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

依存関係の宣言

 // build.gradle apply plugin: 'java' repositories { mavenCentral() } dependencies { compile group: 'com.googlecode.jsontoken', name: 'jsontoken', version: '1.1' testCompile group: 'junit', name: 'junit', version: '4.+' }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

上記の例では、プロジェクトをコンパイルするための異なる構成（compileとtestCompile）の2つの依存関係が接続されているビルドスクリプトが表示されます。 JsonTokenはプロジェクトのコンパイルとプロジェクトテストのコンパイル中に接続され、jUnitはプロジェクトテストのコンパイル中のみ接続されます。 コンパイル構成の詳細については、 こちらをご覧ください 。



また、jUnit依存関係を動的（+）として接続していることもわかります。 最新のバージョン4. +が使用されます。マイナーアップデートを追跡する必要はありません（アプリケーションのコンパイルのコンパイルタイプでは、この機能を使用しないことをお勧めします。予期しない、ローカライズが難しい問題が発生する可能性があるためです）。



jUnit依存関係の例については、必要な依存関係を見つけるための標準的なGradleメカニズムを検討してください。

 1.  compile ("org.junit:junit:4.+") 2.    group: "org.junit" name: "junit" version: "4.+" 3.      [junit:4.1] … [junit:4.12] 4.     [junit:4.12] 5.    [junit:4.12] dependencies { … } artifacts { … } 6.      junit-4.12.jar junit-4.12-source.jar junit-4.12-javadoc.zip
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

キャッシュ

Gradleには、デフォルトで依存関係を24時間保存するキャッシュシステムがありますが、この動作はオーバーライドできます。

 // build.gradle configurations.all { resolutionStrategy.cacheChangingModulesFor 4, 'hours' resolutionStrategy.cacheDynamicVersionsFor 10, 'minutes' }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

キャッシュにデータを保存するために設定された時間が経過すると、システムはタスクを開始するときに、動的依存関係と変更依存関係を更新する可能性を最初にチェックし、必要に応じて更新します。



Gradleは、以前にダウンロードされたファイルをアップロードしないようにし、URL /ファイルソースが異なっていても、これに検証システムを使用します。 Gradleは、キャッシュ（URL、バージョンとモジュール名、Gradleの他のバージョンのキャッシュ、Mavenキャッシュ）、HTTPリクエストヘッダー（日付、コンテンツ長、ETag）、SHA1ハッシュ（利用可能な場合）を常にチェックします。 一致するものが見つからない場合、システムはファイルをダウンロードします。



また、ビルドシステムには2つのパラメータがあり、起動時に特定のタスクのキャッシュポリシーを変更できます。



--offline-Gradleは、依存関係の更新を確認するためにネットワークに接続しようとしません。

--refresh-dependencies-Gradleはすべての依存関係を更新しようとします。 キャッシュ内のデータが破損した場合に使用すると便利です。 キャッシュされたデータを検証し、異なる場合は更新します。



Gradle User Guideで依存関係のキャッシュの詳細を読むことができます。

依存関係の種類

Gradleにはいくつかの種類の依存関係があります。 最も一般的に使用されるのは次のとおりです。



-外部プロジェクトの依存関係-外部リポジトリからダウンロードされた依存関係。

 // build.gradle dependencies { compile "com.android.support:appcompat-v7:23.1.1" }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

-プロジェクトの依存関係-1つのプロジェクトのフレームワーク内のモジュール（サブプロジェクト）への依存。

 // build.gradle dependencies { compile project(':subproject') }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

-ファイルの依存関係-ファイルとして接続された依存関係（jar / aarアーカイブ）。

 build.gradle repositories { flatDir { dirs 'aarlibs' //  ,  aar-   } } dependencies { compile(name:'android_library', ext:'aar') //  aar- compile files('libs/a.jar', 'libs/b.jar') compile fileTree(dir: 'libs', include: '*.jar') }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クライアントモジュールの依存関係、Gradle APIの依存関係、およびローカルGroovyの依存関係もあります。 それらはめったに使用されないため、この記事のフレームワークではそれらを分解しませんが、それらに関するドキュメントはこちらで読むことができます 。

依存ツリー

各外部または設計の依存関係には、独自の依存関係が含まれている場合があり、それらを考慮してダウンロードする必要があります。 したがって、コンパイル中に、選択した構成の依存関係が読み込まれ、依存関係ツリーが構築されます。その人間表現は、Android StudioのGradleタスク「dependencies」またはプロジェクトルートフォルダーにあるコンソールのgradle％module_name％：依存関係コマンドを実行することで確認できます。 応答として、使用可能な各構成の依存関係ツリーのリストを取得します。



構成パラメーターを使用して、構成名を指定して、指定された構成のみの依存関係ツリーを表示します。



githubにあるリポジトリの特別に準備されたソースを取得して、特定の構成の依存関係ツリーを取得してみましょう（プロジェクトが状態0になった瞬間、つまりbuild.gradle.0がbuild.gradleとして使用されます）。







依存関係ツリーを分析した後、アプリモジュールは2つの外部依存関係（appcompatとguava）を依存関係として使用し、2つの設計依存関係（1番目と2番目）を使用していることがわかります。 プロジェクトがクラスパスに同じライブラリの2つのバージョンを含むことはできないことは明らかであり、これは必要ありません。 この時点で、Gradleには競合解決モジュールが含まれています。

紛争解決

Gradle DSLには、依存関係の競合を解決するために使用されるコンポーネントが含まれています。 上記の依存関係ツリーでjsontokenライブラリの依存関係を見ると、それらは一度しか表示されません。 2番目のモジュールでは、jsontokenライブラリの依存関係は指定されておらず、依存関係自体の出力には '-> 1.1'が追加されています。つまり、ライブラリバージョン1.0は使用されませんが、Gradle競合解決モジュールを使用してバージョン1.1に自動的に置き換えられます。



競合がどのように解決されたかを説明するために、GradleタスクのdependencyInsightを使用することもできます。次に例を示します。







競合解決の結果としてバージョン1.1が選択されることに注意してください。他のルールの結果として選択することもできます（たとえば、強制選択またはルール選択）。 この記事では、依存関係を解決するための戦略に影響するルールの使用例を示します。dependencyInsightタスクを完了した後、以下の各ステップでライブラリの特定のバージョンを選択する理由を確認できます。 これを行うには、各ステージに移動するときに、dependencyInsightタスクを個別に実行できます。



必要に応じて、たとえば、プロジェクトの構成中に競合が検出されたときにフォールドするように指示することで、Gradle競合解決モジュールのロジックを再定義できます。 （状態1）

 // build.gradle // … configurations.compile.resolutionStrategy { failOnVersionConflict() }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、Gradle依存関係ツリーを構築しようとしても、アプリケーションの依存関係の競合によりタスクが中断されます。







この問題には4つの解決策があります。



最初のオプションは、競合解決戦略を無効にする行を削除することです。



2番目のオプションは、特定のバージョン（状態2）を示す、jsonTokenライブラリーの必須使用規則を競合解決戦略に追加することです。

 // build.gradle // … configurations.compile.resolutionStrategy { force 'com.googlecode.jsontoken:jsontoken:1.1' failOnVersionConflict() }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このソリューションを適用すると、依存関係ツリーは次のようになります。







3番目のオプションは、jsonTokenライブラリをアプリプロジェクトの依存関係として明示的に追加し、その依存関係にforceパラメーターを割り当てることです。これにより、使用するライブラリのバージョンが明示的に示されます。 （状態3）

 // build.gradle // … dependencies { compile fileTree(dir: 'libs', include: ['*.jar']) compile 'com.android.support:appcompat-v7:23.1.1' compile 'com.google.guava:guava:+' compile project(":first") compile project(":second") compile ('com.googlecode.jsontoken:jsontoken:1.1') { force = true } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、依存関係ツリーは次のようになります。







4番目のオプションは、excludeパラメーターを使用して、プロジェクトの依存関係の1つから独自の依存関係の1つからjsontokenを除外することです。 （状態4）

 // build.gradle dependencies { compile fileTree(dir: 'libs', include: ['*.jar']) compile 'com.android.support:appcompat-v7:23.1.1' compile 'com.google.guava:guava:+' compile project(":first") compile(project(":second")) { exclude group: "com.googlecode.jsontoken", module: 'jsontoken' } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、依存関係ツリーは次のようになります。







excludeは両方のパラメーターを同時に渡す必要はなく、1つしか使用できないことに注意してください。



しかし、依存関係ツリーの正しい出力にもかかわらず、アプリケーションをビルドしようとすると、Gradleはエラーを返します。







エラーの原因は、ビルドタスク実行メッセージの出力から理解できます。同じパッケージ名のGwtCompatibleクラスは、いくつかの依存関係に含まれています。 これは事実です。事実、アプリプロジェクトは依存関係としてguavaライブラリを使用し、jsontokenライブラリは依存関係で古いGoogleコレクションを使用しています。 Googleコレクションはグアバの一部であり、同じプロジェクトで共有することはできません。



プロジェクトのビルドを成功させるには、次の3つのオプションがあります。



1つ目は、アプリモジュールの依存関係からguavaを削除することです。 Googleコレクションに含まれるグアバの一部のみを使用する場合、提案されたソリューションは適切です。



2番目は、最初のモジュールからGoogleコレクションを除外することです。 上記の例外または構成ルールを使用してこれを実現できます。 最初に例外を使用して、両方のオプションを検討してください（状態5）

 // build.gradle dependencies { compile fileTree(dir: 'libs', include: ['*.jar']) compile 'com.android.support:appcompat-v7:23.1.1' compile 'com.google.guava:guava:+' compile(project(":first")) { exclude module: 'google-collections' } compile(project(":second")) { exclude group: "com.googlecode.jsontoken", module: 'jsontoken' } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

構成ルールの使用例（状態6）：

 //build.gradle configurations.all { exclude group: 'com.google.collections', module: 'google-collections' } dependencies { compile fileTree(dir: 'libs', include: ['*.jar']) compile 'com.android.support:appcompat-v7:23.1.1' compile 'com.google.guava:guava:+' compile project(":first") compile(project(":second")) { exclude group: "com.googlecode.jsontoken", module: 'jsontoken' } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Googleコレクションの例外の両方の実装の依存関係ツリーは同じです。







3番目のオプションは、モジュール置換機能を使用することです（状態7）：

 // build.gradle dependencies { modules { module('com.google.collections:google-collections') { replacedBy('com.google.guava:guava') } } compile fileTree(dir: 'libs', include: ['*.jar']) compile 'com.android.support:appcompat-v7:23.1.1' compile 'com.google.guava:guava:+' compile project(":first") compile(project(":second")) { exclude group: "com.googlecode.jsontoken", module: 'jsontoken' } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

依存関係ツリーは次のようになります。







競合が発生した場合にアセンブリを中断することを示す定義済みの競合解決ロジックを終了すると、構成段階でタスクの実行が中断されることに注意してください。 つまり、モジュール置換ルールの使用は、依存関係間の競合解決戦略のルールの1つです。



また、Gradle依存関係のリストからguavaを削除すると、Googleコレクションがプロジェクトに保存され、それに依存する機能が実行を継続できるため、前述のオプションの最後が最も柔軟性が高いことに注意することも重要です。 そして、依存関係ツリーは次のようになります。







各オプションの後、コンパイルおよび起動されたアプリケーションの形で成功を収めます。



しかし、別の状況（状態8）を見てみましょう。ワイヤーモックの動的な依存性が大幅に削減されています（スクリーンショットのサイズを小さくするため）。 トレーニング目的でのみ使用します。代わりに、同僚が提供するライブラリを想像してください。彼はいつでも新しいバージョンをリリースできます。最新バージョンを使用する必要があります。

 // build.gradle configurations.all { exclude group: 'org.apache.httpcomponents', module: 'httpclient' exclude group: 'org.json', module: 'json' exclude group: 'org.eclipse.jetty' exclude group: 'com.fasterxml.jackson.core' exclude group: 'com.jayway.jsonpath' } dependencies { compile 'com.github.tomakehurst:wiremock:+' }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

依存関係ツリーは次のとおりです。







ご覧のとおり、Gradleはベータ版であるwiremockの最新バージョンをダウンロードします。 デバッグアセンブリの状況は正常ですが、アセンブリをユーザーに提供する場合は、リリースバージョンを使用してアプリケーションの品質を確認する必要があります。 しかし、同時に、常に最新バージョンと頻繁なリリースを使用する必要があるため、wiremockバージョンを動的に指定することを拒否する方法はありません。 この問題の解決策は、依存関係のバージョンを選択する戦略について独自のルールを作成することです。

 // build.gradle //… configurations.all { //… resolutionStrategy { componentSelection { all { selection -> if (selection.candidate.version.contains('alpha') || selection.candidate.version.contains('beta')) { selection.reject("rejecting non-final") } } } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このルールは、wiremockだけでなく、すべての依存関係に適用されることに注意してください。

その後、情報モードで依存関係ツリーを表示するタスクを開始し、ライブラリのベータ版がどのように破棄されるか、およびそれらが破棄された理由を確認します。 最終的に、安定バージョン1.58が選択されます。







しかし、テスト中に、バージョン1.58に重大なバグがあり、アセンブリをこの状態でリリースできないことがわかりました。 この問題を解決するには、依存関係のバージョンを選択するための別のルールを記述します。

 // build.gradle //… configurations.all { //… resolutionStrategy { componentSelection { // … withModule('com.github.tomakehurst:wiremock') { selection -> if (selection.candidate.version == "1.58") { selection.reject("known bad version") } } } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、wiremock 1.58も破棄され、バージョン1.57の使用が開始され、依存関係ツリーは次のようになります。

おわりに

記事が非常に膨大であることが判明したという事実にもかかわらず、Gradleの依存関係管理のトピックには、この記事のフレームワーク内で発表されていない多くの情報が含まれています。 公式のユーザーガイドとGradle DSLのドキュメントの助けを借りて、この世界を深く掘り下げることをお勧めします。GradleDSLのドキュメントは勉強に時間がかかります。



しかし、その結果、自動化のおかげで、またさまざまなバグが表示されたときに何をする必要があるかを理解したおかげで、数十時間を節約する機会が得られます。 たとえば、最近65KメソッドとMultidexのバグは非常に活発でしたが、依存関係の適切な表示とexcludeの使用のおかげで、問題は非常に迅速に解決されます。



また読む： Gradle：5つの開発者の利点