On 4 Apr 2014, at 12:01 am, Radim Kubacki <radim.kuba...@gradleware.com> wrote:
> On Thu, Apr 3, 2014 at 12:36 PM, Szczepan Faber > <szczepan.fa...@gradleware.com> wrote: > Hey, > > How do we avoid sleeps in incremental compilation integ tests? My initial > batch of integ tests for java incremental compilation uses Thread.sleep and > file.lastModified to verify which files were actually recompiled. It seems > tricky to avoid the sleep. If I use file hash/size instead of lastModified it > does not work for cases where recompiled class is the same as the original > one. Another option would be to introduce some api/listener that gets > notified just before the compilation and receives the information about > requested source to compile. > > Do you mean that the file is recompiled and identical? Same md5sum? > > Perhaps we could use filesystem listener when running with Java7 but this > seems too big restriction as we want to test with older platform too. But > there can be backports if this inotify libraries. It is an option. The problem with filesystem listeners in general is that they are asynchronous, which means we have to wait in the test for all the events to be delivered. This is fine when checking for files that should be changed, but awkward when checking for files that should not be changed because we don’t know when we’ve received all the events for a given build. A similar, but synchronous, option would be to use the file’s inode to decide if the file has been recreated (in combination with logging). We can easily add this to native-platform. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com Join us for Gradle Summit 2014, June 12th and 13th in Santa Clara, CA: http://www.gradlesummit.com
