Community
Participate
Working Groups
Build ID: I20080516-1333 Steps To Reproduce: We are shipping a product based on Eclipse 3.4 and we have just ported to RC1. Our latest code drop has uncovered some very disturbing behaviour that I think you are going to hear people complain about. In particular, the preference to delete a launch configuration when its associated resource is deleted defaults to ON. This took me a while to track down what was going on here, but our launches were disappearing regularly and it was driving me insane. We ship a compiled language IDE and as a result users are doing a "Clean" on their projects regularly when they rebuild them. The launch configuration is associated with the executable that is deleted as a result of the clean, and with it goes the user's launch configuration. Our launch configurations contain a lot of information concerning connections to the embedded device, scripting, cached memory watches, breakpoints, etc. and it is being wiped out with no notification. I guess this is something somebody may want, but I would have thought the default behaviour to be the other way around (don't delete my stuff!). I realize we can override this preference in our product, but it seems like a dangerous default to me.
I'm inserting our product preference override and I just noticed that the preference name is "org.eclipse.debug.core.PREF_DELETE_CONFIGS_ON_PROJECT_DELETE". If this preference did what its name implies I would be all for this being the default. If the project is deleted there is no point in keeping the launch around. But it appears to just work off of all associated resources. Perhaps it could be augmented to check and see if the associated resource is also an instanceof IProject?
NOTE: I believe this was also the default setting in 3.3
You're right - it was the default in 3.3 as well but I just checked and the wording as well as the behavior has changed in 3.4. In Eclipse 3.3 it said: Delete configurations when associated project is deleted And now it says: Delete configurations when associated resource is deleted And it behaves differently than before which is causing me major grief. In fact, I am recalling a release because of it so I can put the default preference into our branding plugin. As I said - I don't mind the way it worked before when it just worked on the project, but deleting the launch configs whenever a user cleans/rebuilds their project output folder is just not useful. I am changing the bug description to more accurately describe my issue.
I just was looking at the source and found bug 197000. It is the fix for that bug has caused this issue. While I can see the use case there, it seems to me that the old behavior was better. We can have a project with multiple executables in it, each with a launch configuration. However, these executables come and go as the user cleans and rebuilds their project. Deleting the launch configurations as a regular part of the build cycle is not at all user friendly as they store all kinds of state and debugging configuration. Perhaps a better solution would be to have the launch configurations themselves participate in the deletion. Maybe they can be asked when deletion is appropriate? This would allow for both use cases to be met.
In this case, should the config be associated with the "build" artifact (executable) ? Or should it be associated with the source artifact that is used to generate the executable? Configs do have control over resource mappings. Having a resource mapping that depends on build state does not seem very stable.
How would you handle multiple outputs in the same project then? All of my executables would then be associated with the same (set of) source file(s). I realize we have control over resource mappings (we use them). It just seemed logical to us to associate a launch with the resources that were being used as part of the launch procedure (the executable code being downloaded to the device as part of the launch). Anything more complex than that would require the launch configuration to have intimate knowledge of build dependencies - which theoretically can change at any point in time. Then how would I keep this in sync with cached launch configurations? I would have to modify/update them every time the build dependencies changed, which seems more unstable to me as it involves way more "build state" than a simple executable name.
Not to harp on this (I am just hoping for the best solution and I am open to changing the way we map things...), but in a similar vein it seems to me that the current code will also prematurely delete a launch configuration if any one resource in the (potential) group of mapped resources is deleted. Wouldn't it make more sense to only delete the launch configuration if *all* mapped resources are gone? [As an aside, in the method #collectAssociatedLaunches(IResource), you may want to break after you add the launch configuration to the list. There is no point in continuing to iterate over the mapped resources after the config has been found applicable and added to the list.]
(In reply to comment #6) > How would you handle multiple outputs in the same project then? All of my > executables would then be associated with the same (set of) source file(s). I think this is a more specialized scenario than we able to handle. Obviously, with Java, users think about running their "main type" (.java file) from the IDE. They don't need to worry about the fact that a .class file is built for them. If you're creating N executables, each capable of being launched, then perhaps it does make sense to have the configs associated with those artifacts. In this case, I think you should just change the default setting for this preference. (In reply to comment #7) > Wouldn't it > make more sense to only delete the launch configuration if *all* mapped > resources are gone? > This may be true... the platform does not handle multiple resource mappings well in general... and we have not seen many use cases.
The question is - when should the config be auto-deleted in your scenario? How could the platform know when it is the right time do delete the config?
That is a good question. ;) For our particular case, it made sense to only delete them when the project was deleted as that is really when they became invalid/not useful. Hmm... I guess we *could* associate them with the project, but then we are back to being ambiguous. That's why I suggested perhaps the launch config could play a role in the deletion decision, but that is a naive idea as well because how does the platform know when to ask in the first place! Obviously this is not a trivial problem...
(In reply to comment #10) > That's why I suggested > perhaps the launch config could play a role in the deletion decision, but that > is a naive idea as well because how does the platform know when to ask in the > first place! Yes - it would require new infrastructure - like an extension point or attribute on the launch type to contribute a delegate that could do the right thing.
*** Bug 287206 has been marked as a duplicate of this bug. ***
Hello - I reorganized my projects and suddenly found that 20 of my carefully crafted launch configurations have been deleted. I will be able to restore them from backup, I hope - but this is unacceptable. I request hereby that the default setting on this preference be OFF. It's inconceivable to delete user data without showing a dialog or any warning at all. Data that I have entered myself, that I have spent time on creating, that I have put considerable effort into, cannot be deleted automatically. Ever. Certainly not by default. I don't know why you would delete launch configurations (rather than making them invalid) - but if this is useful for some people then these can find the preference and turn it on. I don't think this is a question. That's a very clear violation of expectations. What needs to happen is that those launch configs are made invalid, so I can go in and edit them. Here is my use case: Our project is very old, and has many modules - as many as 100. I cleaned up the project structure and merged one module into another one. Then I deleted the old module. Unfortunately the main launch file for the project was in the module that got deleted. No big deal, I could switch my launch configurations to the new unified project, which contains the same file, and the same code. Unfortunately though, due to the automatic deletion of launch configurations, they were all deleted already.
Note that there used to be a prompt for deleting configurations when the associated resource/project was deleted, but it was removed due to bug 150625. As there is no prompt, the default setting for this feature should be off (don't delete).
Created attachment 174750 [details] patch
Fixed.
Wow, that's what I call a quick turnaround time. I am impressed. Thanks!
Verified.
