Community
Participate
Working Groups
1) create a new plug-in project with an Activator 2) create a new package in your project 3) move the Activator to this package --> refactor is OK for Bundle-Activator in MANIFEST.MF 4) move the Activator to a package of another Java Project ==> gosh, refactor is done and the Bundle-Activator header now exposes the qualified name of the Activator in its new package The problem also occurs when moving out the bundle localization file, for example...
Implementing RefactoringParticipant#checkConditions() may be the solution to ensure a move should trigger refactoring (i.e. check that the target project is equal to the source project, and return a FATAL refactoring status if not).
I'm surprised someone like Jeff hasn't tried this yet to throw a wrench into PDE :) but yes, your solution sounds spot on Ben, thanks for looking into our refactoring code which needs some love :)
So let's fix it before Jeff can even notice the bug :) I can work on it. I've quickly tried to override checkConditions but it's not the good solution (if FATAL status the whole move operation is canceled ; if ERROR or less status, a dialog is shown displaying the potential errors, but the erroneous refactoring is still performed). Instead, I will perform the check at the beginning of the createChange method
Ahem, in fact we should decide what to do when moving resources outside a project: 1/ don't change anything (i.e. skip refactoring) in MANIFEST.MF/plugin.xml/build.properties... 2/ remove every piece of information associated to old resources (if Activator is moved out of the project then delete the Bundle-Activator header??? if localization file-->Bundle-Localization, etc. etc.)
FATAL should be fine... we should be able to check all the conditions before even refactoring. I talked to Martin who owns the LTK Refactoring stuff that he said that is the intended behavior.
OK, great! I can fix this bug. So, just to be sure, the behaviour will be 1/ create a new plugin project with an Activator 2/ *move* (drag&drop) Activator.java in the package of another Java project within your workspace 3/ the whole move operation is canceled (even if you selected other resources that could successfuly be moved out of your project), an error dialog indicates that the refactoring was unsuccessful.
(In reply to comment #5) > FATAL should be fine... we should be able to check all the conditions before > even refactoring. I talked to Martin who owns the LTK Refactoring stuff that he > said that is the intended behavior. Hold on, Chris talked to me, but I was not aware of the whole context. In this situation, I'd recommend that you detect the problem in checkConditions() and return ERROR if it occurs. FATAL should be reserved for situations where a refactoring really can't do anything and must be stopped to avoid further havoc (e.g. if the declaration is not writeable, classpath problems, ...). Here, it would be better to return an ERROR from checkConditions(). This way, the user gets informed about the problem, but if she decides that's not a problem for her, she's not blocked from moving the class. In createChange, you should just return null in this case (i.e. "nothing to add", says the participant). That's 1/ from comment 4.
(In reply to comment #7) > [...] Sounds good, thanks Markus :)
I've dumped comment 7 into the Javadocs of the RefactoringStatus constants.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This bug is marked as stale for some time. If it is still relevant for the current release, please reopen and remove the stalebug whiteboard tag.
