[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: |
|
||||||||
| 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 Run: ./gradlew.bat --daemon clean build $ ./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:
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. |