All GSP files are treated as new files after startup in development mode and will stop reloading agent from finding real changes (only happening in windows environments). If there are 100 GSP files, the reloading agent finds the first "real" change after 500 seconds, which is a blocker on windows machines.
On windows environment do:
1. create-app testApp
2. create-plugin testPlugin
3. Add the plugin testPlugin to testApp by adding the following line the BuildConfig.groovy of testApp.
grails.plugin.location.'testPlugin' = "../testPlugin"
4. create-controller testController in testApp.
5. change log level of
to INFO in testApp.
6. start grails interactive from within testApp
7. do "run-app"
8. wait 10 seconds.
9. after that error.gsp is treated as "new file"
INFO compiler.GrailsProjectWatcher - File [C:\a\testPlugin\grails-app\views\error.gsp] added. Applying changes to application.
(grails is doing that for ALL plugin-GSP files)
10. if the plugin has 100 gsp files, this takes 100*5 seconds until any other change is taken, because he is busy "adding" existing GSPs to the project.
This behaviour is only seen in windows environments. The same app starting in linux is NOT producing those "new file"-signal.
The reason for this is in line 172 of DirectoryWatcher.java. In linux environments the same behaviour is happening: since all GSP files are not in the lastModifiedMap in the initialization phase (because, the "*" in extensions is added AFTER the view folders have been initialized) in linux they are added AFTER the application is started, however they are ignored because windows == false (see source code).
So there is a bug here:
- GSP files are not initializied in the lastModifiedMap. (this could only happen if the order of the PluginSourceFolders is different ...)
I dont know why the extension array is maintained, since once "*" is added, every file will be observed.