Bug 570556 - better handling of run configuration with missing or closed project
Summary: better handling of run configuration with missing or closed project
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Debug (show other bugs)
Version: 4.18   Edit
Hardware: PC Windows 10
: P3 normal with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: Platform-Debug-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-01-21 13:57 EST by T. Orf CLA
Modified: 2021-01-22 05:41 EST (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description T. Orf CLA 2021-01-21 13:57:50 EST
When a launch fails due to a missing or closed project, it is added to the Debug view and cannot be removed any more.

Steps to reproduce:
- Create and start a run configuration of type "Java Application".
- Close its referenced project.
- Try to start the run configuration again. (The "Run configurations..." dialog does not allow it, but the "Run Last Launched" command and the "Run -> Run History" menu do.)

Not a big problem, but here's why it matters to me:
- I produce such garbage quite often, because I use different Eclipse projects for different versions of the same software project (e.g. git repository). (Instead of a `git stash save`, `git checkout other_branch` workflow, I often prefer to use multiple git clones and multiple Eclipse projects.) Therefore, the run configurations I last used in Eclipse project "myrepo-1" are perfectly fine for project "myrepo-2", only the assigned project needs to be changed. Also, unless I duplicate run configurations and include the project name in its name, the "Run -> Run History" menu does not show the project.
- When I deliberately keep some correct launches open and close others, the failed ones can get distracting. The only way I found to get rid of them is to restart Eclipse; but of course, that is not an option as long as I still need those good launches.

(1) A minimal fix would be to just treat such a launch like a usual terminated and hence removable one in the Debug view.

(2) Even better, like the "Run Configurations" dialog already does, maybe all ways to start such a run configuration should be disabled in the first place. Menu items should be grayed out. Command "Run last launched" (when invoked via a keyboard shortcut) should show a warning dialog (*not* just start the most recently used valid run conf, IMO, because that would be too surprising or even dangerous).

(3) Better yet, if one or more open projects' classpaths contain the run configuration's main class, prompt the user whether to update the run configuration. Something like such a dialog:
| Run configuration … references closed or missing project …,          |
| but the following project(s) also contain class ….                   |
| <list of matching projects, with the current - if any - preselected> |
| Change run configuration to reference this project?                  |
| [&OK] [OK and &edit] [Cancel]                                        |
[OK] would update the run conf and immediately launch it; [OK and edit] would update it and enter the "Run configurations" dialog.

Nice to have: Also append " (<project name>)" to run configuration names in menus ("Run History" etc.).
- This would be most useful in solution (2) to quickly understand why some "Run History" menu entries are grayed out.
- Also very useful in (1) so the user does not start it only to get the "Problem Occured - Launching … has encountered a problem. Launch configuration … references a closed project …." error dialog.
- But even when (3) would handle "bad" run configurations gracefully, it might still be useful to show the project. For example, you could easily see that you didn't start something since switching to the currently open project.

BTW, all of this applies to other types of run configurations besides "Java Application": "JUnit", and probably some more.
Comment 1 Sarika Sinha CLA 2021-01-22 01:25:52 EST
Will you be able to work on this?

Unfortunately we don't have bandwidth to take up this.
Comment 2 Rolf Theunissen CLA 2021-01-22 02:35:29 EST
Related to this is Bug 565708, where name collisions between launch configurations occur with a deleted project. The more advanced solutions could possible solve both issues.
Comment 3 T. Orf CLA 2021-01-22 05:41:10 EST
(In reply to Sarika Sinha from comment #1)
> Will you be able to work on this?
> 
> Unfortunately we don't have bandwidth to take up this.

No, sorry.


Oh, and I should add that I think that besides closed or missing projects there have been other ways to get such broken launches. But not sure, my current attempts to reproduce it all produced nice, deletable launches:
- a misconfigured JVM (-javaagent option whose agent jar is no longer there)
- using VisualVM Launcher while the program in preference "VisualVM Executable" no longer exists
- External Tool Configuration uses ${resource_loc}, but fails with "Variable references empty selection: ${resouce_loc}"
- program in External Tool Configuration -> Location no longer exists

If anyone knows of other ways to get a broken launch, that might mean that my proposed minimal fix (1) should be done in any case. Detecting such a problem in order to disable a menu item (2) may not be possible. And the Java-specific enhancement (3) should then be another issue.