Community
Participate
Working Groups
Build ID: M20070921-1145 Steps To Reproduce: 1. start eclipse, point to a new workspace (never used before, i.e. no .metadata folder) 2. go to window->preferences->string substitutions 3. add a new variable 4. export preferences with file->export->preferences 5. close eclipse 6. start eclipse, point to a new workspace (never used before, i.e. no .metadata folder) 7. import just exported preferences with file->import->preferences, select "import all" 8. go to window->preferences->string substitutions 9. the created variable with then correct value is there 10. restart eclipse 11. go to window->preferences->string substitutions 12. the variable is lost More information: If the variable is edited after an import an saved unchanged, the variable is preserved after restart The behaviour does not only apply to string subtitution variables but also to installed server runtimes of WTP. It's the same with the installed server runtimes - when they are edited and saved unchanged, they are preserved after restart. see also bug #95490
This is still a problem in build M20071017-0800 but is fixed in build I20071017-1638. I don't believe we have made any changes in the low-level preference code... Darin is there something in the Debug space that might affect this?
Note: Problem exists in 3.3.0 as well. Not a 3.3.1 regression.
The only thing that changed in the org.eclipse.core.variables plug-in since 3.3 is compiler settings, which will (should?) not affect the persistence of variables.
When the preferences are imported, the string variable manager recognizes the property change and updates the preference page and it's cache properly. However, using 3.3.1, when Eclipse is shut down, the preferences file .metadata\.plugins\org.eclipse.core.runtime\.settings\org.eclipse.core.variables.prefs is never written out. So the next time Eclipse is started, no saved variables are found. In 3.4 the file is written out properly on shut down. I do not know what changes are causing this difference (there are no changes to the core variables plugin). Perhaps Platform-Runtime can comment?
Tod, do you know what might be the cause here? We haven't made any changes in the prefs code in that timeframe either. So I'm thinking maybe a preference page thing?
No changes in our code either - we would have to look at what the preference page itself is doing
How quickly we forget... :-) *** This bug has been marked as a duplicate of bug 195073 ***
I do not believe it is a duplicate of bug 195073. Actually this bug covers bug 195073 comment 45 point 3. I think this bug should be reopened.
Reopening as requested
Moving to Platform/UI as per bug 195073 comment 45 item 3.
We are also seeing this issue, but in 3.2.x stream. We (WTP J2EE tools) started implementing an IPropertyListener interface after reading related comments, to serialize our preferences specifically. This fails because we can't control what plugins are loaded at import time. I know way back the preferences import was located in the dialog itself, and wasn't an issue because they were saved when applied.
Raising the severity because of adopter customer issues with sharing preferences
I spend most of my time investigating preferences now. It seems that fix for bug 195073 fixes also this bug (the fix just saves preferences after import, so there is no way we can lost them). Sadly, fix was targeted for 3.4 m2 milestone, and is not available in any release earlier than r3_3_1_1 (including).
You should request that Bug 195073 is also ported to 3.2.2 then
fixed by bug 195073 PW
