Community
Participate
Working Groups
Created attachment 77929 [details] Renamed failed Steps to reproduce: 1. Install Rational ClearCase SCM Adapter 7.0.0.20061206A in Eclipse 3.3.0 2. Create CC snapshot view and load a base ClearCase vob. 3. Launch eclipse 3.3.0 and switch workspace to a folder in vob loaded in the view mentioned in #2. 4. Connect to ClearCase from the ClearCase menu. 5. Create a java project in the Eclipse IDE. 6. Add the project to source control. 7. Use either the Java or Resource perspective. 8. Right click on the Java project and select Refactor -> Rename from the context menu. 9. Type in new name for the project. 10. Rename fails. Screenshot "Renamed failed" is attached. Initial analysis: This works in eclipse 3.2.2. Since the validateEdit/validateSave code has not changed, one can only come to the conclusion that Eclipse changed something and validateEdit is no longer being called... at least not in the same way as before... Found that the .project file DOES get checked out, but then the WRITE to the .project file FAILS. The CC Plugin does NO writing to files... that is Eclipse's job and THAT is what is failing. Probably, Eclipse is attempting to write before validateEdit has had a chance to do it's job.
Is there anything in your <workspace>/.metadata/.log file?
Created attachment 78119 [details] workspace log
Can't seem to find anything interesting in the log....
Moving to JDT for comment - do you catch exceptions (like the NPE in the dialog) without logging a stack trace?
All exceptions show in our exception dialog are also logged. I just verified this. So we should see something in the log. I don't have access to a ClearCase SCM Adapter and also not to clear case. I could not reproduce the problem with the pessimistic repository provider. Do you have any chance to run this in the debugger?
What *seems* to be happening is that validateEdit is being called AFTER eclipse attempts to write to the .project file because the scm state of .project is always "checked out" but the name of the project in the xml hasn't changed at all. IF you check out the .project file FIRST, and then rename, the error does not occur. This problem occurs in the Java perspective with the Navigator view and in the Resource Perspective using the Project explorer view.
I just verified that .project is correctly checked out by the rename Java project refactoring. However, rename in the Navigator or Project explorer is failing as there is no check-out happening. The two views use the ResourceNavigatorRenameAction. This doesn't explain the NPE, and it doesn't match step 8. 8. Right click on the Java project and select Refactor -> Rename from the context menu. Ok to move Platform to fix their rename project implementation?
John and/por Jao, could you please clarify if the steps from the description are accurate? Step 8 does not look like a menu item from the Navigator view.
If memory serves, when using the navigator view, it's just "Rename"
and to beat a dead horse, when using the Resource Perspective w/the project explorer, it is "Refactor->Rename"
Moving to CommonNavigator as I gather its specific to its action.
I'm not sure what to do with this. I don't have access to the software mentioned at the beginning of the bug report in order to reproduce this. I heard NPEs mentioned in this bug report, but there is no stack trace anywhere. Jao, can you reproduce this with 3.4? And if so, can you get me a stack trace of the NPE (perhaps by running in the debugger). Alternatively provide a set of steps where I can reproduce this using only the Eclipse stuff.
Closing because I have no way of reproducing this and no information about the NPE to fix it. If there is new information, please provide it and reopen.
