2016-01-28 26 views
7

プロジェクトAがプロジェクトBをコンパイル依存として参照し、プロジェクトBがライブラリCをランタイム依存性として参照する、グラデル依存性管理で奇妙な動作が発生します。今度は私のプロジェクトでライブラリCのクラスを使用できます。gradleにコンパイル依存性としての推移的ランタイム依存性が含まれています

私の質問:(これはバグですか、機能ですか?

問題は2.9のGradleと2.10と、次の最小限のセットアップを再現することができます:あなたが見ることができるように

// settings.gradle 
include ':A', ':B' 
// build.gradle 
allprojects { 
    apply plugin: 'java' 
    apply plugin: 'maven' 

    repositories { 
     mavenLocal() 
     mavenCentral() 
    } 
} 

project(':A') { 
    dependencies { 
     compile project(':B') 
    } 
} 

project(':B') { 
    dependencies { 
     runtime "org.slf4j:slf4j-log4j12:1.7.13" 
    } 
} 

、Gradleの:A:dependencies

[...] 

compile - Compile classpath for source set 'main'. 
\--- project :B 
    \--- org.slf4j:slf4j-log4j12:1.7.13 
      +--- org.slf4j:slf4j-api:1.7.13 
      \--- log4j:log4j:1.2.17 
[...] 

とのlog4jを使用してを示していプロジェクトAに常駐するJavaコードでは完全に可能です。

+0

マイケルにお尋ねいただきありがとうございます。この場合のgradleの振る舞いは完全に直感的ではありません:-( – Peti

答えて

5

this Q & Aを参照してください。設定を指定しない場合、の設定はruntimeから選択されます。クイックフィックスを使用することです

compile project(path: ":B", configuration: "compile") 
+0

'default'設定は' runtime'から拡張されています。つまり、Q&Aの説明によれば、 '' runtime'設定のすべての依存関係と成果物プロジェクト ":B"の実行時設定の依存関係は 'runtime'です。これは依然として依存関係' slf4j-api'がプロジェクト ":A"で 'compile'と表示される理由を説明していません。 – dmoebius

+1

'compile project( ':B')'メソッドは、プロジェクトBから 'default'設定を受け取り、プロジェクトAの' compile'設定に追加します。したがって、Bの 'runtime'依存性がAの' compile'依存関係 –

+2

私はこれをオフラインで@dmoebiusと議論しましたが、その答えはまったく正しかったですが、次の点に留意してください。 'compile'設定を明示的に指定すると、プロジェクトがc lasspathが推移的なランタイム依存関係で「汚染」されることはありませんが、あなたのプロジェクト*ランタイム*クラスパスにはこれらの推移的なランタイム依存性も欠落しています。したがって、 'default'設定を使用するか、' runtime'to 'runtime'にマッピングするための第2の依存関係を追加する必要があります:' runtime project(path: ":B"、configuration: "runtime") ' –

関連する問題