Community
Participate
Working Groups
Build ID: I20080617-2000 Steps To Reproduce: 1.do "run as jad" on a MTJ Midlet project.(This step is a must, because we need generate a debug config) 2.rename the MTJ Midlet project(refactor->rename) 3.do "run as jad" on the project again. It will said "Could not find Application descriptor at ....." More information: We encounter this bug because the already exist debug config contains the JAD url information. If we rename the project, the Jad Url information in the debug config will not updated accordingly. A possible solution is: Adds a 'org.eclipse.ltk.core.refactoring.renameParticipants' extension to update debug config according project name changing. Walk around: Delete the exist "run as jad" debug config after project renaming.
Created attachment 110415 [details] Project rename Participant For JAD launch config
Reviewing patch
Hi Feng, First I would like to congratulate you about this contribution. The code is very clean, readable and using Eclipse API very weel. However I found a bug within it, that I think will be easily fixed. When the project is not inside the workspace, the JAD url information is updated to a wrong place inside the workspace. Steps To Reproduce: 1.Create a MIDLet project in a location outside the workspace. 2.Follow steps 1 to 3 from comment #1. The behavior will be the same described on comment #1. Another point I've noticed is that the "undo" change doesn't seem to be necessary, as JDT seem to delete any debug configuration associated with a project if this project is renamed and then the rename is "undone". Can you address this issues?
Created attachment 111447 [details] version 2 - fix bugs Hi Hugo, Thanks a lot for your carefully review. I made two change in this new patch: 1. Fix the bug you identified. 2. Return null in JadLaunchConfigProjectRenameChange#perform(IProgressMonitor) method, as you suggested. This makes the rename operation Not undoable. If we don't return null(like first version patch), after performing undo, the debug config file disappeared in the workbench but still on the hard disk, without any undo change. So make it not undoable makes more sense. Thanks, Feng
Hi Feng, I've just reviewed and commited the new patch. The fix will be available on next NB. I've checked the bug described on comment #3 and it is not happening anymore :) However, I would like to better discuss the "Undo" issue. I don't think removing the 'undo' support is a good approach, as projects renames for projects that don't have an associated JAD launch config can still be undone. I'd prefer returning a NullChange that does nothing with the JAD launch config (as it is removed from the workbench) than returning null and removing the 'undo' support.
Hi Hugo, I find JDT have bug on launch config refactoring(see bug 244395). Our rename refactor participant relay on JDT rename refactor participant. I try to fix bug 244395 and modify our participant(on my local workspace), then it can be undo/redo. If JDT guys fix the bug, then we can modify our code to introduce the undo/redo ability. I also tried to just return a NullChange. After perform undo, the launch config is "removed" from the workbench but the corresponding config file are still on the hard disk(located at \%WORKSPACE_ROOT%\.metadata\.plugins\org.eclipse.debug.core\.launches). This is because JDT rename refactor participant don't perform undo correctly(It should undo the "project name" and "listEntry" property change in the launch config, but it didn't). When perform undo, JDT will delete Java application launch config file on lcoal file system, but won't delete our JAD launch config. Another option is we do (in our rename refactor participant) what JDT rename refactor participant should do. But it will be complex and if JDT fix the bug, we should change the code again. So I prefer leave the code as it is until JDT fix the bug. Thaks, Feng (In reply to comment #5) > Hi Feng, > > I've just reviewed and commited the new patch. The fix will be available on > next NB. > > I've checked the bug described on comment #3 and it is not happening anymore :) > However, I would like to better discuss the "Undo" issue. > > I don't think removing the 'undo' support is a good approach, as projects > renames for projects that don't have an associated JAD launch config can still > be undone. I'd prefer returning a NullChange that does nothing with the JAD > launch config (as it is removed from the workbench) than returning null and > removing the 'undo' support. >
Ok Feng, I agree with this approach. Lets keep the patch "as is" and wait until JDT fix their bug. Then we file another bug against MTJ.
all bugs we integrated and release on MTj 0.9
