Hi Derek,
The mentioned build system does sound like a difficult use-case to integrate with JRebel due to a few reasons.
Firstly JRebel uses filesystem notifications extensively to check which files/frameworks to reload. If a file changes, only the original path(hardlink) will be mentioned so using a symlink to point to a current directory will not have the changes picked up this way.
It’s possible to disable this plugin and fall back to classpath scanning, however a lot of frameworks resolve the symlinks once on startup so we would need to ensure this resolution happens lazily everywhere, however this can in return cause performance issues.
It is possible to add new classpath URLs to classloaders and JRebel will do re-initialization, for example URLClassLoader#addURL. If something adds a new path after the build, the changed classes should be picked up. So one theoretical option is to write a classloader that scans(or gets external input, e.g. MBean call) for the ‘current’ symlink and registers a new path if the symlink changed.
Considering all these problem points and possible hidden caveats, it’s best to have some script running which continuously updates a fixed classes folder that JRebel will monitor.
For example the script can check if any symlink changed and copy classes over to this flat classpath. As JRebel will do hash checks for classes before reloading, a simple copy that doesn’t maintain timestamps should even work fine and not cause extra reloads for classes that didn’t actually change.
Let us know if any of these sound like a suitable option.