If a project declares two dependencies that only differ in classifier, then the Gradle tooling API will incorrectly merge them, dropping one of the dependencies.

For example project declares this:

dependencies {
	compile 'org.myorg:Testproject1:0.1'
	testCompile 'org.myorg:Testproject1:0.1:tests'
}

But the tooling API's EclipseProject model will only return the jar file from the testCompile dependency and loose the other one.

This issue was reported in the STS issue tracker here: https://issuetracker.springsource.com/browse/STS-1838

An example zip containing two projects is attached. (The projects are slighly modified from those in the STS issue, because they in fact triggered a different bug, which I reported here http://issues.gradle.org/browse/GRADLE-1621.

To reproduce the problem:

1) on TestProject1 run "gradle uploadArchives"
This should upload three jars to the flat directory file repository. One of them is a sources.jar for the compile dependency.
2) on TestProject2 Build the EclipseProject model and retrieve its class path entries.
(In STS/Eclipse you can do this by running refresh dependencies)

Observed (in Eclipse). The EclipseProject model is incomplete and is missing the compile dependency. This causes compile errors to remain in the Eclipse project. However, building the project on the commandline with "gradle package" will produce no errors.