next plugin version is being planned

Howdy,

We are now approaching the release of jetgroovy 1.0, and are mostly concerned with bugfixing. Meanwhile the planning for next version has started. We of course have some features on our own priority list, like for example extract and inline method in groovy. Still we are extremely interested in getting your feedback. What features would you consider worth adding into jetgroovy in the next release?

Best,
Eugene.

28 comments

Hey Eugene!
As always I vote for stability and bug fixes above features, but for features here are my votes:

1. Improvements in code completion in groovy. Improvements in speed for code completion is also important so it can just be an automatic thing I do while I'm coding.
2. Code completion of attributes in GSPs, it would be great for custom tags as well.
3. Improved groovy-to-java and java-to-groovy object recognition.
4. Better refactoring support, in particular changing the names of Domain classes and having those changes in the GSPs, controllers, etc.

In short, everything that intellij does so well in Java. I think all the other features are just nice-to-haves for me. But these are things I use EVERYDAY.

My attitude is that Groovy's strength is it's integration with Java APIs and the ability to drop into Java anytime I want. Grails is already an outstanding prototyping or smallish application framework, but it's ability to integrate with Java stuff gives it the potential to be used in projects of all sizes and complexities. That is the space in which I work and that's where I want it to go.

0

In terms of finishing refactorings, I'd put Copy/Clone Class high on the list. It's extra especially annoying in that right now the key binding for Copy Class defaults to copying a file, leaving you with two identical Groovy classes.

--Dave Griffith

0

Stability and consistency are the top priorities for me. I currently have problems with the JUnit-integration that starts to run against the Groovy-Java stubs instead of the compiled Groovy classes with every second run. A full rebuild of the project is required then.

This makes it pretty hard to convince my teammates to use it...

Dierk

P.S. it would be helpful to show classes generated from Groovy with a different icon in the project view than normal Java classes (just like Groovy scripts).

0

This is idea core issue, and good news is that is has been fixed. The fix will be available in 7.0.2

0

OK, I see. This would require minor refactoring to idea core, that I was ready to make in 7.0, but it was decided to postpone it.

0

Hey Eugene!
As always I vote for stability and bug fixes above
features

Sure, anything specific?

, but for features here are my votes:


1. Improvements in code completion in groovy.
Improvements in speed for code completion is also
important so it can just be an automatic thing I do
while I'm coding.

Again any specific information regarding th eperformance of completion would greatly help us polish the release.

. Code completion of attributes in GSPs, it would be
great for custom tags as well.

We have this already, but we are not sure if to include it in the release.

3. Improved groovy-to-java and java-to-groovy object
recognition.

Anything here not working should be considered a bug

4. Better refactoring support, in particular changing
the names of Domain classes and having those changes
in the GSPs, controllers, etc.

Well, we cannot figure out the types for all occurrences, so you'll always need to review "dynamically typed usages" yourself.


In short, everything that intellij does so well in
Java.

Not everything makes sense in groovy, after all it is the language that cares about many aspects of routine programmer work.

Eugene.

0

Actually, Groovy class files are shown with different icons, they're just not very different. The Groovy ones are rounded-corner squares, while the Java ones are circles.

Randall Schulz

0

The only bug that actually causes me pain is the restart-classes-not-recognized which I mention in another thread.

Actually I think the "groovy" code completion is pretty darned good, and thanks for that. I am mostly thinking of GSP attributes. But one thing I would love to see is completion of dynamic methods by convention within Grails. With Grails 1.0 about to come out the conventions should stabilize so I can see this being a useful feature. So for instance, your domain classes have all the query methods, would it be possible to add these to the list of code completion? I use the code completion for speeding up my typing as much as to find what is available so it would be great to auto-complete the domain class queries.

As far as speed of code completion, is it just me or does the pop-up hesitate for a second or two? With the Java code-completion it appears to be instantaneous.

0

very subtle ;)
Then let's reframe my request by saying "make the distinction a bit more obvious". Maybe green background color?

but it's only a minor issue
Dierk

0

"Extract Closure" refactoring. Similar to extract method, but producing an inline closure/.call() combination. Useful in itself, but especially useful when followed up by Extract Variable/Method/Parameter, enabling control-flow to be easily abstracted.

A big job, but in your heart you know you really want to...

--Dave Griffith

0

Yes, that would be a real killer. Also in case there is closure transparency in groovy (which is still to be proved...) this code modification seems extremely trivial.
Thank you for the great idea, Dave.

Eugene.

0

Refactoring: move class to separate file (groovy files sometimes have more than one class and it would be convenient to refactor code that way. E.g. I often start writing the testcases in the same file and want to have it separated later)

Navigation between Unit Tests and Class Under Test with a single click.

Unit-Test: let the tests run with every 'save' like eclipse does. It's so cool to have a minimized Junit-icon showing Tests ok/not ok/running while you keep on working in the editor...

