[GRADLE-1472] java.lang.ClassCastException FileCollectionSnapshotImpl cannot be cast to OutputFilesSnapshot Created: 13/Apr/11  Updated: 04/Jan/13  Resolved: 16/Aug/11

Status: Resolved
Project: Gradle
Affects Version/s: 1.0-milestone-2
Fix Version/s: 1.0-milestone-5

Type: Bug
Reporter: Ildiko Varga Robey Assignee: Adam Murdoch
Resolution: Fixed Votes: 3

Issue Links:
Duplicates GRADLE-1924 Build fails Resolved
Duplicated by GRADLE-1735 ClassCastException: DefaultFileSnapsh... Resolved
Duplicated by GRADLE-1166 Corrupted cache exception Resolved


FAILURE: Build aborted because of an internal error.

  • What went wrong:
    Build aborted because of an unexpected internal error. Please file an issue at: http://www.gradle.org.
  • Try:
    Run with --debug option to get additional debug info.
  • Exception is:
    java.lang.ClassCastException: org.gradle.api.internal.changedetection.DefaultFileSnapshotter$FileCollectionSnapshotImpl cannot be cast to org.gradle.api.internal.changedetection.OutputFilesSnapshotter$OutputFilesSnapshot
    at org.gradle.api.internal.changedetection.OutputFilesSnapshotter$OutputFilesSnapshot.changesSince(OutputFilesSnapshotter.java:96)
    at org.gradle.api.internal.changedetection.OutputFilesChangedUpToDateRule$1.checkUpToDate(OutputFilesChangedUpToDateRule.java:43)
    at org.gradle.api.internal.changedetection.CompositeUpToDateRule$1.checkUpToDate(CompositeUpToDateRule.java:41)
    at org.gradle.api.internal.changedetection.DefaultTaskArtifactStateRepository$HistoricExecution.isUpToDate(DefaultTaskArtifactStateRepository.java:122)
    at org.gradle.api.internal.changedetection.DefaultTaskArtifactStateRepository$TaskArtifactStateImpl.isUpToDate(DefaultTaskArtifactStateRepository.java:154)
    at org.gradle.api.internal.changedetection.ShortCircuitTaskArtifactStateRepository$1.isUpToDate(ShortCircuitTaskArtifactStateRepository.java:35)
    at org.gradle.api.internal.changedetection.FileCacheBroadcastTaskArtifactStateRepository$1.isUpToDate(FileCacheBroadcastTaskArtifactStateRepository.java:37)
    at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:44)
    at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:57)
    at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:41)
    at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:51)
    at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:52)
    at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:42)
    at org.gradle.api.internal.AbstractTask.execute(AbstractTask.java:237)
    at org.gradle.execution.DefaultTaskGraphExecuter.executeTask(DefaultTaskGraphExecuter.java:167)
    at org.gradle.execution.DefaultTaskGraphExecuter.doExecute(DefaultTaskGraphExecuter.java:160)
    at org.gradle.execution.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:78)
    at org.gradle.execution.TaskNameResolvingBuildExecuter.execute(TaskNameResolvingBuildExecuter.java:113)
    at org.gradle.execution.DelegatingBuildExecuter.execute(DelegatingBuildExecuter.java:54)
    at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:153)
    at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:107)
    at org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:75)
    at org.gradle.launcher.RunBuildAction.execute(RunBuildAction.java:41)
    at org.gradle.launcher.RunBuildAction.execute(RunBuildAction.java:27)
    at org.gradle.launcher.CommandLineActionFactory$WithLoggingAction.execute(CommandLineActionFactory.java:209)
    at org.gradle.launcher.CommandLineActionFactory$WithLoggingAction.execute(CommandLineActionFactory.java:193)
    at org.gradle.launcher.Main.execute(Main.java:55)
    at org.gradle.launcher.Main.main(Main.java:40)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.gradle.launcher.ProcessBootstrap.runNoExit(ProcessBootstrap.java:46)
    at org.gradle.launcher.ProcessBootstrap.run(ProcessBootstrap.java:28)
    at org.gradle.launcher.GradleMain.main(GradleMain.java:24)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.gradle.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:33)
    at org.gradle.wrapper.Wrapper.execute(Wrapper.java:51)
    at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:37)

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 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?


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.

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