Hi Mircea,
Yes this is because the Groovy runtime dynamically compiles and executes the scripts. As far as we are aware when using Groovy like this (ie a truely dynamic language) you can''t attach the Java debugger.
My guess is that IDEs supporting groovy are actually compiling it to Java classes - and using regular Java debugging.
Its an interesting challenge - since in the ROC world source code is a resource, it may not even have a physical file for the Java debugger to link against. Its analogous to when you try and debug a class and give the IDE source that is not in step and the debugger line marker bears no relation to the breakpoint.
So the solution, when using scripting languages is to use copious logging/println. Or, if what you''re doing does not need the flexibility of a dynamic language - you can always compile the Groovy with groovyc. The NK classloader won''t care - it''s all just classes.
Cheers,
Peter
Yes this is because the Groovy runtime dynamically compiles and executes the scripts. As far as we are aware when using Groovy like this (ie a truely dynamic language) you can''t attach the Java debugger.
My guess is that IDEs supporting groovy are actually compiling it to Java classes - and using regular Java debugging.
Its an interesting challenge - since in the ROC world source code is a resource, it may not even have a physical file for the Java debugger to link against. Its analogous to when you try and debug a class and give the IDE source that is not in step and the debugger line marker bears no relation to the breakpoint.
So the solution, when using scripting languages is to use copious logging/println. Or, if what you''re doing does not need the flexibility of a dynamic language - you can always compile the Groovy with groovyc. The NK classloader won''t care - it''s all just classes.
Cheers,
Peter