Bugzilla – Full Text Bug Listing
| Summary: | [plan item] Support Java references outside Java code | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Jim des Rivieres <jeem> |
| Component: | UI | Assignee: | JDT-UI-Inbox <jdt-ui-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P4 | CC: | burner, danjou, david_williams, dirk_baeumer, eclipse, eichelberger, fmoraes, gsturov, john.arthorne, kbahn, kehn, l.bolzani, m.a.r.k, mariano.kamp, markus.kell.r, stijn.vanpoucke, thorsten.van.ellen |
| Version: | 2.1 | Keywords: | plan |
| Target Milestone: | 3.0 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 44178, 45130 | ||
|
Description
Jim des Rivieres
*** Bug 36940 has been marked as a duplicate of this bug. *** Comments from John Arthone regarding the refactoring proposal: One small comment I have on this proposal is that it doesn't mention participation in deletion. I know deletion isn't traditionally considered a refactoring, but it is closely tied to the behaviour of move and rename. We have had frequent requests for adding hooks to move, rename, and delete for clients that have a cluster of related files that must change in unison. For these cases, deleting a single file in the group should automatically delete all files in the group. Refactoring participation would be one way to achieve this. John, thanks for pointing this out. The refactoring proposal didn't menition all refactoring that we want to convert to processor/participant architecture. Must generic refactorings are rename, move, delete. Furthermore the "Java" specific refactoring change signature must be converted as well since it might effect JSP, SQUlJ, ... files as well. Futher candidates are: inline method, introduce parameter, self encapsulate field, ... Comments from Valentino Kyriakides <vkyriakides@web.de>: Hi Dirk, I've just took a first rough view on the proposal and thus will some day later respond to that in more detail. However, a first quick thought for an addition would be a possibility to exclude/hide specific marked/signed java sources (compilation units) from refactorings at all. This would be an important issue for automatically generated java compilation units via generators and the like. 1) A sketched scenario: Say you usually would have some sort of none java source model (file) as input for a generator, which in turn then creates/generates the corresponding java compilation units according to the settings inside the none java input sources. Now the problem is, that you might want to perform custom refactorings (via processors/participants) on the generator source models (the generator input files), but prevent refactorings to also work/touch the generator created java output sources. AFAI can see, there is no direct reusable capability inside Eclipse to allow just the compilation of java compilation units, but prevent the refactoring for certain selected java compilation units (?). During our tryouts by marking generator based java output as read only or using Eclipse filters etc. we were not able to address these refactoring related issues. 2.) I don't know if the proposal already addresses this (?), but the refactoring participants should also be generic enough to be usable in a two way manner, e.g. by first selecting/performing a foreign source model refactoring and afterwards performing any possible needed related java restructurings. What I mean is, instead of "JAVA -then-> NONE JAVA" refactoring flow it might be sometimes also desirable to perform the opposite direction "NONE JAVA -then-> JAVA" refactoring flow. - Even I think that technically, hidden under the hood and for end users in a suggestive manner, "NONE JAVA -then-> JAVA" can also be performed just via the "JAVA -then-> NONE JAVA" way. However, it might be generally interesting to see how to address such two-way direction refactorings... Greetings Valentino Valentino,
regarding your comments:
- the problem with the generated source is IMO independent from the processor/
participant problem. It exists for normal refactorings as well. So I opt to
open a separate PR for that issue. One quick remark for the
processor/participant architecture: if we can guarantee a specific ordering
then a processor would update the files and the "generate" participant would
regenerate the file. So the system stays consistent, but some updates have
been done twice.
- regarding NONE JAVA -then-> JAVA versus JAVA -then-> NONE JAVA. The decribed
architectures support both ways although JAVA then NONE JAVA case is always
easier to implement. The JAVA then NONE JAVA case can be implemented using
a participant, the NONE JAVA -> JAVA case must be implemented by a specific
processor. Consider the case that we have a type reference in a plugin.xml
file. A rename operation can be implemented in the following way:
o the selected type (in String form) is converted into an IType and the
rename operation is triggered using the IType object. The plugin.xml file
is updated by a corresponding participant. As said this is the preferred
solution.
o there is a special rename processor for plugin.xml file. This processor
takes care about the updating of the plugin.xml file. It also takes
care about refactoring the Java type. This is is best done by delegating
the job to the rename type processor. This is the more complex
solution and requires a deeper understanding of the whole processor/
participant architecture.
The property evaluation mechanism outlined in the proposal (http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt-ui- home/r3_0/proposals/refactoring/participants.html) is useful for other clients. It should be pushed down from the refactoring, and ideally outside a UI plugin. The general purpose navigator (bug 36961) will likely want to make use of the property evaluation to replace the IActionFilter mechanism used in the current prototype. IActionFilter is too rigid since it is based on adapters. There is no way to define additional tests. The property evaluation would solve this. With CM providers like ClearCase, which by default shows a dialog box prompt when checking out files, each participant will show it's own ckeck-out prompt, which is kind of ugly. I guess this can be solved by making IChange object return files/resorces it is going to change, so Processor could collect all resouces involved in the refactoring action and check them out in one shot. *** Bug 41461 has been marked as a duplicate of this bug. *** *** Bug 41462 has been marked as a duplicate of this bug. *** *** Bug 43343 has been marked as a duplicate of this bug. *** *** Bug 44178 has been marked as a duplicate of this bug. *** *** Bug 44179 has been marked as a duplicate of this bug. *** What is the current design/plan to support generic refactorings? I have made a refactoring that inserts code into methods. How would I move it to the new architecture? Is this still TBD? I don't know if this is the place, but I would like to see Code Completion and all the stuff in the Java code inside CUP and JLEX files. What do you say? Regarding comment #14: this PR addresses the problems that Java elements are referenced outside "normal" Java files and that those references should be considered during search and refactoring. If you want to reuse code completion for files that embedd Java code you must first translate the file into a Java CU, activate code assist and then map the result back to your file. For 3.0 there are now two new plug-ins providing refactoring API and participants support (ltk.ui and ltk.core) together with a set of corresponding extension points. The rename move and delete refactorings in Java have been converted to support participants. For search JDT/UI now provides a extension point to added query participants to search queries allowing to present matches to Java elements no located in Java source files. *** Bug 320715 has been marked as a duplicate of this bug. *** |