Bug 111462 - [API] Public api for Refactoring processors ...
Summary: [API] Public api for Refactoring processors ...
Status: RESOLVED INVALID
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.1.1   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: JDT-UI-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: needinfo
Depends on:
Blocks:
 
Reported: 2005-10-04 11:21 EDT by Vikas Trivedi CLA
Modified: 2009-08-30 02:08 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vikas Trivedi CLA 2005-10-04 11:21:34 EDT
We are using internal jdt calls to provide support for refactoring java
elements. JavaRenameProcessor, MethodChecks, RenameCompilationUnitProcessor,
RenameFieldProcessor, RenameJavaProjectProcessor,
RenameNonVirtualMethodProcessor, RenamePackageProcessor,
RenameSourceFolderProcessor, RenameTypeProcessor & RenameVirtualMethodProcessor
are being used. 

We couldn't find public API to replace this usage.

This is blocking our effort to remove access to JDT internal source.
Comment 1 Martin Aeschlimann CLA 2005-10-05 09:50:56 EDT
Please give more details why you use these classes. 
Comment 2 Martin Aeschlimann CLA 2005-10-08 12:57:13 EDT
Setting to 'remind' while waiting for more information.
Comment 3 Vikas Trivedi CLA 2005-10-12 10:07:09 EDT
We have use cases when we indirectly (programmatically) trigger rename
refactoring (without using the "Refactor ... Rename" menu or the wizard). To do
this, based on the element type we instantiate one of the Rename Processors
which we need to pass as an argument to the RenameRefactoring(..) constructor. 

ex. if selected element is a CU we use RenameCompulationUnitProcessor, for Field
we use RenameFieldProcessor etc

We're using MethodChecks to access the isVirtual(..) method but we can replace
its usage with our own utility method. However the methods in this class are
fairly handy and it would be useful if we made it API.
Comment 4 Martin Aeschlimann CLA 2005-10-12 10:23:14 EDT
Dirk, can you respond?
Comment 5 Dirk Baeumer CLA 2005-10-12 11:08:06 EDT
Vikas,

can you please comment on why the API class RenameSupport, which is designed to
do this, doesn't work for you ?

One additional question: when you create the processor are you executing them
directly or via a RenameRefactoring. Directly executing them by passes
participant loading.

MethodsChecks will very likely never become API in the UI layer. It is pure core
functionality and if a plug-in provides such API it should happen in JDT/Core. 
Comment 6 Vikas Trivedi CLA 2005-10-12 14:12:39 EDT
(In reply to comment #5)

Ok ... my fault ... I think RenameSupport will work. I believe we started using
the internal processors before RenameSupport was born. 

Regarding MethodChecks ... i can add my own utility method. Any idea if jdt core
ever considered providing something similar?
Comment 7 Denis Roy CLA 2009-08-30 02:08:09 EDT
As of now 'LATER' and 'REMIND' resolutions are no longer supported.
Please reopen this bug if it is still valid for you.