Thursday, August 20, 2009

Preferences Nightmare

Business Eclipse adopters quite common request for headless preferences import/export. Eclipse preferences has one big disadvantage - they are exported if and only if they have been changed. So if you and your friend have some compiler settings, and you would like to import his preferences, it is impossible, because both preferences set will be merged. There is also a request to reset all existing preferences prior to import.

We, as Eclipse support, have tried to deliver solutions to those problems. But we failed because of something rather unexpected:

There is too much freedom in preferences allowed.

Developer tends to:
  • Cache preference node. This results in beautiful java.lang.IllegalStateException: Preference node "org.eclipse.core.XYZ" has been removed.
  • assume that nobody else will modify those preferences and there is no need to listen for changes.
  • assume that preferences can be changed only by preferences dialog and put some business logic into IPreferencePage#performOK().
And what about you? Can your preferences be exported and imported and changed via 3rd party? Or is it necessary to dig through your code innards to find what you call in performOK?

Is it so difficult to choose the right way?

Best regards,


Eric Rizzo said...

I've yet to hear a use case that couldn't be satisfied by using project-specific settings. I commented in the bug report that preferences are part of the workspace, and workspaces are not sharable.
There is a different bug open that requests better support for sharing project-specific settings among a group of projects; I think that would be a better place to concentrate effort so that using project-specific settings gains wider adoption.

Eric Rizzo said...

The bug I spoke of is