If You Include the Groovy Editor...

...in a NetBeans RCP application, what additional JARs will you need to include for the Groovy Editor to work?

Leaving aside the debate on the current state & quality of the NetBeans Groovy Editor, so, assuming you need the Groovy support that the NetBeans Groovy Editor provides, you would check the Groovy Editor checkbox in the Project Properties dialog of your application:

As you can see, however, the Groovy Editor depends on other modules, some of which, in turn, depend on yet other modules, and so on. So, I clicked the "Resolve" button above and then created a ZIP distribution, to see which additional JARs had been included.

Until that point, I had only been using the "platform" cluster, which means that absolutely everything found in the ZIP's "ide" cluster and "java" cluster have only been included so that the Groovy Editor could be included, i.e., all thanks to clicking the "Resolve" button above.

Let's first look at what that means for the "java" cluster:

That's not so bad and kind of a side effect of Groovy being Java, i.e., a lot of Java functionality is needed.

Now let's look at the "ide" cluster:

So, in answer to the original question, if all you want in your NetBeans Platform application, in terms of editor functionality, is the Groovy Editor, then you have a pretty high price to pay. At the very least, I would have assumed that the project support JARs and the debugger support JARs would not be so tightly coupled with the Groovy Editor. That would be a cool thing to separate out from the editor support.


Yes, long ago we had the standalone editor which worked upto 6.1 or so.

Right now the dependency graph is really tight for the editor modules so it's rather hard to use it.

As it seems in your blog post, the graph is too big even for Platform apps (where you don't need the code to work in a standalone fashion).

Interesting factoid: the ext/javac-*-nb-7.0-b07.jar files you see there are actually the javac compiler (from http://hg.netbeans.org/main/nb-javac/ ).

I think it should be possible to use groovy without most of those dependencies (like debugger), and even libs.javac assuming the groovy module has it's own parser and doesn't need the javac one.

The only decent editor *component* is probably JIDE's (http://www.jidesoft.com/products/editor.htm ). But that doesn't even compare to the NetBeans Editor so it's a shame it's so hard to integrate.

Posted by Emilian Bold on November 30, 2011 at 02:53 AM PST #

Speaking of the NetBeans Groovy plugin, does anyone know how to update the version of Groovy that it uses?

Posted by jimmy on December 01, 2011 at 05:53 AM PST #

Yes, there are definitely lots of opportunities to make things more modular and thus more easily reused without extraneous stuff. See also these issues:



Posted by Module Man on December 02, 2011 at 02:01 AM PST #

I noticed a similar problem with the spellchecker - it depends on the Editor Code Folding, Project API etc. There could/should be a separate module providing a spellchecker support for the editor, but there is no reason why a basic spellchecker module should contain such dependencies.

One might want to use a spellchecker in a RCP without any editor or projects (say checking text in table fields, etc.)

Posted by Jirka on December 02, 2011 at 06:36 AM PST #

Is this a 'code smell' of improperly used modularity? We found in our Nb RCP app that Nb modules we coded were used as a kind of 'super package' and not dynamically loadable/unloadable chunks of functionality with clearly delineated service and/or functionality.

Posted by Bob Johnson on December 04, 2011 at 11:21 PM PST #

Post a Comment:
  • HTML Syntax: NOT allowed

Geertjan Wielenga (@geertjanw) is a Principal Product Manager in the Oracle Developer Tools group living & working in Amsterdam. He is a Java technology enthusiast, evangelist, trainer, speaker, and writer. He blogs here daily.

The focus of this blog is mostly on NetBeans (a development tool primarily for Java programmers), with an occasional reference to NetBeans, and sometimes diverging to topics relating to NetBeans. And then there are days when NetBeans is mentioned, just for a change.


« June 2016