I’m finding it incredibly difficult to keep binary dependencies out of a multi-project build, where a dependency is both a project dependency, and declared as a dependency for a published artifact. It causes jars to be included in the configuration and failures like these:
Why don’t the project dependencies replace the binary dependencies? These are technically conflicts and I’d expect the project dependency to always win. Is there any way to replace these binary dependencies w/ project dependencies manually (I looked at ResolutionStrategy, but it only takes a notation as a replacement it seems).
This functionality would also allow builds that automatically replace artifact w/ project dependendencies, avoiding the workarounds like this. Is there an improvement ticket for this specifically - it’s really critical for multi-project builds, given how much breakage this can cause.
Gradle doesn’t currently correlate project dependencies and external dependencies. There are longer-term plans to make dependencies location-agnostic (that information should come from elsewhere).
That said, I don’t quite understand how you are getting into the situation that within the same build, you have a project dependency and an external dependency that ultimately are the same thing.
The problem isn’t with a straight forward multi-project build, it’s an uberbuild that brings in external projects. The projects that are the problem are decoupled plugins that target multiple versions of our platform. I’m using an approach similar to your ‘elastic’ example to switch the platform dependencies to project dependencies when a plugin project is included in the platform build, because we maintain API compatibility that’s safe. But there are some dependencies we can’t include as projects in the build because different versions are used in the plugins, and those depend on the platform artifacts which results in configurations that include artifact and project dependencies.
The main problem ‘testArchives’ configuration which we use for ‘test’ classifier published artifacts. The IDEA plugin attempts to resolve the configuration against the notated artifact, which doesn’t have the configuration.
It also means that we get both module and jar dependencies in the build, which puts them on the classpath in IDEA.
That and it’d be awesome to be able to do this without having to add a method wrapping all of the dependencies 
Now I think about this some more, I we might be able to avoid this by using the problematic dependencies non-transitively, or at least excluding the offending modules. The war projects generally have the required dependencies in the providedCompile configuration anyway.