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,
Chris

Headless nightmare

It is considered as a proper design to separate *.core from UI. Such code is flexible and very easy to maintain. And exposes important functionalities to others, so they can adopt it and create amazing tool.

But have you ever thought what will happen if your code will be used by headless client? In Eclipse support it is quite common case - someone create a scripts which creates workspace, sets up preferenfes, runs validation, builds jars and deploys them somewhere. It's only a couple of minutes to write that kind of script. Extending Eclipse requires a little bit more time, but it is possible to f.e. start server from ant script!.

Great!

But headless ant is also very quick route to headless hell. Ant application is not aware that there is no UI. Other plug-ins also seem to ignore that fact. Various dialog try to appear and break the build (there is no workbench!). There is actually ant application which creates workbench, but is it really headless script then, when user has to sit and answer when prompted?

And what about you, dear Eclipse developer?
Do your *.core components work in headless mode? Are they protected against failed extension point initialization?

I do not have even idea how to solve this issue correctly. I do not even know what should I request from bugzilla. Should each Eclipse application has own bundle set? Should Equinox allow for UI/non-UI/more general plugin division? Each architecture change will require a lot of work in many plug-ins (some plug-in cannot be easily decoupled, because f.e. *.core exposes extension point which needs to be contributed by one (and only one) extension (which is currently UI dialog)).

Now something related to my previous post:

• 10% of readers was able to find the route couse in less than 10 seconds (I thought it is impossible).
• 60% needed more than 10 seconds, but less than 1 minute.
• 10% of readers finished before stopwatch shown 2 minutes.
• 7% was able to complete the quest in 5 minutes,
• 7% asked for more time.

Chuck Norris also completed the survey. He was contacted by the code which asked for fix (-1 sec).

You all are in quite good shape :-).

Regards,
Chris