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 should add the run/debug single test support was merged into the dailies
some days ago now.

Wade

On Sep 26, 2016 11:22 PM, "Wade Chandler" <[email protected]> wrote:

> Way to go Sven! I can't wait to check it out.
>
> I want to look at source scanning and completion in Groovy files not in a
> project; such as scripts under favorites or in some other structure. It
> seems if a Groovy environment could be associated with a path, that would
> be possible. Too, support for Grape.grab or other class path altering logic
> in a script.
>
> Wade
>
> On Sep 24, 2016 8:06 AM, "Sven Reimers" <[email protected]> wrote:
>
>> Hi guys,
>>
>> I already made some progress enhancing code completion and a first hook
>> for mime-type based code completion extension (using gradle files as poc)
>>
>> Bonus: Initial support for traits (i.e. traits not making IDE unusable)
>>
>> More news once I am back from Java One.
>>
>> I assume we can start committing changes  (after release branch creation?)
>>
>> Will make handling the different things more easy for me
>>
>> Sven
>>
>> Am 07.09.2016 05:23 schrieb "Wade Chandler" <[email protected]>:
>>
>>> 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" <[email protected]>
>>> wrote:
>>>
>>> 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: [email protected]
>>>
>>>
>>>
>>> On Sep 5, 2016, at 13:26, Bruno Flavio <[email protected]> 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 :)
>>>
>>> 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.t
>>>> estrunner.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.parseWhenScanFin
>>>> ished(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.groov
>>>> y.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]
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> ===================
>>>
>>> Wade Chandler
>>> e: [email protected]
>>>
>>>
>>>
>>>
>>>