Introducing NetBeans for Groovy blog

Hello! This is a blog of the team that works on the Groovy development support in NetBeans IDE.

Groovy support has been a part of NetBeans for a while, but we were not working on it much in a last few releases. Good news for everyone is that we are working on it again and hopefully we can make it much better for you!

We really want to get feedback from the real users. No, it doesn't have to be all positive. In fact, there are a number of areas that need improvement and we realize it. So, constructive criticism, feature ideas and enhancement requests, bug reports... all that stuff is welcome!

If you don't have NetBeans on your computer right now, you can either download the Stable Version (currently NetBeans 7.1.1), or, if you want the latest greatest (and likely less stable), you can try the latest development builds. And if you want to share your observations and ideas, feel free to leave comments in this blog, join the users at groovy dot netbeans dot org mailing list, or submit your requests and ideas via our bug tracking system.

Looking forward to hearing from you!


Are you also working on the Grails support?

Right now using Netbeans with Grails 2.0 is not a fun experience.

Posted by Markus on March 14, 2012 at 05:08 AM PDT #

Hi Markus,
we are definatelly plan to work on the Grails support as well, but currently we are focusing more on Groovy improvements in general. Personally I'm fan of step by step aproach so I would like to see good groovy support as a first step and grails improvements as a second step.

Posted by Martin Janicek on March 15, 2012 at 02:11 AM PDT #

Finally, NetBeans decides to move Groovy forward.

Without serious Groovy support a lot of Groovy libraries are just not usable, especially we made a very simple Gradle support with Geertjan few months ago and Groovy support was definitely not great.

Good choice !

Posted by Crazyjavahacking on March 20, 2012 at 03:14 PM PDT #

Hi Martin,

This is a very good news! I use groovy every day with a mixed java/groovy app with maven and is a really is not good experience. This is a some issue:

1. Inner class are marked like a error
2. Code autoformat is not the same as java. Some autoformat are bad: one example is switch/case block
3. Code autocomplete is slow and a lot of time don't work.
4. Javadoc aren't showed, only groovy clases from groovy documentation. Not javadoc from groovy files.

There is a release plan for the fixes?

Posted by Rodrigo on March 20, 2012 at 05:34 PM PDT #

Hi Rodrigo,

thanks for your feedback. I would like to ask you for a few related things.
#1: Could you please show me an example? (simple inner class works for me correctly, but I already heart someone complaining about this one so I'm obviously doing something wrong)
#2: Do you have any other autoformat problem examples? I'm aware of the problem with switch/case, but don't know about any others.
About the release plan: We are currently finishing feature development and starting bug fixing, so ye I definitely plan to fix at least some of these problems ;]

Posted by Martin Janicek on March 21, 2012 at 03:40 AM PDT #

I'm really glad to see Netbeans support for Groovy going forward.

My team primarily uses groovy for writing unit tests in a mixed (Java/Groovy) project.
Given this, it would be really nice (and I think straightforward) to be able to execute a .groovy file as a test (Ctrl+F6/Test File) as is the case for a .java file located in the test package folder.

Currently we have a somewhat unwieldy process where we execute the compile tests ant task, then
have a class that references the java class that is compiled from the .groovy file.

We are using Netbeans 7.0 and JUnit 4+-style tests (viz. @Test and so on annotations).

And similarly I would really love to see "Find Usages..." work with .groovy files that are in the test folder.

Posted by thurston on March 30, 2012 at 10:34 AM PDT #

Hi thurston,

thanks for your feedback. I definitely have to agree with all your proposals. I would like to implement at least basic refactoring (Move, Rename, Find usages) as soon as possible (unfortunately it won't be possible for 7.2 - we are already in feature freeze state).
I'm also aware of the problems with Unit testing. I'll try to focus on that area!

Posted by Martin Janicek on April 01, 2012 at 07:22 PM PDT #


This is great to hear! We use Groovy within our RCP app to allow the customer to both get information from the RCP app and call methods exposed in the RCP app through the binding map. It is critical for our customers to have the ability to use Groovy as a scripting language so they can dynamically change how the application runs yet still have access to all the information within the RCP application.

I have a question. To add support for Groovy I just enabled the Groovy Platform Module within the Libraries of my suite. What I don't understand is why I also have to add another module as a wrapper around the all-in-one jar file to get the groovy shell, binding, and other classes? Also, it seems as though the classes in the all-in-one jar file does not conform to the Java JSR 223 for Scripting Languages. When I went to the website that has all the supported Scripting Engines I found another all-in-one groovy jar file and when I use that one in my wrapper module then the ScriptEngineManager class will discover the Groovy classes and I can use the normal java scripting API rather than the special GroovyShell classes that appear in the other all-in-one groovy jar file. Why two different all-in-one jar files? And why do I have to add the all-in-one at all? I don't seem to have to add any additional jar file for full java script support, i.e. beyond just having editing support.

Posted by guest on April 03, 2012 at 03:27 AM PDT #

this is sounds very good for groovy, I like groovy, thanks for return the support

Posted by skuarch on April 18, 2012 at 03:49 AM PDT #

Thutston, I have add some updates about Groovy unit testing to the issue 159256 in our bugzilla (--> I created updated build-impl.xml file which enables to run groovy tests together with java tests in Ant based projects. And I've described how to get Groovy tests working in Maven based projects.

Not sure now if it will be possible to change the behavior for the 7.2 release, because the changes in build.xml are always quite problematic and risky and we are way after the feature freeze. Thats why I tried to find out at least the most simplest way how to workarround the misbehavior for now.

Posted by Martin Janicek on May 22, 2012 at 05:18 AM PDT #

Thurston, as you were asking the support for the Groovy tests was implemented. You can read more about that in my todays post ( I'm also already working on your second proposal (Find Usages) and it should be definitely a part of the NetBeans 7.3 release as well.

Posted by Martin Janicek on August 28, 2012 at 06:52 AM PDT #

I have a really difficult time debugging certain classes. The breakpoints are ignored, or if the debugger does stop, it doesn't step the code. This seems to be only with services classes.

Posted by guest on August 29, 2012 at 01:01 PM PDT #

What do you mean by services classes? Is these related to the Grails project or pure Groovy? Would it be possible to send me those classes via email?

Posted by Martin Janicek on October 10, 2012 at 01:34 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed

This blogs is written by NetBeans developers who contribute to the Groovy support mainly.


« July 2016