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().
Is it so difficult to choose the right way?
Best regards,
Chris
2 comments:
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.
The bug I spoke of is https://bugs.eclipse.org/bugs/show_bug.cgi?id=194414
Post a Comment