Is anyone working on Groovy language support at the moment? Asking because I'm looking at things, and don't want to collide and throw away each others time.

I previously sent this from the wrong address...

All,

After a long time without proper Groovy support for some important features in the IDE, I have bit the bullet, and started digging in. The first priorities for me are “Run Focused Test Method” and “Debug Focused Test Method”.

I see that someone started in the past, but the code there is in 1 of 2 states: 1) partially to mostly there and incorrect in places or 2) completely wrong. Also, I’m noticing the project DAG with relation to “Groovy Support” and “Groovy Editor”, while correct for some things, is not what we need to be able to discover the selected method and name from the Groovy source code considering to do this we need to be able to access the GroovyParser and GroovyParserResult in the “Groovy Support” module to correlate the cursor position to the selected or surrounding method name and class.

I know this as I have changed up org.netbeans.modules.groovy.support.actions.TestMethodUtil and org.netbeans.modules.gsf.testrunner.ui.TestMethodRunnerAction enough to attempt to run a selected method, and see what happens in the code. I changed TestMethodUtil enough not to error out and allow it to get all the way down to incorrectly looking for a JavaSource instance in the Document; which it never finds. It is using JavaSource where it really needs Source and GroovyParserResult plus the Groovy classes ModuleNode and ASTNode; i.e. we are parsing Groovy code not Java.

This from code in TestMethodUtil doing this:
            JavaSource js = JavaSource.forDocument(doc);
            GroovyTestClassInfoTask task = new GroovyTestClassInfoTask(cursor);
            try {
                if (js != null) {
                    Future<Void> f = js.runWhenScanFinished(task, true);
                    if (f.isDone() && task.getFileObject() != null && task.getMethodName() != null){
                        sm = new SingleMethod(task.getFileObject(), task.getMethodName());
                    }
                }
            } catch (IOException ex) {
                LOGGER.log(Level.WARNING, null, ex);
            }

and then GroovyTestClassInfoTask really needs to be oriented to the Groovy AST.

Once you discover this, you realize you don’t have access to those classes, that Groovy Editor depends on Groovy Support, and thus Groovy Support can not depend on Groovy Editor (cyclical dependencies), and too, there is a bit more to write. I also noticed that org.netbeans.modules.gsf.testrunner.ui.TestMethodRunnerAction is slightly problematic as it is generic code, but action registration is its Achilles hill. To get it to work for both Java and Groovy, one needs to add an extra @ActionReference(path = "Editors/text/x-groovy/Popup", position=1795)} … 1795 definitely needs adjusted as I’m just getting the workings down.

I have thought about using reflection for the near term to access the GroovyParserResult which is returned from code similar to this:
                ParserManager.parseWhenScanFinished(Collections.<Source>singleton(s), new UserTask() {
                    @Override
                    public void run(ResultIterator rit) throws Exception {
                        Result r = rit.getParserResult();
                        if("GroovyParserResult".equals(r.getClass().getSimpleName())) {
                            //do things here as it will be with the correct code
                            //and use reflection to get the Groovy ModuleNode instance
                            //and hand off to a new GroovyTestClassInfoTask like utility
                        }
                    }
                    
                });

I think I can get a POC together that will basically only require changes to:
* org.netbeans.modules.gsf.testrunner.ui.TestMethodRunnerAction (annotation additions unless there is some other way to inject this), but now that I’m writing this I do see org.netbeans.modules.groovy.support.actions.TestMethodAction which isn’t halfway baked. So, this may be TestMethodAction completion or an extra annotation on TestMethodRunnerAction; TestMethodRunnerAction works as expected ATM.

* org.netbeans.modules.groovy.support.actions.TestMethodUtil

* org.netbeans.modules.groovy.support.actions.GroovyTestClassInfoTask (essentially making it extends UserTask instead of CancellableTask<CompilationController>)

* “Groovy Support” projects meta-data “project.xml”, to add the dependency on the Groovy binaries

Anyways, that would be to get it there, as that is the worst thing not having in the Groovy editor during my day to day work when testing code. There are other low hanging fruit related to actions and parsing that might be able to be fixed with everything in the structure it is in currently, and though using reflection doesn’t “feel right”, it may be the best thing to do in the mean time with a TODO being added to break out and fix later, after all dependencies and the overall graph can be better understood, plus some tests to verify if code is ever changed which makes it broken. When I start looking into “Refactoring” then perhaps the picture gets worse; I don’t know. But, at that time, then I would worry further. Does that sound workable or something that could get accepted?

I am working locally off main-golden, so any patch I submit will be in that context.

Many thanks,

Wade

===================

Wade Chandler
e: [email protected] <mailto:[email protected]>



===================

Wade Chandler
e: [email protected]