Bug: Gradle daemon keeps open file handle to project jar (after running gradle.lint) making it impossible to clean

[devminded]

This might be a bug with the plugin or a bug in Gradle. I have not seen this issue often before I started using the gradle.lint plugin.

Environment

• OS: Win10 Pro x64
• Gradle: 3.4
• Java: 7 x64

How to reproduce (using multimodule gradle build):

C:\dev\example> gradle build C:\dev\example> gradle clean

Result:

What went wrong: Execution failed for task ':example-sub:clean'. Unable to delete file: C:\dev\example\sub\build\libs\example-sub-1.0.0-SNAPSHOT.jar

Workaround:

C:\dev\example> gradle --stop C:\dev\example> gradle clean

[DanielThomas]

I recently fixed an unclosed input stream bug (https://github.com/nebula-plugins/gradle-lint-plugin/releases/tag/v7.2.3). What version of the plugin are you using?

[devminded]

Tried with 7.3.1 and 7.3.5.

I can dig into it more later when I have the time.

[devminded]

Made some thread dumps, captured some Gradle logs and file handle logs.

console.txt gradle-pid-5288.log.txt filehandledump-pid-8320-5288.txt threaddump-1491592589794.tdump.txt

[gituser2202]

Any update on this issue?

[DanielThomas]

@gituser2202 what version of the plugin are you using? I've checked the classes that open jars and they're all seem to be using {{withClosable}} and I wouldn't expect dangling file handles.

Edit: Which rules you have enabled would also be helpful. If you could also bisect the rules to figure out which one, that'd be a huge help, because our Windows usage is all WSL2.

[gituser2202]

'nebula.lint' version '16.0.2' did not specifically enable a rule. Does that mean its "all-rules" by default? Can you also help me how can I specify a rule to find which one is causing the issue?

[DanielThomas]

The lint rules are defined here - https://github.com/nebula-plugins/gradle-lint-plugin/tree/master/src/main/resources/META-INF/lint-rules

I assume you're configuring {{all-dependency}} so you can configure each of those rules individually and see which one causes the leak.

[gituser2202]

ran with all the configurations looks like commenting out both 'undeclared-dependency' and 'unused-dependency' helps not getting locked out on the child project jar file.

[
 'all-nebula-renames',
 'bypassed-forces',
 'deprecated-task-operator',
 'duplicate-dependency-class',
 'minimum-dependency-version',
 'multiproject-circular-dependency',
 'recommended-versions',
 'rename-nebula-clojure',
 'rename-nebula-deb',
 'rename-nebula-dependency-lock',
 'rename-nebula-facet',
 'rename-nebula-git-scm',
 'rename-nebula-info-ci',
 'rename-nebula-info',
 'rename-nebula-integtest',
 'rename-nebula-javadoc-jar',
 'rename-nebula-ospackage-application-daemon',
 'rename-nebula-ospackage-application',
 'rename-nebula-ospackage',
 'rename-nebula-override',
 'rename-nebula-release',
 'rename-nebula-source-jar',
 'rename-nebula-stash',
 'transitive-duplicate-dependency-class',
 **//'undeclared-dependency',
 // 'unused-dependency',**
 'unused-exclude-by-conf',
 'unused-exclude-by-dep'
 ]

If it helps My initial setup was {all-dependency} and I was consuming the subproject by having implementation project(':subproject') in the root project build.gradle and the linter was failing my build with the below error

error     unused-dependency one or more classes in rootproject:subproject:version are required by your code directly (no auto-fix available)

error     undeclared-dependency one or more classes in rootproject:subproject:version  are required by your code directly

To fix this I changed it from implementation project(':subproject') to **compile project(':subproject')
** and the build was successful but then comes this lock issue just while cleaning. But I am able to rebuild with out any issues.