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.

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