What’s big in eeek4?
After yesterday’s e4 talks/BoF, it is easy to get the impression, that e4 is all about bringing Eclipse to the web browser. Although I see the reason behind it (don’t leave the web-app market to e.g. Google alone), it alone doesn’t justify e4.
But what else could be a major story for e4? The e4 BoF gave us an answer (Btw. do we have minutes from last year’s blue sky BoF for e4?). A larger portion of the community wants to tackle API rot in e4 and clean up all those org.eclipse.ui.IWorkbenchPart3… cruelties. Even if it means that we have to break backward compatibility if totally unavoidable.
And we wouldn’t break what we had promised before. The major version indicates a non-compatible API change in our component model.
But the big players seem to be reluctant to this idea which is understandable. If you spent millions of dollars building products on top of Eclipse, you need to protect your investment. However, Eclipse 3.X is going to stay with us for a long time even after e4 has been release. So it’s simply wrong arguing that we cannot let “(EPIC) plug-in authors” hanging loose in the air.
This is especially dingy in front of the community out reach to step up and actively get involved in the e4 efforts. If the big players will only care for their needs in e4 and the community should take care of their own (which is absolutely fine by me) watch out that it doesn’t backfire. The community can pull the same argument and let the big guys deal with backward compatibility. But not by blocking off API cleanups!
Why does the community want to get rid of redundant APIs anyway? Because its getting harder and harder for anybody to develop on top of Eclipse. It’s becoming way to complicated to figure out which Interface to use and outdated documentation doesn’t help either. Some cases cannot be done with newer API version…
So cleaning up API in the end is an effort anybody will benefit from. We will be able to continue work innovative like we’re so much used to.