[GRADLE-1472] java.lang.ClassCastException FileCollectionSnapshotImpl cannot be cast to OutputFilesSnapshot Created: 13/Apr/11 Updated: 04/Jan/13 Resolved: 16/Aug/11
|Ildiko Varga Robey
FAILURE: Build aborted because of an internal error.
|Comment by René Gröschke (Inactive) [ 13/Apr/11 ]
Have you recently updated the gradle version on your hudson? did tried to delete the .gradle in your home directory and cleanup the workspace?
|Comment by Ildiko Varga Robey [ 13/Apr/11 ]
We did upgrade recently to milestone 2. I have not tried to clean up the workspace yet. I did not know it was advisable to do so when we upgrade. Good to remember for the future.
For now we downgraded back to milestone 1 and things seems to be working. I will take your advice and clean things up and see where that takes us.
Thanks a lot!
|Comment by Jamie Bisotti [ 15/Apr/11 ]
Just delete the .gradle folder in the user's home directory? It's OK to leave the one in the project root directory?
What's the purpose of the delete/clean-up? Are there known upgrade issues that I just overlooked?
|Comment by Joel Robotham [ 29/May/11 ]
I've had this same stack trace occur twice on our Jenkins server running Gradle 1.0-milestone-3 on Linux.
Deleting the .gradle directory fixes the problem. (until it happens again)
Don't really want to an 'rm -rf .gradle' as a precondition to all my builds....
|Comment by Chris Dail [ 15/Jun/11 ]
I have run into this same issue using Gradle 1.0 milestone 3 on Windows. Same thing as the original post. This occurred from Jenkins. Previously we had been using Gradle version 0.9. Just this week we upgraded to 1.0 milestone 3 and are now experiencing this issue.
Like others have indicated, removing the .gradle directory fixed the problem.
|Comment by Thomas Glaeser [ 30/Jun/11 ]
Seeing this issue very frequently. We are running Jenkins on Linux and Gradle 1.0-m3. Once we had installed 1.0-m1 on the same box but now the default is 1.0-m3 and all Jenkins jobs also explicitly run 1.0-m3. Running with the -C rebuild switch resolves the problem ... for some time
|Comment by Adam Murdoch [ 30/Jun/11 ]
A more reliable workaround is to use the -g option to give each Jenkins build a separate home directory.
|Comment by Thomas Glaeser [ 01/Jul/11 ]
Yes. But can we expect to see this fixed in the near future? Thanks!
|Comment by Adam Murdoch [ 01/Jul/11 ]
Yes. We're just about to finish Gradle 1.0-milestone-4. We'll fix this issue in the release after that.
|Comment by Brett Cave [ 02/Jul/11 ]
This seems to be related to a classloader when Gradle is run within another JVM, e.g. a CI system (we're using Go from thoughtworks, and getting this with milestone-3).
1 more specific workaround seems to be removing the gradleUserHomeDir/caches/VERSION/ directory, perhaps something relating to the fileSnapshots or outputFileStates? Have done this a limited number of times, but has always resolved the issue. Would adding a delete on this directory be suitable for a temporary workaround, what implications would this have - tasks not detecting whether they are up to date or not?
|Comment by Adam Murdoch [ 03/Jul/11 ]
Yes, that's one implication. Also, everything will be much slower, as Gradle will need to recompile the build scripts, calculate file hashes, and a bunch of other things.
A much better workaround is to use -g to give each CI build a separate home directory.
|Comment by Detelin Yordanov [ 06/Jul/11 ]
What about removing just the task history cache of each project, e.g. project.rootDir/.gradle/VERSION/taskArtifacts ? If no task execution is referencing the files snapshot cache, there should not be a problem, right? If this works, build should not get that slower since build script cache would be preserved?
|Comment by Vincent Partington [ 27/Jul/11 ]
Getting the same error building with Gradle 1.0-milestone-3 from Jenkins 1.411 on Linux.
|Comment by René Gröschke (Inactive) [ 06/Sep/11 ]
Those of you manipulating the gradle cache manually, should avoid this, as 1. this is not explicitly supported and 2. will not work the way as mentioned here with versions >= 1.0-milestone-4 because paths in the cache had changed and now contain checksums, etc.
running gradle milestone-3 on macosx 10.6 and winxp works fine for us with jenkins. In prior versions we used the combination "-g . -C rebuild" if nothing else worked.