Community
Participate
Working Groups
Sometimes after I20040914 AbstractUIPlugin.initializeDefaultPreferences stopped from being called. I experience this in the Compare plugin where default preferences are now wrong. I did not change anything in Compare since I20040914.
added workaround for Compare.
If you look at the spec for it is only called if the compatibility layer is in use which is not the case for the Compare plug-in. If you look at the JavaPlugin they explicitly call the backwards compatibility layer in thier start() method.
I wasn't aware that this has changed since I20040914 (last week). Why is the Compatibility layer not in use for the Compare plugin? I always thought, it would be.
It is not the compatibility layer that is the issue - it is that you are trying to do too much work in the plug-in constructor and were getting lucky before when we used a PreferenceForwarder. The issue is that you are initializing your preference store in the constructor of your plugin class. public CompareUIPlugin(IPluginDescriptor descriptor) { super(descriptor); Assert.isTrue(fgComparePlugin == null); fgComparePlugin= this; fResourceBundle= descriptor.getResourceBundle(); registerExtensions(); initPreferenceStore(); } Is there a reason it needs to be here? As we are not using a CompatibilityPreferenceStore for getPreferenceStore() anymore you are now going through the OSGI API directly. This creates an instance of DefaultPreferences() which looks for your plug-in class an attempts to call initializeDefaultPreferences(). As the instance is in the process of being created we cannot return it to you and hence cannot get its preferences. The code in initPreferenceStore should not be done in the constructor - it should be done in initalizeDefaultPluginPreferences or better yet write a preference initializer as speced in the javadoc of initalizeDefaultPluginPreferences .
org.eclipse.compare does pre-req the compatibility plug-in, so as far as runtime compatibility goes, this should work the same as in 2.1 and 3.0. In 3.0 getPreferenceStore(), whether from the constructor or not, would lazily create the preference store, calling initializeDefaultPreferences(IPreferenceStore). This was implemented in terms of the Plugin preference mechanism (getPluginPreferences() and initializeDefaultPluginPreferences()), which was in turn implemented in terms of the new 3.0 scoped preferences mechanism. With the latest changes, this flow of control is no longer guaranteed, which smells like a breaking API change.
No further action required. Closing.
