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.

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]
>>
>>
>>
>>
>>