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.

I don't see why not. I have a small patch in 8.2 which uses streams.


--emi

On Sun, Sep 4, 2016 at 6:36 PM, 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]
>
>
>
>
>