This GRADLE-2693. There’s some contention of whether this is an issue that needs to be addressed. Gradle isn’t Ivy and thus there’s no guarantee that dependency resolution will behave as it does in Ivy. Perhaps you could explain your use case for private configurations further. There may be another solution.
Thanks for the reply, Mark. This issue came up because someone was depending on an artifact I published. I thought it was safe to remove the “privateConf” from the Ivy file I published, but when I did, the other person’s build failed with
> Could not resolve all dependencies for configuration ':otherProject:testCompile'.
> Module version com.example:exampleProject:1.0.0, configuration 'default' declares a dependency on configuration 'privateConf' which is not declared in the module descriptor for com.example:example:1.2.3
I was surprised that a module could depend on a private configuration.
The problem was easy enough to fix but I just wanted to check if this behavior was by design or a bug.
I think it’s a legitimate bug: Gradle should honour the clear semantics of the ‘ivy.xml’ file in this case, and just strip the private configurations when building it’s internal model of the Ivy file.