Gradle script cache related IllegalAccessErrors after upgrading from 2.8->2.11

(Michael Ahern) #1


Since we upgraded from Gradle 2.8 to 2.11 we have been experience recurrent issues related to .lock files in the gradle script cache. The error is as follows:

Caused by: org.gradle.cache.CacheOpenException: Could not open cp_dsl class cache for script '/home/****/workspace/sc-main-application-development/planmanagement-incremental-build/rtcSource/PlanManagement/PlanManagement/BuildTools/mixins/std_component_multi_db_zip_2.gradle' (/home/****/.gradle/caches/2.11/scripts/std_component_multi_db_zip_2_18wavz83az9qwcm6oo1sgc4br/cp_dsl).
	at org.gradle.cache.internal.DefaultCacheFactory.doOpen(
	at org.gradle.cache.internal.DefaultCacheRepository$PersistentCacheBuilder.doOpen(
	at org.gradle.cache.internal.DefaultCacheRepository$
	at org.gradle.groovy.scripts.internal.FileCacheBackedScriptClassCompiler.compile(
	at org.gradle.groovy.scripts.internal.ShortCircuitEmptyScriptCompiler.compile(
	at org.gradle.groovy.scripts.internal.CachingScriptClassCompiler.compile(
	at org.gradle.groovy.scripts.DefaultScriptCompilerFactory$ScriptCompilerImpl.compile(
	at org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl.apply(
	at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.applyScript(
	at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.access$000(
	at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction$
	at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.execute(
	at org.gradle.api.internal.project.AbstractPluginAware.apply(
	at org.gradle.api.plugins.PluginAware$ Source)
	at org.gradle.api.internal.project.ProjectScript.apply(ProjectScript.groovy:35)
	at org.gradle.api.Script$apply$1.callCurrent(Unknown Source)
	at org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$
	... 109 more
Caused by: java.lang.IllegalAccessError: tried to access method from class
	at org.gradle.util.GFileUtils.forceDelete(
	at org.gradle.cache.internal.DefaultPersistentDirectoryCache$Initializer.initialize(
	at org.gradle.cache.internal.DefaultCacheAccess$
	at org.gradle.cache.internal.DefaultFileLockManager$DefaultFileLock.doWriteAction(
	at org.gradle.cache.internal.DefaultFileLockManager$DefaultFileLock.writeFile(
	... 129 more 

The suggestions from earlier threads was deleting the .lock files in the script cache. This does fix the problem, for a time however the issue continues to come back. We see the issue occur for both developers on Window & Linux, so the problem is not platform dependent. We use a variant of Sun JDK 1.7 in both cases. Prior to upgrading to 2.11 we had no such issues.

One interesting behavior is that I am able to reproduce the problem by running a with the ‘–concurrent’ flag. This is a multi-project build where a common .gradle file is included into a number of subprojects.

To get past this, we have since downgraded back to 2.8 which has resolved the issues. Any thoughts on a more permanent fix? Could there be something about our environment that could cause the issue?

IllegalAccessErrors: "...FilenameUtils.isSystemWindows()Z from class"
(Lari Hotari) #2

I assume it’s caused by a common-io version conflict within the plugins used in your build. commons-io was upgraded from 1.4 to 2.2 in Gradle 2.10.

You should be able to get around the problem by adding a buildscript dependency to commons-io:

buildscript {
    dependencies {
        classpath "commons-io:commons-io:2.2"

After that you can analyze the build script dependencies with the built-in buildEnvironment task (since Gradle 2.10) to find the reason of the conflict.

(Michael Ahern) #3

Many thanks - I can see Artifactory is pulling in another version of commons-io.

org.jfrog.buildinfo:build-info-extractor-gradle:3.+ -> 3.1.1
| ±-- commons-io:commons-io:2.0.1

Looks like even the newer versions of this plugin (4.0.0) have the same issue. I’ll file a defect with those guys once we can string together a few days of clean builds.

(Lari Hotari) #4

Thanks for investigating the problem. Yes, seems that it depends on commons-io 2.0.1. There is an issue tracker on the project’s Github page, so I assume you could file the request to update to commons-io 2.2 there.

(Michael Ahern) #5

I am not sure how often that is checked. They have JIRA on their project site:

I’ll file a defect there once I fully confirm the issue.

(Michael Ahern) #6

I have confirmed the buildscript {} solution works.

This is being tracked in the Artifactory JIRA system here:
For anyone seeing the same issue.