Community
Participate
Working Groups
In our code we have many places that record/cache/persist qualified names/sigatures/etc. for reuse. If a refactoring is done on one of these referenced types then the cached information about the (previous) type is stale and never gets removed. We need to add in refactoring participants for: 1. api descriptions, for package/type/member rename/signature changes 2. api filters, for package/type/member rename/signature changes
No longer required for API descriptions.
*** Bug 267087 has been marked as a duplicate of this bug. ***
Created attachment 131672 [details] start This patch provides refactoring participants for reaming a type and / or a package. The default behavior of our participants is to simply remove the filter - while I was testing the fix I found that renaming, moving or deleting any types had the same net effect: the original type was removed (meaning the filter would be flagged as unused, even if updated) There is one problem with the proposed fix though: it seems that on an undo the resources are not back yet for us to recreate the filters on. Markus, is there any way we can ensure that our refactoring participants are run after all the rest? That way we could ensure the resource(s) have been recreated for us to recreate our filters on.
The refactorings proposed in the patch allow a lot of the filter detection code to be removed from our builder, which affects the incremental build world...
> Markus, is there any way we can ensure that our refactoring participants are > run after all the rest? That way we could ensure the resource(s) have been > recreated for us to recreate our filters on. Your participant can return the changes in RefactoringParticipant#createPreChange(IProgressMonitor). Those changes will be executed before the main refactoring runs, and on undo, they will consequently come after the main refactoring undos. > The refactorings proposed in the patch allow a lot of the filter detection code > to be removed from our builder, which affects the incremental build world... I'm not sure if I got that right, but I just want to stress that you cannot assume that all changes are made through refactorings. There are always cases where a user does a refactoring by hand (Copy/Paste), or manipulates the file system by other means (e.g. with external apps or via team operations). The builder needs to handle those changes as well.
> I'm not sure if I got that right, but I just want to stress that you cannot > assume that all changes are made through refactorings. There are always cases > where a user does a refactoring by hand (Copy/Paste), or manipulates the file > system by other means (e.g. with external apps or via team operations). The > builder needs to handle those changes as well. > Thats a good point, we were hoping to be able to remove the 'deleted type' code from the filter detection, but it looks like we need to leave it in for the cases you mentioned
Created attachment 131808 [details] updated fix updated patch using createPreChange(..) like Markus suggested (which works perfectly).
applied patch, please verify Olivier
Verified.
