Bugzilla – Full Text Bug Listing
| Summary: | Launch file is automatically saved when not modified | ||
|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | James Synge <james.synge> |
| Component: | UI | Assignee: | PDE-UI-Inbox <pde-ui-inbox> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | backhous, balajik, darin.eclipse, philippe_mulet, schacher, sja.eclipse |
| Version: | 3.3 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
James Synge
There are cases where launch files will get touched without the user doing anything intentional. For example, when the launch dialog is opened on a config and a tab adds/removes something to/from a config, the dialog saves the config right away so that the dialog will not prompt to save changes to a config that the user has done nothing to, except open. This happens between releases and milesontes of Eclipse as new options area added to configs and tabs, etc. If this is the case, then problems will settle out after everyone migrates to the same Eclipse version. If you have a specific scenario where a config is being modified, please let us know the specific problem. Launching a config should not modify the config (at least the configs provided by the SDK are not modified when launching). With that said, it would be useful if we persisted config attributes in a reliable order so it is easier to see incoming/outgoing changes. I've finally installed the XML compare example, so I hope to be able to give you a better answer soon regarding whether there are completely unnecessary changes, or just the implicit ones you mention. +1 for a resolutionn in the 3.3 time frame, although I realize that time is short. At least being able to do a sensible compare would help a lot. The fact that the XML is not formatted for human reading exasperates matters... it would be far better if the XML was formatted such that the compare editor has a chance of showing what really changed. Just my 2 cents, thanks. Another +1 for a resolutionn in the 3.3 timeframe. James, do you know why the launch file is being changed? Or do you have a test case for us? Darin, I just looked in my list of "changed files", and found a JUnit plug-in test launch that I had probably looked at, but not executed, nor had I (deliberately) edited. Comparing the before and after versions, I see that the change (besides re-ordering of elements) adds these two lists: <listAttribute key="org.eclipse.debug.core.MAPPED_RESOURCE_PATHS"> <listEntry value="/com.ibm.team.repository.service.tests"/> </listAttribute> <listAttribute key="org.eclipse.debug.core.MAPPED_RESOURCE_TYPES"> <listEntry value="4"/> </listAttribute> There were no other changes to the file (i.e. the pde.version did not change). I double checked by reverting to the old version of the file, opening the launch in the Run... dialog, viewing all tabs, and closing. The file was changed exactly as described above. I can understand an automatic upgrade that changes the set of attributes stored, and would find it much easier to recognize that this has happened if the elements weren't re-ordered, and if the pde.version were bumped. I think we could improve how the attributes of a launch file are written out to disk. Right now we just barf out a hashmaps' contents to xml, but it would be better if we oredered the attributes to allow changes in launchs under SC to be more recognizable. James, you should migrate all your launch configs to upgrade the resource mappings for the launch configs. The 'resource mappings' for configs has changed in 3.3, and if you go to the "Run/Debug > Launching > Launch Configurations" page and press the "Migrate..." button. This will let you migrate all your configs at once, rather than each time you look at one. Note - for 3.3, we don't plan to change the XML format of the launch configs. In response to comment 8, I tried to migrate my launch configs, as described by Darin using the Run/Debug preference page, but found that only my "Java Application" and "JUnit Plug-in Test" launch configs showed up as candidates for migration. I did not see any "Eclipse Application", "JUnit" or "OSGi Framework" launch configs, even though I have plenty of those. - Maybe only the launch configurations that need migrating are presented. - Maybe only the launch configurations that have opted in to migration are presented. This is very curious, since I just tried launching one of my "OSGi Framework" launch configurations and it was marked as dirty even when I did not change anything. Note that I ran the launch by opening the launch config dialog, selected the launch config and clicked Run. Reporter shows that Equinox/OSGi Framework configs appear as dirty after the launch dialog is opened on those configs. However, the configs do now show up as migration candidates. Can this be addressed for 3.3 ? The fix for bug 180756 now provides ordering for the launch configuration attributes. Michael, thanks very much! Using Eclipse 3.3 M5. Some more information regarding the dirtying of the .launch file... - We have an Eclipse Application launch config for launching an RCP application, and I noticed that when the .launch is opened in the Run dialog the file ONLY becomes dirty if you click on the Plug-ins page. - I believe that that Plug-ins page is shared by the Equinox and the Eclipse Application launch configs, so this is likely the reason why the .launch files are getting dirty. - I investigated further and found that the only difference between the original .launch file and the dirty .launch file was the order of the XML attributes AND the order of the plug-ins listed for the <stringAttribute> "selected_workspace_plugins". I would like to see the "selected_workspace_plugins" listed in alphabetical order. This will make it possible to compare two versions of a .launch file, but it will also make it easier for a human-reader to verify the contents. So Debug took care of the ordering of key/attributes when saving the file, which is unrelated but makes the diff easier to spot. As for the PDE issue (ie. Simon's observation in comment 14), this was the real problem and has already been addressed (bug 181512) Debug had a similar issue in falsely dirtying some tabs and this has also been resolved (bug 177988) As for Simon's questions in comment 9, PDE does not typically use the Platform's migration support. We automatically upgrade the launch configs when we detect when there is a need to. A couple of reasons: 1. So many things change in the runtime and Update over a release cycle, that if we ask people to migrate every time something changes, they will have to migrate 10 times on average. 2. The Migrate function is relatively hidden (buried on some Debug preference page). By the time someone finds it, we would see a million bug reports complaining that their existing launch configs don't launch anymore. So we go the extra mile to make sure existing launch configs continue to launch without the user noticing anything as the runtime/update change their story. In this case, there was some false dirtying of files going on and this has been fixed. *** This bug has been marked as a duplicate of bug 181512 *** Thanks, Wassim. All around, things are much improved. Thanks. |