Thursday, August 20, 2009

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:

Monday, August 17, 2009

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)).