Community
Participate
Working Groups
Build Identifier: 20110615-0604 Very similar to bug 19854, if you delete a project, then create a new one with the same name the launch configurations from the previous project appear in the launch configuration list, even though some options may be irrelevant to the new project. Note that this occurs even if the "Delete project contents on disk" option is selected. Also note that the launch configurations do not show in the list until the new project by the same name is created. Reproducible: Always Steps to Reproduce: 1.Create a project. 2.Launch it, remember name of launch config. 3.Delete project including contents on disk. 4. Note launch configuration is not listed 5. Create new project with same name. 6. Note launch configuration IS listed.
What kind of configuration is it? What is the state of the Run/Debug > Launching > Launch Configurations > 'Delete configurations when associated resource is deleted' option? What are the filtering options set to in the launch dialog? > Also note that the launch configurations do not show in the list until the new > project by the same name is created. Depending on your filtering settings in the launch dialog you can make them show up again (without re-creating the project). You can change these options directly in the launch dialog and from the Run/Debug > Launching > Launch Configurations preference page.
This was a Java project, but we've seen the same kind of behavior in a C (CDT/DSF) project. But you're absolutely right, there's a preference for "Filter configurations in deleted or missing projects" and it's selected (by default?). So this means that the "hide" part of this bug's description is only by default. The problem then remains that orphaned launch configurations persist. Which is interesting because it appeared that duplicate "Bug 19854 - Deleting project does not delete associated launch configuration" and its indirectly duplicated "Bug 12746 - refactoring support for launch configurations" had fixed exactly that. Perhaps not? Thanks for the clarification!
(In reply to comment #2) > So this means that the "hide" part of this bug's description is only by > default. The problem then remains that orphaned launch configurations persist. > Which is interesting because it appeared that duplicate "Bug 19854 - Deleting > project does not delete associated launch configuration" and its indirectly > duplicated "Bug 12746 - refactoring support for launch configurations" had > fixed exactly that. Perhaps not? Yes and no - depending on the type of launch configuration there might not be any resources associated with it; meaning we might not be able to compute if the containing project (resource) had been closed / removed. It is up to the provider of the launch configuration to decide what resource (if any) are associated with the launch configuration. For example the Java Application configuration has a main class (.java file) and possibly a project associated with it, as for CDT I don't know if they provide a resource mapping or not. The filtering is working as designed, closing as worksforme.
Perhaps I logged this bug in the wrong category, but this remains a problem, though it's not with filtering. I agree that filtering appears to be working well -- this is probably a problem with incomplete project deletion. Sorry I wasn't clear at first. The problem is specifically that launch configurations are not deleted with their corresponding projects. Such orphaned configurations are then by default not shown (no harm), but if there's a new, different project with the same name they will be automatically associated with that project, which may be incompatible, possibly in obscure ways, causing confusion when debugging (harm). Reopening essentially the same problem as in bug 19854, which was supposedly fixed (by fixing it's duplicated bug), but apparently was not, or has regressed since then. That bug was logged against Eclipse Platform, Debug as this one is, but please reassign if appropriate! By the way, there was a comment in a related bug about storing launch configurations in the individual projects' meta-data instead of in the workspace's. That would seem to be a nice solution, but I don't know if there are other consequences of relocating them. Thanks, Ken
(In reply to comment #4) > Perhaps I logged this bug in the wrong category, but this remains a problem, > though it's not with filtering. I agree that filtering appears to be working > well -- this is probably a problem with incomplete project deletion. Sorry I > wasn't clear at first. > From comment #1: "What is the state of the Run/Debug > Launching > Launch Configurations > 'Delete configurations when associated resource is deleted' option?" If you turn on that option launch configurations will be deleted when their associated resource is deleted. This option is *not* on by default.
Well, I stand corrected. You're absolutely right, I was looking at the wrong preference. The launch configuration is correctly deleted when the preference is checked to "delete configurations when associated resource is deleted". Thanks for your patience and clear explanation (twice)!
(In reply to comment #6) > Thanks for your patience and clear explanation (twice)! No worries, thanks for reporting back.
