The gradle daemon prevents a clean


(Jesper Thuun-Petersen) #1

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.


(Peter Niederwieser) #2

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’.


(Attila Kelemen) #3

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).


(Luke Daley) #4

Hi Attila,

What is conime?


(Luke Daley) #5

@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?


(Attila Kelemen) #6

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.


(Jesper Thuun-Petersen) #7

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.


(Luke Daley) #8

@Jesper: I don’t suppose this is a build I can access and play with?


(Jesper Thuun-Petersen) #9

@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?


(Luke Daley) #10

@Jesper: that’s worth a try.

It’s luke.daley at http://gradleware.com


(Jesper Thuun-Petersen) #11

Here’s the gradle files I mentioned.

Main build: https://gist.github.com/anonymous/dd53ece6a47bb6d96e96 Framework: https://gist.github.com/anonymous/29135474ccbbd795c29e


(Luke Daley) #12

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?


(Jesper Thuun-Petersen) #13

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.


(Luke Daley) #14

It was worth a shot. I’ll have to take a deeper look to find what is using the jar file.