When I run a gradle clean I get this:
FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':framework:clean'. > Unable to delete file: E:\code\trunk\stepx\framework\build\libs\framework-1.0-SNAPSHOT.jar * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. BUILD FAILED Total time: 23.391 secs
When I kill the gradle daemon java process, the problem goes away.
We are aware that this still sometimes happens on Windows, and are working on improving it bit by bit. Meanwhile, the best way to deal with this error is to stop the currently running daemon with ‘gradle --stop’.
I relatively often (a lot more than none at least:)) encounter failure in the ‘clean’ task. To be fair, usually the problem is that conime.exe does not allow to remove a directory (but files can be deleted). Since Gradle cannot do anything about conime, could there be an option (or maybe the default behaviour) in Gradle so that clean does not fail if it cannot remove an empty directory?
EDIT: By empty directory, I mean that it does not contain files, only directories (recursively).
Hi Attila,
What is conime?
@Jesper: I can’t think why Gradle would be holding a reference to this Jar. Is there anything special about this jar? How is it used in the build?
I’m not sure but it somehow helps the console with chinese and japanese (etc.) characters (at least this is what I read). I don’t use them but Windows often starts conime anyway for some reason.
No, it’s not special, even though it’s the only one of our modules in a multimodule setup that does not depend on other modules. It hereby follows that it’s the first module build, whether we clean or assemble, or what not.
@Jesper: I don’t suppose this is a build I can access and play with?
@Luke, I’m sorry, but it’s a pretty large project with > 100 modules, and the code is not public. I can send you the global buildfile and the framework file though, if that’s any good for you?
@Jesper: that’s worth a try.
It’s luke.daley at http://gradleware.com
Here’s the gradle files I mentioned.
Main build: https://gist.github.com/anonymous/dd53ece6a47bb6d96e96 Framework: https://gist.github.com/anonymous/29135474ccbbd795c29e
On a quick glance, I suspect the JRebel plugin holding this jar open. Would this jar be used by the jrebel plugin in any way?
I’ve since removed my jrebel plugin, even though I don’t see any connection between this plugin and my local files. I’ve just experienced a lock-problem with the same jar file, so unfortunately that was not the explanation.
It was worth a shot. I’ll have to take a deeper look to find what is using the jar file.