This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Having the following scenerio: prj -build -gen-classes -org/netbeans/api/java/project/Bundle.java -org/netbeans/modules/java/project/ui/Bundle.java The recursive listener is attached to gen-classes folder which has 2 files created in it. The clean deletes the build folder. Only single file event is delivered (randomly for either org/netbeans/api/java/project/Bundle.java or org/netbeans/modules/java/project/ui/Bundle.java). The native listener OSXWatcher correctly delivered event about change in build: FINE [org.netbeans.modules.masterfs.watcher.OSXNotifier]: Event on /Users/tom/Projects/netbeans/test/java.project/build/classes-generated/org/netbeans/modules/java/project/ 0 FINE [org.netbeans.modules.masterfs.watcher.OSXNotifier]: Event on /Users/tom/Projects/netbeans/test/java.project/build/classes-generated/org/netbeans/spi/java/project/support/ui/ 0
Also the following change was delivered: FINE [org.netbeans.modules.masterfs.watcher.OSXNotifier]: Event on /Users/tom/Projects/netbeans/test/java.project/ 0
I've looked into doc and according to it it may happen that only the /Users/tom/Projects/netbeans/test/java.project/ can be delivered for delete.
As far as I can tell, the API asked you to listen on some/folder/path via addWatch method, so it is reasonable to expect that if there was some change, you will deliver change for some/folder/path and not for some/ or some/folder/, right? If you are able to detect this case, then you can deliver ALL_CHANGE. If you are unable to detect this kind of event collapsing, then I guess we are out of luck. Anyway the fix needs to be done primarily in OSXNotifier, which is your creation, so passing back to you, Tomáši.
I can do it in OSXNotifier. Originally I did it but Nejedlak remove the filtering due to performance reasons. As far as I remember the reason was that FS does the same in more efficient way.