Community
Participate
Working Groups
20030206 If you change the Task Tags preference and then export it it will not be set when you later import it. STEPS 1) Remove the TODO tag from the Task Tags page 2) Export your preferences 3) Reset the Task Tags page 4) Close the preference dialog 5) Reopen the preference dialog 6) Import preferences - you will not get rid of the TODO preference.
Moving to JDT/Core since it seems to have something to do with how values are stored in the preference store. After load the exported plugins the preferences returned form JavaCore via JavaCore.getOptions() has still the TODO value in it.
The problem seems to be in 'org.eclipse.core.internal.runtime.PluginExporter#exportPreferences()'. This method merge all prefences in globalPreferences. The method 'mergePluginPreferences' add the value of a preference in globalPrefences but the default value is not set. If the actual value is an empty String then this value is not add to globalPrefences because the default default value is an empty String. But for task tag the real default value is not an empty String. That's why task tag preference value is not exported.
Move to platform
Similar problem to bug 22533. By design, default values are not stored in the Preference store. So if you remove all your compiler tasks, then the value in the Preference store is an empty string. Later, Java core retrieves the value using the get(key, default) and since it doesn't exist, is returned the "default" which is "TODO". Recommend that the TODO task is not given to the user for free.
I still think there is a problem in PreferenceExporter. The preferences are correctly stored but the export fails. In my test case 'Task tag' value is "" and 'Task tag' default value is "TODO". In PreferenceExporte#exportPreferences globalPreferences is create and all default values in globalPreferences are "". When the current value of 'Task tag ' ("") is store in globalPreferences, this value is considered as a default value in globalPreferences. But this is not the default value for 'Task tag'. To avoid this problem i think the code of mergePreferences should be private static boolean mergePluginPreferences(IPluginDescriptor descriptor, Preferences preferences) throws CoreException { boolean found = false; IPath propertiesFile = InternalPlatform.getMetaArea ().getPluginPreferenceLocation(descriptor, false); if (propertiesFile.toFile().exists()) { Preferences pluginPreferences = loadPreferences(propertiesFile, new Preferences()); String pluginId = descriptor.getUniqueIdentifier(); String[] keys = pluginPreferences.propertyNames(); found = keys.length > 0; for (int i = 0; i < keys.length; i++) { String longKey = pluginId + PLUGIN_SEPARATOR + keys[i]; preferences.setDefault(longKey, pluginPreferences.getDefaultString(keys [i])); // This line is added preferences.setValue(longKey, pluginPreferences.getString(keys[i])); } } return found; } otherwise all the default values of the merged preferences are considered to be "". So all the preferences with current value of "" are lost, even if their default values are not "".
I was incorrect, this is not the same as bug 22533. There are 2 different problems here, one with the export and one with the import. In the export, the global Preferences object which is being used to collect the preference values to export doesn't know about the default values for the workspace. So the empty string is not stored because it is the same as the default-default. (and there is no default) That is why the resulting file does not include the key for the task tags. In the import, something similar is happening. But we have a slight problem. The only one who knows about the defaults is the preferences object on the plug-in instances. Which means if a plug-in is not activated yet then we can't get a hold of its preferences (and defaults) without activating it. So we need to consider a different approach since activating all plug-ins on preference export is unacceptable. The Preferences.setValue is being too smart. In the mergePluginPreferences call we already know that the list of keys that we have are values which we want stored, so we shouldn't do the "if the value is the same as the default then don't include it" optimization. Investigate being extra smart and by-passing the #setValue call or using Properties for persistence.
Created attachment 3553 [details] patch for runtime Here is a patch for the org.eclipse.core.runtime project. Needs to be tested and released.
Fixed. Test case added. Released.
