[GRADLE-3315] Gradle daemon holds lock on jar file on Windows when using TestNG Created: 01/Jul/15  Updated: 24/Jan/17  Resolved: 24/Jan/17

Status: Resolved
Project: Gradle
Affects Version/s: 2.4
Fix Version/s: None

Type: Bug
Reporter: Mark Vieira (Inactive) Assignee: Unassigned
Resolution: Won't Fix Votes: 3

Issue Links:
Related
Related to GRADLE-2275 Clean can fail on windows when using ... Resolved

 Description   

When using the Gradle daemon and the excludeCategories or includeCategories JUnitOptions, dependent jars are locked by the daemon process and you cannot delete them.

I have provided an example project at https://github.com/redcape/gradle-example/tree/junit-error
Please make sure you're looking at the junit-error branch if you download this project. Note that there is no code in the 'projectdep' dependency project, yet its jar still gets locked. Additionally, tests are not even running. It is important that Gradle tries to run a test though meaning that there is source code in the directory or else the condition will not occur.

Run: ./gradlew.bat --daemon clean build
The project will successfully clean and build.
Run it again and it will fail with:

$ ./gradlew.bat --daemon clean check
:projecta:clean
:projectdep:clean FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':projectdep:clean'.
> Unable to delete file: T:\code\show-errors\gradle-example\projectdep\build\libs\projectdep.jar

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Running ./gradlew.bat --stop followed by ./gradlew.bat clean build or ./gradlew.bat --daemon clean build will run fine.

If the daemon is not running, no clean errors will occur.

Commenting out either the project dependency line or the JUnit excludeCategories line and restarting the daemon(if it's already holding a reference) will make the problem go away.

I tested this against Gradle 2.4 on IBM Java 6 (32-bit) and Oracle Java 8(64-bit) on Windows 7 32-bit and 64-bit respectively. They both have the same result.

I also tested this on the gradle master branch built from source on Oracle Java 8 and had the same issue.



 Comments   
Comment by Gil Cottle [ 01/Jul/15 ]

The proper URL for the example project: https://github.com/redcape/gradle-example/tree/junit-error

Comment by Will Boyd [ 03/Feb/16 ]

I am seeing this happen on our bamboo server as well (CentOS)

Comment by Pepper Lebeck-Jobe [ 05/May/16 ]

Relevant discussion on StackOverflow. http://stackoverflow.com/questions/11273303/java-classloader-dilemma-with-locked-jars

Comment by Michael Barnathan (Inactive) [ 12/May/16 ]

Similar issue: loading classpath and not letting it go until the JVM exits.

Comment by Lari Hotari [ 31/May/16 ]

This change might fix the problem specific to JUnit Include/Exclude categories: https://github.com/gradle/gradle/commit/1a5cf52c .

Comment by Lari Hotari [ 31/May/16 ]

The TestNG support might have a similar problem as there was with JUnit Include/Exclude categories since it's also using a cached classloader for checking for features supported by the used TestNG version.

Comment by Michael Barnathan (Inactive) [ 02/Jun/16 ]

Sounds like this use case was fixed and will be rolled out in the next release, but TestNG stil suffers from the problem.

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Pepper Lebeck-Jobe [ 18/Nov/16 ]

As far as I know, this is still an issue affecting our TestNG users. @Mark Vieira can you confirm?

Comment by Mark Vieira (Inactive) [ 19/Nov/16 ]

I believe this was originally reported by someone on the forums. I don't have any insight here beyond what's in the JIRA. We can certainly try to reproduce with the sample project again.

Generated at Wed Jun 30 12:45:34 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.