This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 151987 - Groovy refactoring support
Summary: Groovy refactoring support
Status: NEW
Alias: None
Product: groovy
Classification: Unclassified
Component: Refactoring (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker with 5 votes (vote)
Assignee: Martin Janicek
URL: http://wiki.netbeans.org/GroovyDevelo...
Keywords:
: 154758 (view as bug list)
Depends on: 159871 196604 123161 123163
Blocks: 211896
  Show dependency tree
 
Reported: 2008-10-31 15:00 UTC by Petr Hejl
Modified: 2012-10-24 07:33 UTC (History)
5 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Hejl 2008-10-31 15:00:14 UTC
There is some kind of basic refactoring support implemented. We should made it more reliable and robust. The main focus
is on pure groovy refactoring, not primarily mixed Groovy/Java and Java/Groovy refactoring, although it should not be
prevented by implementation of this enhancement.
Comment 1 Petr Hejl 2008-10-31 15:04:35 UTC
Fixed cc.
Comment 2 Martin Janicek 2012-03-11 13:59:02 UTC
*** Bug 154758 has been marked as a duplicate of this bug. ***
Comment 3 _ wadechandler 2012-05-16 19:19:31 UTC
Yes, Java/Groovy together in my experience is usually what one gets. So, for instance, being able to click in a Groovy file, search for usages, and have them show up for Groovy and Java sources is a big deal. 

Same if one goes to the navigation menu and tries to find a type. Seeing both Java and Groovy types is very important; *though I'm just using this as an example because in the latest builds I noticed that I can search for types and both Groovy and Java types are found*
Comment 4 Martin Janicek 2012-05-17 06:55:08 UTC
Ye, I absolutely agree with you. I'm planning to work on Groovy refactoring right after the code freeze for 7.2
Comment 5 _ wadechandler 2012-06-18 18:01:43 UTC
Another very important feature is cross language refactoring such as renaming a method or a class. If I do that in Java or Groovy, then I expect it to take care of those things in other files of either Java or Groovy across the projects. I haven't specifically looked at the refactoring context stuff, but if this is just refactoring information about types which is broadcast and can be consumed, then this could be used by other languages such as scala as well. If some changes are needed to the Java refactoring support to support Groovy, and JVM languages in general, at least those which support the Java type system and are compatible with Java itself, then that could be a good driver for general purpose usage if refactoring support isn't that generic already.
Comment 6 Martin Janicek 2012-06-19 07:37:51 UTC
(In reply to comment #5)
> Another very important feature is cross language refactoring such as renaming a
> method or a class. If I do that in Java or Groovy, then I expect it to take
> care of those things in other files of either Java or Groovy across the
> projects. 

Thanks, I'm aware of this and of course planning to make it as well. But step by step (Groovy refactoring as the first part, cross language as the second part - but agree that we need to have that in our mind when implementing the first part)

> I haven't specifically looked at the refactoring context stuff, but
> if this is just refactoring information about types which is broadcast and can
> be consumed, then this could be used by other languages such as scala as well.
> If some changes are needed to the Java refactoring support to support Groovy,
> and JVM languages in general, at least those which support the Java type system
> and are compatible with Java itself, then that could be a good driver for
> general purpose usage if refactoring support isn't that generic already.

Unfortunately this isn't as easy as one could say. There are some specific problems in different languages, mostly because e.g. Groovy is a dynamic language in opposite to Java and thus you can't know (in some cases) which occurrences user want to refactor and which don't. If you are interested in details, you might want to see [1] which is a pretty nice team bachelor thesis about Groovy refactoring in Eclipse. It's actually nice written and you might found there details about the problem I've mentioned.

Anyway I'm planning to start the work in a few days, so stay in touch ;]

[1] http://groovy.ifs.hsr.ch/