Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 51898

Summary:	Refactor Rename of class members does not offer the option to update non-java files [refactoring]
Product:	[Eclipse Project] JDT	Reporter:	Philippe Ombredanne <pombredanne>
Component:	UI	Assignee:	JDT-UI-Inbox <jdt-ui-inbox>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	dirk_baeumer
Version:	3.0	Keywords:	helpwanted
Target Milestone:	---
Hardware:	All
OS:	Windows XP
Whiteboard:

Description Philippe Ombredanne

2004-02-12 16:07:47 EST

When you do a refactor/rename on a class member, no option is offered to "Update
fully qualified name in non java files" like for many other refactorings.

As a result the renaming of the member can never be propagated to a non java
configuration file.

Actually renaming members never has that option available whatever the modifer
(public, private, default, protected) you use.

Therefore there seems to be an assumption that a member fully qualified name is
NEVER used in an external file...
While I could say this may not be good programming style, there is no reason why
refactoring should ignore that. 

As far as renaming of classes, not members, it works fine and is propagated to
the non-java files when the option is choosen.

For a simple test project see Bug#50988 attachment at
https://bugs.eclipse.org/bugs/attachment.cgi?id=7696&action=view

My suggestion: 
The  "Update fully qualified name in non java files" option should be offered
everywhere it is relevant :
-renaming of members, static or not,
-moving members static or not, but especially static,
-renaming or moving methods,
-inlining of methods (to highlight problems that will occur once the method has
been inlined)
-changement of signatures,
-pulling up,
-introducing factories,....

Specific attention could be paid to jsp (and derivative new jsp 2.0
jspx/jspf/tag/tagf/tagx) files where the syntax used is quite close to Java and
remaning propagation could include non-qualified names, since you can import
java packages in jsp. Same of JSTL el.
That could make refactoring a real power tool for j2ee web apps.
Cheers
Philippe

Comment 1 Dirk Baeumer

2004-02-13 04:25:56 EST

With 3.0 refactoring is opened-up in a way that other can participate in 
certain refactorings (rename, move, delete, change signature, (and may be 
inline). For example a JSP Tool can listen to all "rename" refactorings 
(including method, field, inner type renames) and can update the JSP specific 
files. There are no plans to implement the "text based" searching for other 
refactorings (we might even remove it since the right way to do it are 
participants).

Comment 2 Philippe Ombredanne

2004-02-20 15:12:27 EST

Dirk, the issue of renaming class member without having a way to propagate that
to external file is still valid regardless of JSP suggestions.
I added that bug based on the recommendation of Markus. See
https://bugs.eclipse.org/bugs/show_bug.cgi?id=50988 .
As far as removing the ability to natively work with external files, do not
remove it!
You would just make eclipse a less powerful tool, and just provide incentive to
move to IntelliJ (or Jdevelopper when they release their new refactoring
capabilities which they are working hard on)

Please do not remove it!!

Cheers
Philippe

Comment 3 Dirk Baeumer

2004-02-21 11:54:39 EST

There are now plans to extend the file based searching to type members for 
3.0. Hoewever I will consider the point of not removing the existing support.

Comment 4 Eclipse Webmaster

2009-08-30 02:42:21 EDT

As of now 'LATER' and 'REMIND' resolutions are no longer supported.
Please reopen this bug if it is still valid for you.