Community
Participate
Working Groups
Build ID: M20080911-1700 Steps To Reproduce: I have a custom file that generates java source. When I rename the file I want it to rename the java source also. 1.Create a rename participant which given a file of type X it renames both the X file, and the related java file. 2.Create a file of type X, and a java file (named the same but for the extension and in the same path). 3.Select the X file and rename it. The rename participant can easily rename X, and can also rename the java source, but cannot take advantage of the built in jdt renaming code since it appears bundled into the RenameTypeProcessor which must have been used to start the rename refactoring. More information: It seems like refactoring the RenameTypeProcessor (and other JDT refactoring code) such that it is useable by custom refactorings should solve this problem. Another possible solution (perhaps more clean) is to allow adding to the RenameAction (include other actions such as the move?) while performing discovery (calling initialize(Object) on RefactoringParticipant instances). This solution would appear to be much more flexible.
Markus, please comment.
Cascaded refactorings are currently not supported by the processor/participant infrastructure. The framework would need to make sure that cascaded refactorings don't end up in loops. I agree that this would be nice, but it would be a lot of work to implement, and we unfortunately don't have the resources to do this at the moment. The best advice I can give you right now is to do it asynchronously, i.e. schedule a Job in your participant which calls the RenameSupport API to trigger rename of the Java file after X has been renamed.
