Eclipse: OSGI Preferences vs. PreferenceStore

Question

I'm working on an Eclipse plugin (or in fact, a plugin for an Eclipse-based application) which needs some configuration to be entered by the user.

From looking at the documentation, there seem to be two preference APIs - one in org.eclipse.core.runtime.preferences, extending/implementing the OSGI prefererence API, another one, JFace specific, in org.eclipse.jface.preference. Then we have org.eclipse.ui.preferences, too.

The OSGI API has a hierarchic Node tree - a preference node (Preferences or IEclipsePreferences) can have multiple subnodes, which themselves can contain both individual name-value-pairs as well as more subnodes. This seems to be right for my use case - I have a dynamic number of "preference groups", each with about three string properties (name, description, command), which would nicely map to these nodes.

The JFace API has no such hierarchy, only a flat IPreferenceStore for each plugin. But it provides preference editor pages, which then can be included in the usual preferences dialog (Window / Preferences) by implementing IWorkbenchPreferencePage and using the "org.eclipse.ui.preferencePages" extension point. (I still have to implement part of the preference page myself, but this API provides a good base for this, it seems.)

It seems that the org.eclipse.ui.preferences API somehow bridges both these APIs by providing an IPreferenceStore implementation based on the IEclipsePreferences, but I still can't see how to use this.

So here my question: How can I use the hierarchical OSGI Preferences in the preferences-dialog? I only need one level, but I need the user to be able to dynamically add new nodes (with about three preferences each). (These nodes do not have to have new preference-pages, though.)

Touchmenot

Answer 1

It seems that at the preference page level, it wants to work with a preference store. Most plugins get their preference store from the default provided by org.eclipse.ui.plugin.AbstractUIPlugin.getPreferenceStore(). That translates loosely to a ScopedPreferenceStore with an InstanceScope with a node that matches their bundle.id.

The equivalent to get the matching IEclipsePreferences object would be InstanceScope.INSTANCE.getNode("bundle.id"). That would allow you to add further nodes underneath, but they wouldn't be accessible from your IPreferenceStore. However, your preference page could set its preference store to the main one for your plugin, and still use IEclipsePreferences or a secondary IPreferenceStore to access extra preferences (you just have to code it yourself, similar to org.eclipse.ui.internal.dialogs.EditorsPreferencePage).

Roden

Thanks, this is also what I gathered so far. I'm working along this approach now. – Barkentine

Answer 2

I tackled this problem by overriding the getPreference store as follows:

@Override
public IPreferenceStore getPreferenceStore() {
    if (preferenceStore == null) {
        preferenceStore = new ScopedPreferenceStore( InstanceScope.INSTANCE, ID );
    }
    return preferenceStore;
}

works for me

Xuthus