2016-01-28 12 views
7

Sto esponendo uno strano comportamento nella gestione delle dipendenze gradle, dove il progetto A fa riferimento al progetto B come dipendenza di compilazione e al progetto B fa riferimento alla libreria C come dipendenza di runtime. Ora posso utilizzare le classi dalla libreria C nel mio progetto A.gradle include la dipendenza da runtime transitivo come dipendenza di compilazione

La mia domanda: (Perché) si tratta di un bug o di una funzionalità?

Il problema può essere riprodotto con Gradle 2.9 e 2.10 e la seguente configurazione minima:

// 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" 
    } 
} 

Come si può vedere, un Gradle :A:dependencies mostra

[...] 

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 
[...] 

e l'utilizzo di log4j è totalmente possibile nel codice java che risiede nel progetto A.

+0

Grazie per aver chiesto questo Michael. Il comportamento di gradle in questo caso è totalmente controintuitivo :-( – Peti

risposta

5

Vedere this Q & A. Se non si specifica una configurazione, Gradle sceglierà la configurazione default che si estende da runtime. Una soluzione rapida è usare

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

La configurazione 'default' si estende da' runtime' che significa che, secondo la spiegazione sul Q & A, "contiene tutte le dipendenze e gli artefatti della configurazione' runtime' e potenzialmente più ". Le dipendenze del progetto": B "nella configurazione di runtime sono' runtime'. Questo non spiega ancora perché la dipendenza 'slf4j-api' si presenta come' compile' nel progetto ": A". – dmoebius

+1

Il metodo 'compile project (': B')' prende la configurazione 'default' dal Project B e la aggiunge alla configurazione' compile' del progetto A. È quindi logico che le dipendenze di 'runtime' di B vengano aggiunte alla' compile' di A dipendenze –

+2

Ho discusso offline con @dmoebius e, sebbene la risposta sia completamente corretta e utile, è necessario tenere a mente quanto segue: Specificando esplicitamente la configurazione 'compile' si impedirà effettivamente la compilazione dei progetti c lasspath dall'essere "inquinato" con le dipendenze del runtime transitivo, ma i progetti * runtime * classpath ora mancano anche queste dipendenze del runtime transitivo. Quindi puoi vivere con la configurazione di default in uso o devi aggiungere una seconda dipendenza per mappare 'runtime'to' runtime': 'progetto di runtime (percorso:": B ", configurazione:" runtime ")' –

Problemi correlati