Bugzilla – Full Text Bug Listing
| Summary: | refactoring support for launch configurations | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Carolyn MacLeod <carolynmacleod4> |
| Component: | Debug | Assignee: | Darin Wright <darin.eclipse> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P2 | CC: | alex.blewitt, alvin, andy.w.freeman, Darin_Swanson, dirk_baeumer, erich_gamma, h_heinecke, jaeger, lynne_kues |
| Version: | 2.0 | ||
| Target Milestone: | 3.0 M8 | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
|
Description
Carolyn MacLeod
Do not intend to address for 2.0, this is really a refactoring issue. This is a pretty bad problem, particularly if "single-click launch" is on by default (which, I understand, it should be and will be). So if this is a refactoring problem, we should let the refactoring people know. CC'ing EG. I agree it is a problem, but not a common one. How often do programmers usually change the name of their main class? I argue that is is not often. The old launching support did not handle this problem well either - it deleted the history item rather than updating the launch history item. I rename main classes all the time - it is very common for me to do this. I start with a little example swt class, copy it, rename the copy, modify code, and run the new (renamed) class. I never had a problem with the old stuff. The very first drop I run in with the new stuff, and I have a problem that is a real pain to work around - I had to turn off single-click, run, get the dialog, make the changes, save the changes, and turn single-click back on. If I didn't know the option existed (most newbies won't), I would have been completely and totally stuck, unable to run my class, and with no idea why not, or what to do to work around it. This is worse than I thought. I can't turn single-click back on and then run the class. i.e. My main class that is in a new package will never run again under single-click. It insists on trying to go back to the original (bogus) package name. At least fix this. If someone modifies the launch configuration, please honour that modification if they turn single-click back on. *** Bug 35962 has been marked as a duplicate of this bug. *** Re-opening for 3.0. We plan to plug into the JDT refactoring support. *** Bug 17453 has been marked as a duplicate of this bug. *** *** Bug 32009 has been marked as a duplicate of this bug. *** FYI - Dirk is using this the launch config updating as a use case for refactoring participants. *** Bug 32009 has been marked as a duplicate; however, bug 32009 describes the fact that removal of a project does not remove the launch configs as well. Not sure whether that's precisely the same as this bug, or whether they will both be actioned by the same fix, but before verifying the duplicate I'd just like to add this comment in the older bug. *** Bug 41030 has been marked as a duplicate of this bug. *** *** Bug 44317 has been marked as a duplicate of this bug. *** *** Bug 45961 has been marked as a duplicate of this bug. *** *** Bug 48037 has been marked as a duplicate of this bug. *** Released some refactoring support for launch configurations. The launch configurations are updated for : - project renaming - Java type renaming - Java file (compilation unit) renaming (will work after a one line fix in the compilation unit processor) Luc, is this complete, or is there still some work in M8? JDT.DEBUG.UI should listen to package renames as well. And to moves of CUS and types as soon as move participants are implemented which will be the case with M8. Released support for package renaming. Please verify, Darin W. I create bug 54557 for the 'move type' case. Changes in org.eclipse.jdt.internal.debug.core.refactoring and jdt.debug.ui plugin.xml. Verified. |