Have you recently updated the gradle version on your hudson? did tried to delete the .gradle in your home directory and cleanup the workspace?
–
René
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!
Ildi
René,
Just delete the .gradle folder in the user's home directory? It's OK to leave the one in the project root directory?
What do you mean by "cleanup the workspace"?
What's the purpose of the delete/clean-up? Are there known upgrade issues that I just overlooked?
Thanks,
Jamie
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....
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.
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 
A more reliable workaround is to use the -g option to give each Jenkins build a separate home directory.
Yes. But can we expect to see this fixed in the near future? Thanks!
Yes. We're just about to finish Gradle 1.0-milestone-4. We'll fix this issue in the release after that.
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?
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.
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?
Getting the same error building with Gradle 1.0-milestone-3 from Jenkins 1.411 on Linux.
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.