Random failures with Gradle delete, processResources or compile when doing incremental builds


(Abhishek Nath) #1

We are slowly rolling out Gradle in our enterprise and many devs with Macs are reporting random build failures specially during delete, processResources or compile. Errors are generally unable to delete file/folder or unable to copy files in build dirs. On investigation, looks like tasks are failing as these files somehow are marked with permission r–r--r-- (444) or r-x------ (500).

Are there any such reports and is a known issue. Devs use Intellij/Eclipse and share same build dir with Gradle. Is it possible IDEs are locking these files. Any lead will be great help.


(Peter Niederwieser) #2

I haven’t heard of any such issues. How are the problematic files created? Do you use the Gradle Daemon, and if yes, have you tried without it (’–no-daemon’)?


(Peter Niederwieser) #3

I should add that sharing build dir between Gradle and IDE is discouraged. You don’t want two different tools/processes/compilers that aren’t aware of each other partially overwriting each other’s files without any coordination. This is likely to cause stability issues, and unlikely to have any advantages.


(Abhishek Nath) #4

Yes, we have daemon enabled on Mac. I will try disabling it.

I think its gradlew idea or gradlew eclipse which sets this same output dir as build dir. Are you saying we should override default behavior? Only advantage with same dirs is when dev is using jrebel and we want build system to support this.


(Peter Niederwieser) #5

Gradle’s IDE plugins intentionally do not do this, unless you reconfigured them.


(Peter Niederwieser) #6

I don’t understand the jRebel argument. Can you elaborate?


(Abhishek Nath) #7

Idea is to provide seamless build experience to devs when they are using jRebel.

We have split of devs using IntelliJ and Eclipse. IntelliJ devs use it full blown and expect - once they make change in IntelliJ and make project, change will be immediately picked by JRebel.

Then we have Eclipse community who use it mostly as editor and use command line for most of their build needs. They also expect their changes picked by JRebel immediately after they do incremental compile from Gradle command line.

Sharing same build directories (only source - build/classes/main) provide this experience.


(Peter Niederwieser) #8

If I understand you correctly, IntelliJ users don’t really need to share an output directory with Gradle because they are happy to compile in IntelliJ. But Eclipse users prefer to compile with Gradle, and nevertheless expect to see changes in the JRebel enabled application started via Eclipse?


(Abhishek Nath) #9

Starting of app is from Gradle - gradlew start-tomcat. Essentially, its all about which directories should jRebel monitor. What we dont want is extra configuration that each dev has to do based on what IDE he is using.

Right now only directory we share with IDEs is build/classes/main and nothing more. Our resources also go in the same directory. It has worked reasonably well except the reported file permission issue.

If you strongly feel we should not do this, we might have to come up with alternate strategy.


(Peter Niederwieser) #10

I do think there are better options. For example, you could provide two ways to run the web app: From the Gradle build dir, or from the IDE build dir. I’d expect reloading to be faster when compiling in the IDE, because IDEs do incremental Java compilation, whereas Gradle doesn’t. This might also affect the number of classes that JRebel has to reload (not sure).

Anyway, to solve your original problem you’ll first have to figure out the cause - Gradle daemon, sharing of build dir, or something else. Then we can think about ways to solve the problem.