[GRADLE-1622] Gradle Tooling API EclipseModel silently drops dependencies if they only differ in classifier Created: 17/Jun/11  Updated: 04/Jan/13  Resolved: 08/Sep/11

Status: Resolved
Project: Gradle
Affects Version/s: 1.0-milestone-3, 1.0-milestone-4
Fix Version/s: 1.0-milestone-5

Type: Bug
Reporter: Kris De Volder Assignee: Daz DeBoer
Resolution: Fixed Votes: 2

Attachments: Zip Archive davide.zip    
Issue Links:
Duplicated by GRADLE-739 Better support for downloading depend... Resolved
Related to GRADLE-1567 Cannot have more than one version of ... Resolved


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.

Comment by Kris De Volder [ 17/Jun/11 ]

BTW: I tried this with M3 and also with a locally build gradle from the git master branch... with the same result.

Comment by Daz DeBoer [ 24/Aug/11 ]

This is certainly a bug in M3 and M4, but the attached sample is hampered by a compounding problem: gradle/ivy doesn't handle classifiers properly with flatdir repositories. Using a maven repository allows the sample to demonstrate the problem, and the fix currently in HEAD.

This bug seems to have been fixed by the fix for GRADLE-739: I'll just add an integration test to prove that, and it will be closed.

Generated at Wed Jun 30 12:00:15 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.