Community
Participate
Working Groups
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
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).
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
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.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
