I didn't respond to Scott's initial comments: > - My gut reaction is that it's odd to make it a command-line option. It's not > really a user-facing 'option' in the same way that draftCompile or > style=PRETTY > is, it's just an internal implementation detail. It would seem more like a > jvm > flag, and perhaps later just always on.
Toby, Jason and I had planned to put all of these dev mode changes behind a -X command line flag, but I went ahead and took out the command line flag and made it a system property because it simplified the API (enabled boolean flag in static api) > - Same with having to encode the persistence dir into every single entry > point. > Throwing it into WEB-INF in dev mode seems weird, and there's no fundamental > reason dev mode and the compiler shouldn't share a unit cache anyway. How > about > just using / creating a well-known directory under the current directory? If > you fail to create the directory (permission problem) then you don't use the > disk. First, I want to let you know I put a lot of thought into where to put the cache files and after discussions with Toby, we came up with the WEB-INF solution. There is precedent for putting the cache type files in WEB-INF (app engine integration with GWT does this). Also, its a terrific place when you consider that with our GWT ant setup, the cache gets removed when you run 'ant clean'. I've updated the Compiler entry point to also use the war/WEB-INF dir so the cache can be shared with web mode. The problem with using the current working directory is that potentially we are going to splatter cache directories all over the disk, and no user is going to thank us for that. Also, where would we tell users to clean things up? How could they write a reliable clean target? The problem with a 'well known' place, like /tmp/gwt-unitCache is that in a shared environment, that cache is not just going to be shared between compiles (what we want), it is going to be shared between different users on the same machine, and I'm pretty sure we don't want that. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
