FileUtil.addRecursiveListener(..., new File(System.getProperty("user.home"), ".m2/repository")) does work to report all changes to the local repository. However logging indicates that this first creates a FileObject for _every file and folder_ under that root, even though the IDE need never examine most of these dirs otherwise. See bug #190675 comment #7.
This major overhead is not apparent from the API, and does not seem intrinsically required; it is rather an artifact of the poor communication between openide.filesystems and masterfs: DeepListener (and/or RecursiveListener?) are written to assume that the FS impl can only be asked to watch existing FO's. A proper implementation would pass along the aRL call directly to masterfs's Notifier, which would then add its watch or watches in a platform-dependent manner (possibly requiring a recursive traversal of java.io.File's, possibly not).
If and when an event occurs somewhere within the tree, a FileEvent may be fired. Without making any API change, this could just create the FO for the event source & file (plus intermediate folders) when the FileEvent is constructed, or on demand when the relevant getters are called on it. Even better would be a FileEvent constructor and getter using URL rather than FileObject, where getFile() would call URLMapper.findFileObject; then clients which are only interested in the location of the changed file could receive events without forcing a FO subtree to be created.
If all FileObjects (including folders and files) are kept in memory, then it is a bug. However first you have to proove it.
I believe that only FileObjects representing folders are held. That is by design, seems to be needed and there are no plans to eliminate that.
Besides transient allocation, still results in several thousand FolderObj's being held in memory, which seems like considerable overhead.