Dierk

0

Refactoring: move class to separate file (groovy
files sometimes have more than one class and it would
be convenient to refactor code that way. E.g. I often
start writing the testcases in the same file and want
to have it separated later)

OK, makes perfect sense.


Navigation between Unit Tests and Class Under Test
with a single click.

Do groovy programmers always have their test structure identical to production code structure? I don't think java projects are structured that way always.
Otherwise how would IDE know which test is relevant? By searching for ]]>Test ? Probably this makes sense sometimes...


Unit-Test: let the tests run with every 'save' like
eclipse does. It's so cool to have a minimized
Junit-icon showing Tests ok/not ok/running while you
keep on working in the editor...

The subtlety here is that idea has know explicit save:) So some other indication of the fact you have finished certain iteration is needed. I can't think of any such indication, but triggering the test itself:)


Dierk


Eugene.

0

"no explicit save" I mean of course, should really have a good sleep now...

0

>Otherwise how would IDE know which test is relevant? By searching for ]]>Test ?

Purely as an aside, yes, navigation to a unit test based on naming pattern would be incredibly worthwhile. The pattern you describe should be the default, as it's incredibly common in production environments. The unitTest plugin provides just that functionality, and it's incredibly handy. Yes, it's crude and contains no knowlege whatsoever of any semantic content, but nonetheless it's The Right Thing To Do.

--Dave Griffith

0

Do groovy programmers always have their test
structure identical to production code structure? I

..

Otherwise how would IDE know which test is relevant?
By searching for <ClassName>Test ?


IIRC there has been a feature in an IDEA version long time ago (around version 3 or so) where one could specify that mapping like src/*/<class> would map to test/*/]]>Test.

It's so cool to have a minimized
Junit-icon showing Tests ok/not ok/running while
you keep on working in the editor...

..

The subtlety here is that idea has know explicit
save:) So some other indication of the fact you have
finished certain iteration is needed. I can't think
of any such indication, but triggering the test
itself:)


True, but this should be easier. Currently - even with the test window being open - I cannot use Ctrl-F5 to run the test, because that short cut doesn't work as long as I'm in the editor window :(
What I have seen in eclipse and what made me jealous is
- only having the editor open and not leaving it (I see the maximum of the code)
- clicking a certain shortcut (e.g. Ctrl-S)
- the tests start running and I get a minimized indication about their status (ok/not ok/running)
- only in case of unexpected results, I click on the minimized icon to open the JUnit view.
It may well be possible that this is supported today. In this case I would be very thankful to see how ;)

0

A fairly small one, but being able to manage Grails plugins via IDEA would be cool. Nothing major, just a subpanel in the config for list/download/enable/disable plugins.

--Dave Griffith

0

Ability to switch between Groovy/Grails versions just like for the JDK. Currently, it's probably on the Groovy/Grails developers that need this feature but in future it will be of general interest...

Dierk

0

I see. I wonder when you guys will introduce groovy language level like in java:)

Eugene.

0

I'm not a great expert in how this is manageable. Have been to Graeme's session on plugins, but I didn't get the repository aspect. Has anybody an idea if grails plugins infrastructure is really IDE friendly?

Eugene.

0

How about auto completion of constraints in Domain Objects. It would be cool to auto complete nullable, maxSize, etc to cut down on spelling errors and the like. Also have Idea give me common options such as true/false for nullable. This is a small one but it's the kind of polish that we expect from Idea.

0

All I'm really describing is a UI for ListPlugins/InstallPlugin/PluginInfo scripts, which are just Groovy scripts in the Grails script directory. Should be pretty straightforward, if you decide to do it.

--Dave Griffith

0

I'd like to see the ability to inform a script of the names and types of variables expected in a binding so that code completion works.

e.g.
the calling part:
Map<String,Object> beans = new HashMap<String,Object>();
beans.put("logger", logger);
GroovyScriptEngine().run(scriptName, new groovy.lang.Binding(beans));

if a script contains:

logger.debug("I'm here")

there doesn't appear to be any way to tell IntelliJ what names/types of the objects present in the binding are. I don't know much about how annotations work in Groovy but I assume the following might work to kick things off:

@Binding name=logger, type=org.apache.log4j.Logger

logger.debug("I'm here")

0

Closely related is that so much code results in a warning of 'Cannot determine type statically'. I find this warning to be "noise" and miss any warning when I forget to declare a variable before use.

0

I've been saying exactly this for a couple of months, now...


RRS

0

This action as available in surround with group. In jetgroovy 1.0 it does not take care of changed resolve targets (no, closure transparency is not there in groovy). In the branch that will be released afterwards I've modified that, and now explicit 'owner' qualification will be inserted.

Eugene.

0

Please sign in to leave a comment.