[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: |
|
||||||||
| Description |
|
This problem is symmetrical to 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. |
| Comments |
| 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). |