Why does not Gradle fail if resolving a private configuration

(detelinyordanov) #1

I’m using Gradle 1.4 and noticed that if I try to resolve some dependency that references a private configuration, the resolve is successful:

dependencies {
    compile (group: 'org.foo', name: 'bar', version: '1.0.0', configuration: 'compile')

The same dependency fails to resolve with Apache Ivy, so why does Gradle allow it?



(Luke Daley) #2

It most likely was not a conscious decision, just an omission. Gradle is not Apache Ivy and isn’t a one for one replacement.

Is this causing you problems? If so, would you mind explaining your scenario?

(detelinyordanov) #3

We have a multi-project build that uses Gradle (most of our builds are using Gradle). Some modules happen to reference other module’s private configurations, and this did not cause any problems - in fact we did not actually notice it, until a project that uses Apache Ivy attempted to reference those modules and got a resolution failure (e.g. ‘configuration not public in org.foo#bar;1.0.0’).

So now we are trying to modify all these projects to reference just the public configurations - for example if a project is referencing other project’s ‘providedCompile’ configuration, which is private, we are changing it to ‘providedRuntime’ (these are custom provided configuration we’ve introduced).

But in general, I think it would be good if Gradle detects and reports such cases since otherwise it will be impossible for anyone using Apache Ivy to resolve those modules - and I guess there is an overall thinking that ivy metadata produced by Gradle can be consumed with Apache Ivy.

(Luke Daley) #4

Thanks for the info, I’ll raise the discussion internally on what to do about this and post back here.

(Luke Daley) #5

Raised as GRADLE-2693.