NetBeans Forums

 FAQFAQ   SearchSearch   MemberlistMemberlist   RegisterRegister   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
  

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.

 
Post new topic   Reply to topic    NetBeans Forums -> NetBeans Developers
View previous topic :: View next topic  
Author Message
Wade Chandler
Posted via mailing list.





PostPosted: Sun Sep 04, 2016 3:20 pm    Post subject: 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. Reply with quote

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: address-removed ([email]address-removed[/email])



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

Wade Chandler
e: address-removed ([email]address-removed[/email])
Back to top
Wade Chandler
Posted via mailing list.





PostPosted: Sun Sep 04, 2016 3:37 pm    Post subject: 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. Reply with quote

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: address-removed ([email]address-removed[/email])


Quote:
On Sep 4, 2016, at 11:19, Wade Chandler <address-removed ([email]address-removed[/email])> 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: address-removed ([email]address-removed[/email])



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

Wade Chandler
e: address-removed ([email]address-removed[/email])




Back to top
emi



Joined: 14 Aug 2009
Posts: 245

PostPosted: Mon Sep 05, 2016 1:44 pm    Post subject: 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. Reply with quote

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 <address-removed ([email]address-removed[/email])> wrote:
Quote:
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: address-removed ([email]address-removed[/email])





Quote:
On Sep 4, 2016, at 11:19, Wade Chandler <address-removed ([email]address-removed[/email])> 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: address-removed ([email]address-removed[/email])







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


Wade Chandler
e: address-removed ([email]address-removed[/email])













Back to top
Bruno Flavio
Posted via mailing list.





PostPosted: Mon Sep 05, 2016 5:30 pm    Post subject: 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. Reply with quote

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 Smile


Best regards,
Bruno Flávio.


On Sun, 4 Sep 2016 at 16:37 Wade Chandler <address-removed ([email]address-removed[/email])> wrote:

Quote:
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: address-removed ([email]address-removed[/email])







Quote:
On Sep 4, 2016, at 11:19, Wade Chandler <address-removed ([email]address-removed[/email])> 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: address-removed ([email]address-removed[/email])







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


Wade Chandler
e: address-removed ([email]address-removed[/email])











Back to top
Wade Chandler
Posted via mailing list.





PostPosted: Mon Sep 05, 2016 6:16 pm    Post subject: 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. Reply with quote

Sounds good Bruno. I’m in the middle of it, so once I done I will post an issue (or find one), and attach the patch, or look for a repo in which to create a branch to request a merge.
Thanks

Wade
===================

Wade Chandler
e: address-removed ([email]address-removed[/email])


Quote:
On Sep 5, 2016, at 13:26, Bruno Flavio <address-removed ([email]address-removed[/email])> wrote:
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 Smile

Best regards,
Bruno Flávio.

On Sun, 4 Sep 2016 at 16:37 Wade Chandler <address-removed ([email]address-removed[/email])> wrote:
Quote:
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: address-removed ([email]address-removed[/email])




Quote:
On Sep 4, 2016, at 11:19, Wade Chandler <address-removed ([email]address-removed[/email])> 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: address-removed ([email]address-removed[/email])



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

Wade Chandler
e: address-removed ([email]address-removed[/email])














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

Wade Chandler
e: address-removed ([email]address-removed[/email])
Back to top
Wade Chandler
Posted via mailing list.





PostPosted: Mon Sep 05, 2016 8:42 pm    Post subject: 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. Reply with quote

Sounds good Bruno. I’m in the middle of it, so once I done I will post an issue (or find one), and attach the patch, or look for a repo in which to create a branch to request a merge.
Thanks

Wade
===================

Wade Chandler
e: address-removed ([email]address-removed[/email])


Quote:
On Sep 5, 2016, at 13:26, Bruno Flavio <address-removed ([email]address-removed[/email])> wrote:
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 Smile

Best regards,
Bruno Flávio.

On Sun, 4 Sep 2016 at 16:37 Wade Chandler <address-removed ([email]address-removed[/email])> wrote:
Quote:
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: address-removed ([email]address-removed[/email])




Quote:
On Sep 4, 2016, at 11:19, Wade Chandler <address-removed ([email]address-removed[/email])> 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: address-removed ([email]address-removed[/email])



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

Wade Chandler
e: address-removed ([email]address-removed[/email])











Back to top
Wade Chandler
Posted via mailing list.





PostPosted: Wed Sep 07, 2016 3:24 am    Post subject: 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. Reply with quote

I have it running nicely locally. I haven't tested on Windows yet though. Too, I noticed there are no tests in the support module; at all. I am adding some only for what I am touching. Too, I will need to make isTestClass work better. At the moment I believe it would be enabled for any Groovy file, but honestly it is better than not having the option at all, and at worst case things will fail as expected of one tries to test a class or method that is not a test. Not much different than the "run" file which is enabled for a file with nothing "runnable". So, I may submit this before making that work better, and then iterate.
I wonder if this could be back ported to 8.1 or at least make a quick fix for the 8.2 release. It is a pain using Groovy for testing in NB without run single.
Wade
On Sep 5, 2016 2:15 PM, "Wade Chandler" <address-removed ([email]address-removed[/email])> wrote:
Quote:
Sounds good Bruno. I’m in the middle of it, so once I done I will post an issue (or find one), and attach the patch, or look for a repo in which to create a branch to request a merge.

Thanks



Wade



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


Wade Chandler
e: address-removed ([email]address-removed[/email])






Quote:
On Sep 5, 2016, at 13:26, Bruno Flavio <address-removed ([email]address-removed[/email])> wrote:


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 Smile


Best regards,
Bruno Flávio.


On Sun, 4 Sep 2016 at 16:37 Wade Chandler <address-removed ([email]address-removed[/email])> wrote:

Quote:
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: address-removed ([email]address-removed[/email])







Quote:
On Sep 4, 2016, at 11:19, Wade Chandler <address-removed ([email]address-removed[/email])> 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: address-removed ([email]address-removed[/email])







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


Wade Chandler
e: address-removed ([email]address-removed[/email])
























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


Wade Chandler
e: address-removed ([email]address-removed[/email])







Back to top
Display posts from previous:   
Post new topic   Reply to topic    NetBeans Forums -> NetBeans Developers All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB
By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo