| Summary: | Changing our refactoring capability to use the LTK refactoring framework | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [WebTools] WTP Java EE Tools | Reporter: | Hari Shankar <hshanka> | ||||||||
| Component: | jst.j2ee | Assignee: | Hari Shankar <hshanka> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | Chuck Bridgham <cbridgha> | ||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | ccc, david_williams, hjzhang, jsholl, kaloyan | ||||||||
| Version: | 3.0.3 | Flags: | cbridgha:
review+
|
||||||||
| Target Milestone: | 3.0.4 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows XP | ||||||||||
| Whiteboard: | |||||||||||
| Bug Depends on: | |||||||||||
| Bug Blocks: | 261555 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Hari Shankar
Created attachment 122018 [details]
patch
Reviewing now.... This is big enough, and does technically involve UI changes, so a PMC review is required. Carl - can you handle announcing this change? PMC Review requested due to UI change Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. At present there is no way to provide a preview of refactoring changes to Java EE modules, and there are gaps in our support of refactoring. By changing to the LTK framework, we get a preview and we become more consistent with the way that base Eclipse handles refactoring. This has requested by adopters and users. Is there a work-around? If so, why do you believe the work-around is insufficient? The current refactoring support is not sufficient- there is no preview capability (and it would be nearly impossible to add), and it has some gaps in its support (such as leaving the EJB client after deletion of the EJB project) How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? This fix has been tested by hand. Give a brief technical overview. Who has reviewed this fix? The change is simple to explain- we are converting our refactoring from our DataModel framework to the LTK framework, which works better and displays a preview UI to enhance the user's understanding of what is about to happen. Chuck Bridgham reviewed this fix. What is the risk associated with this fix? Low risk - we are utilizing the LTK framework. The biggest hit here would be to documentation (and not translation, since we are just exposing an existing UI). Carl, Hari, this sounds to me more like an enhancement that everybody would appreciate in the Galileo release, but not like a stop-ship defect for the Ganymede release. Is there an adopter's business case that is blocked by this change (in this case the bug should be promoted to hotbug) or this is just a general improvement for WTP? Although I don't have anything concrete in mind, I'd like to ask the following question: are we sure that there is no adopter which relies on the current refactoring tool and extends it with own functionality? (the Data Model Framework enables good level of extensibility) If there is such an adopter, I thing there is a good chance that we break them. Just wanted to provide some more background on this patch. Justification behind requesting inclusion of patch in this milestone: 1. This patch fixes some issues that are causing complaints in adoptor product - specifically, when an EJB client project is deleted, the corresponding entry is not removed from the ejb-jar.xml, causing subsequent migration issues. 2. There are scenarios where when an EJB project is deleted, the corresponding client project is not deleted. 3. Customers of adopter product are requesting for a way to view and choose what changes are being made as part of refactoring. Also, we have unhooked our old listeners from the PRE_DELETE event, but are not deleting any of the old code as part of this patch. So, whenever a Java EE module is deleted, the new code will get called, however, any users of the old Data Model framework operations can continue to use them. If allowed permission to release this code, we will also thoroughly test this code as part of adopter test cycle in the first week of february. Created attachment 122566 [details]
udated patch
Updated the patch to limit to module deletion refactoring changes. Patch attached.
Requesting not to vote on this bug yet - I will provide a patch with much smaller impact, very soon. Created attachment 122974 [details]
patch
Patch with all the LTK refactoring moved to adopter code. This patch checks for a system variable, and if set, removes the hooks that trigger the existing Datamodel framework code. This system variable will be set in adopter product. In the absence of the system variable being set, old behavior is preserved.
The overall refactoring to reuse the LTK is being moved to WTP 3.1 (see bug 261555). As such, with Hari's latest patch, PMC approval is no longer required, and: Adopters can specify a product preference that will disable the current DataModel refactoring (and thus allow adopter products to add in their own refactoring processing) However, please note that in WTP 3.1, LTK factoring will become the default refactoring processing mechanism. (And please add comments therein as applicable.) thanks guys, it's important to minimize potential side-effect impacts in maintenance release. This really looks much much saver. I am just curious about something and would appreciate if clarified. Why for the switch in the behavior is used a system property and not a plugin preference? Is there any special reason behind this? I accidentally removed the request for Chuck's review when I removed the PMC request- re-adding it now. approve this change.... system property is used in practice more than plugin pref for product overriding behavior Committed to R3_0_maintenance for 3.0.4 |