2009/5/1 Steve Appling <[email protected]> > > > Steve Appling wrote: > >> >> >> Tom Eyckmans wrote: >> >>> >>> Steve if you want to perform a test there is a ChangeDetecter main >>> class that you can modify for testing in the >>> org.gradle.api.changedetection package. >>> >>> I hope you all like it, I think it is the very efficient and because >>> of that rather complex code so I'll add some documentation to it in >>> the coming days. >>> >>> >> Great, I'll try to play with this some this afternoon. >> >> FYI - it wouldn't compile as is in your branch for me. I had to add >> "commons-codec:commons-codec:1...@jar" to the compile configuration to get >> it to build. >> >> Thansk for this feedback!
> > I had to make a few changes to get it working on Windows. I put my changes > at git://github.com/sappling/tgradle.git. I didn't test all of these, so > please review them: > > 1) I couldn't get it to compile without adding the commons-codec jar to the > compile configuration. I forgot to add it to the build. > > 2) There are a lot of places where you are doing String.replaceAll( > somePath ... > Under Windows, somePath will result in a path with "\" characters which are > interpreted as escapes in the regular expression replaceAll is expecting. > I > escaped these with Pattern.quote. > > 3) In a couple of places , you are calculating file names to hold the > hashed values by using the path to the watched directory and replacing the > file.separator character with an "_". This isn't sufficient for windows > because you also get the ":" character as a part of the path after the drive > letter. Where you are doing this I changed the regexp to replace the : as > well. > Indeed I didn't think of windows while developing this code, sorry for this. > > I think that I might personally like some other way of coming up with this > file name - perhaps just hashing the path and using the hash for a name. I like this idea and is certainly a more platform independent way. I'll use the relative path of the directories as base for the hash so it doesn't screw up if the directory is moved. > > > 4) I created an AnyChangeProcessor class (trivial implementation of your > ChangeProcessor) to use to enable/disable my tasks. > > With these changes, it seems to work great! I tried it on some simple > sample projects that I was using to test my Copy task and it will do the > test of about 15,000 source files to see if anything changed in about 5 > seconds (disabling a copy that takes 35 seconds even if there is nothing > changed). I'll try some more timing tests under different circumstances > later. > Nice, thanks for the speed testing. > > I'll look at adding something to Task over the weekend to allow easier use > of this. I was thinking about Task.dependsOnDir(dirToWatch). I'm going to put an event queue between the old/new state detection and the calls to the ChangeProcessor, so implementations of ChangeProcessor can get called in a single threaded or multithreaded way. So a copy or your sync task can only perform actions for the files / directories that have changed. > > > > > > -- > Steve Appling > Automated Logic Research Team > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
