| execution order of refactoring participants (or their changes) [message #256133] |
Fri, 05 September 2008 12:28  |
Eclipse User |
|
|
|
Hi,
we're having a participant attached to the
org.eclipse.ltk.core.refactoring.renameParticipants, to participate in a
rename-package refactoring.
The JDT refactoring renames the directories and all references to the
package (e.g. in Java files), which is fine.
Our participant wants to adjust some more references, in some cases in the
same files that are already touched by the JDT participant.
Unfortunately, the JDT changes and our changes to these same files are not
grouped together -- they are carried out into two separate changes. And now
that we have two separate changes (first the JDT changes, then ours), we
have the problem that the JDT refactoring already renames the resources
before our changes can be applied to them.
So my question is: how could we make sure that our changes are applied
before the resources are moved away under our feet.
Ideally I would think that the framework would merge these changes belonging
to the same resource and execute the rename-change last.
Thanks for any hints,
Carsten
|
|
|
| Re: execution order of refactoring participants (or their changes) [message #256168 is a reply to message #256133] |
Mon, 08 September 2008 07:18  |
| Eclipse User |
|
|
|
On 2008-09-05 18:28, Carsten Pfeiffer wrote:
> So my question is: how could we make sure that our changes are applied
> before the resources are moved away under our feet.
See the Javadoc of
RefactoringParticipant#createChange(IProgressMonitor). It tells that you
can use RefactoringParticipant#getTextChange(Object) to add your text
edits to an existing change. As argument, use the ICompilationUnit (or
an IFile).
Note that participants must ensure that their changes don't conflict
with the changes generated by the refactoring processor. This is not
trivial, since the rename package processor does not (and will not)
specify what exactly it changes in .java files.
That being said, you might try it by using
org.eclipse.jdt.internal.corext.refactoring.changes.TextChan geCompatibility
(make a copy, since this is internal code, and catch the
MalformedTreeException).
HTH,
Markus
|
|
|
Powered by
FUDForum. Page generated in 0.04755 seconds
Home