[GRADLE-1146] Eclipse task fails with StackOverflowError in case of cycle in library dependencies Created: 10/Sep/10  Updated: 04/Jan/13  Resolved: 25/Jan/11

Status: Resolved
Project: Gradle
Affects Version/s: 0.9
Fix Version/s: 0.9.2

Type: Bug
Reporter: Artur Nowak Assignee: Unassigned
Resolution: Fixed Votes: 1

Issue Links:
Duplicates GRADLE-1330 StackOverflowError in Eclipse plugin ... Resolved


This problem is symmetrical to GRADLE-1099, but is limited to gradle-eclipse codebase and isn't either caused by GCC-715, so I've decided to fill in a new bug report.

I've created a branch called handleCycleInLibraries on my fork on github: http://github.com/anowak/gradle. It contains both test and a solution to this problem. I will also create a pull request, although I don't know if it's recommended, since there is no mention of it on wiki page regarding contributing. Please ignore it if it's superfluous.

I've extended EclipseIntegrationTest with a scenario that exposes this problem: if we add dependency on a library that has a cycle in its dependencies (as is the case with 'org.apache.xmlgraphics:fop:1.0'), then resolving them during operation of adding JavaDoc/sources modules leads to infinite loop. Hopefully, some other library can be used in this test, because using FOP is quite bandwidth intensive and it unnecessary lengthens test's execution time.

Comment by Brian Trezise [ 23/Dec/10 ]

Is there a work around for this? Or can we expect a fix soon? I've got a problem with needing this exact dependency ('org.apache.xmlgraphics:fop:1.0'). I tried running @jar but then I don't get fop's dependencies, which is obviously a problem. Suggestions?

Comment by Artur Nowak [ 23/Dec/10 ]

Hello, you can use a Gradle distribution from my github fork: http://github.com/anowak/gradle. I try to keep it pretty updated to the Gradle trunk.

Comment by Brian Trezise [ 27/Dec/10 ]

@Artur... no offense intended but my boss would never agree to run a non-trunk version of the software. Any other ideas?

Comment by Artur Nowak [ 28/Dec/10 ]

If you cannot modify Gradle source (even yourself) and you're totally blocked by this issue, then I think that only valid options that you have is either overwriting eclipseClasspath task to produce some file calculated by hand (quick & dirty) or setting up a proxy Maven repository modifying POMs for FOP so the dependency cycle would be removed (mundane & temporary as well).

Generated at Wed Jun 30 11:48:07 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.