Re: 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.

Hello Wade,

I'm currently the community member maintaining Groovy/Grails support.

Sven Reimers and Martin Klähn recently got in touch to improve the NetBeans
Groovy code completion for Groovy based DSL's. A wiki page has been setup
by Sven which gives us an overview of the issues and options regarding
their resolution:

http://wiki.netbeans.org/MakeGroovyInNetBeansGreatAgain

I'm working to add extension points that allow an faster support of newer
Grails versions and that will eventually allows NetBeans to support a
Grails version per project (currently only one version can be used at a
time within the IDE).

Thus it would be great to have your help and the POC would be greatly
appreciated (using reflection in order to access the necessary groovy
classes) Let me know what I could do to ease the development. I can
test/apply patches or give access to a Jenkins instance configured to test
a patch against core-main or main-silver and run the Groovy/Grails related
test suites.

Feel free to edit the aforementioned wiki page and/or update the relevant
issues (#212829 ?). Also I don't see a reason not to update the source to
1.8 whenever necessary.

Thank you for looking into this. Keep in touch :)

Best regards,
Bruno Flávio.

On Sun, 4 Sep 2016 at 16:37 Wade Chandler <[email protected]> wrote:

> Also,
>
> Any objections to bumping the Java version in NB projects
> project.properties to 1.8 considering we need 1.8 to build as it is? i.e.
> is it OK to use Java 1.8 syntax in NB projects (such as Streams and Lambdas
> where possible). I noticed some already do this, and others are still at
> source 1.6. If no to a blanket “if you touch a project, update the source
> to 1.8”, then what about just the Groovy projects for now?
>
> Thanks,
>
> Wade
>
>
> ===================
>
> Wade Chandler
> e: [email protected]
>
>
>
> On Sep 4, 2016, at 11:19, Wade Chandler <[email protected]> wrote:
>
> 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]
>
>
>
>
> ===================
>
> Wade Chandler
> e: [email protected]
>
>
>
>
>