[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
|Affects Version/s:||1.0-milestone-3, 1.0-milestone-4|
|Reporter:||Kris De Volder||Assignee:||Daz DeBoer|
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:
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"
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