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

Help/Discuss
1

Hi,

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.DefaultPersistentDirectoryStore.open(DefaultPersistentDirectoryStore.java:48)
	at org.gradle.cache.internal.DefaultPersistentDirectoryStore.open(DefaultPersistentDirectoryStore.java:28)
	at org.gradle.cache.internal.DefaultCacheFactory.doOpen(DefaultCacheFactory.java:80)
	at org.gradle.cache.internal.DefaultCacheFactory.open(DefaultCacheFactory.java:50)
	at org.gradle.cache.internal.DefaultCacheRepository$PersistentCacheBuilder.doOpen(DefaultCacheRepository.java:138)
	at org.gradle.cache.internal.DefaultCacheRepository$AbstractCacheBuilder.open(DefaultCacheRepository.java:121)
	at org.gradle.groovy.scripts.internal.FileCacheBackedScriptClassCompiler.compile(FileCacheBackedScriptClassCompiler.java:63)
	at org.gradle.groovy.scripts.internal.ShortCircuitEmptyScriptCompiler.compile(ShortCircuitEmptyScriptCompiler.java:60)
	at org.gradle.groovy.scripts.internal.CachingScriptClassCompiler.compile(CachingScriptClassCompiler.java:41)
	at org.gradle.groovy.scripts.DefaultScriptCompilerFactory$ScriptCompilerImpl.compile(DefaultScriptCompilerFactory.java:50)
	at org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl.apply(DefaultScriptPluginFactory.java:127)
	at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.applyScript(DefaultObjectConfigurationAction.java:101)
	at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.access$000(DefaultObjectConfigurationAction.java:35)
	at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction$1.run(DefaultObjectConfigurationAction.java:61)
	at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.execute(DefaultObjectConfigurationAction.java:135)
	at org.gradle.api.internal.project.AbstractPluginAware.apply(AbstractPluginAware.java:46)
	at org.gradle.api.plugins.PluginAware$apply.call(Unknown Source)
	at org.gradle.api.internal.project.ProjectScript.apply(ProjectScript.groovy:35)
	at org.gradle.api.Script$apply$1.callCurrent(Unknown Source)
	at build_96pb0ru4qng1svvzapb9ueqrp.run(/home/****/workspace/sc-main-application-development/planmanagement-incremental-build/rtcSource/PlanManagement/PlanManagement/EJBServer/components/CTMInfrastructure/build.gradle:10)
	at org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:91)
	... 109 more
Caused by: java.lang.IllegalAccessError: tried to access method org.apache.commons.io.FilenameUtils.isSystemWindows()Z from class org.apache.commons.io.FileUtils
	at org.apache.commons.io.FileUtils.isSymlink(FileUtils.java:2667)
	at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1464)
	at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2097)
	at org.gradle.util.GFileUtils.forceDelete(GFileUtils.java:206)
	at org.gradle.cache.internal.DefaultPersistentDirectoryCache$Initializer.initialize(DefaultPersistentDirectoryCache.java:93)
	at org.gradle.cache.internal.DefaultCacheAccess$2.run(DefaultCacheAccess.java:104)
	at org.gradle.cache.internal.DefaultFileLockManager$DefaultFileLock.doWriteAction(DefaultFileLockManager.java:173)
	at org.gradle.cache.internal.DefaultFileLockManager$DefaultFileLock.writeFile(DefaultFileLockManager.java:163)
	at org.gradle.cache.internal.DefaultCacheAccess.open(DefaultCacheAccess.java:102)
	at org.gradle.cache.internal.DefaultPersistentDirectoryStore.open(DefaultPersistentDirectoryStore.java:46)
	... 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?

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.

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.

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.

5

I am not sure how often that is checked. They have JIRA on their project site:
https://www.jfrog.com/jira/browse/GAP#selectedTab=com.atlassian.jira.plugin.system.project%3Aissues-panel

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

6

I have confirmed the buildscript {} solution works.

This is being tracked in the Artifactory JIRA system here:
https://www.jfrog.com/jira/browse/GAP-250
For anyone seeing the same issue.