Groovy scripts are not on the classpath in the normal sense, but are loaded (and I guess compiled) at runtime from the script's .groovy file.
This is handled in the GroovyEngine#serviceInvoker where you'll see a line similar to:
Script script = InvokerHelper.createScript(GroovyUtil.getScriptClassFromLocation(this.getLocation(modelService)), GroovyUtil.getBinding(gContext));
By following the above call to GroovyUtil.getScriptClassFromLocation, it looks like the script is read from the .groovy file each time the groovy service is invoked, and added to the relevant at this point.
Since the script does get on the classpath, it should be accessible from your debugger.
I use IntelliJ to debug groovy services/events.
Launch Ofbis using:
Once the initial build steps are complete you should see:
Set your debugger to connect to a remote VM on localhost port 5005. Ofbiz won't continue to load until your debugger is connected.
Once connected, if you aren't able to hit any breakpoints then it is worth checking how your debugger associates sources with the remote VM's classpath.
Hopefully that should get you connected. We can then figure out any other IDE specific issues after that.
Note: you can only modify a script called as a service or event. You can't modify any supporting classes (groovy or java) without a rebuild and restarting ofbiz. This is due to those supporting classes being loaded from the proper classpath, and I haven't been able to get ofbiz to recognise that those compile classfiles on the classpath have been modified and to reload them accordingly. Finding a solution to this will massively improve development for me.