Nowadays there are tens of Eclipse project under Eclipse Foundation and hundreds of eclipse-based products in all over the world. Everyone can clearly recognize eclipse-project and separate it from non-eclipse projects. But what is criteria of calling project eclipse-based or not? Linkage with any of Eclipse Foundation projects do not look sufficient...
I think there are three things, that do the project Eclipse-based: Equinox, SWT, and EMF. It's interesting, but anything else is not significant in current people's mind: I can reuse millions lines of other Eclipse code for example JDT's Java complier, EclipseLink, or something like that but nobody could say "this is eclipse-based" project. But if I'm running on Equinox, or exposing SWT UIs - my project will be named "eclipse project" magically. Even SWT-based RSS reader is Eclipse-based in people's mind. Equinox and SWT act as a glue. If you use them - you belong to Eclipse world. If you're building on Equinox or use SWT - you can interoperate with other Equinox and/or SWT-based projects, which are Eclipse projects. In Eclipse Modeling world EMF is a such glue.
All that above means Eclipse Foundation built on top of 3 whales: Eclipse Plugin Architecture, SWT, and EMF. Each of these whales is vital for Eclipse Foundation existence and ambitions (in form they exists now). Let's look at each whale:
Eclipse Plugin Architecture
Eclipse Foundation did huge work transitioning plugin architecture to OSGi, influenced on OSGi, and revitalized OSGi. Let's move to the future: People expressing thank Eclipse! Eclipse did an excellent job. Now OSGi living it's own life and we have many OSGi runtime vendors. Suddenly some of Eclipse Foundation Projects, which neither use SWT nor EMF recognized that they have no connections with Eclipse Foundation. Nobody able to explain why OSGi-based financial libraries will stay at Foundation, or why OSGi-based communication protocol implementaions will stay at Eclipse Foundation. What about OR-mapping frameworks? What is the difference between Apache Foundation OSGi projects and Eclipse Foundation OSGi projects?.. [BTW Orbit will be closed] Or how Eclipse Foundation OSGi projects different to EPL-compatible OSGi projects, which are hosted at SourceForge?.. Eclipse != OSGi. Pure OSGi projects leaving Foundation... First whale (and the strongest glue) is dead...
Standard Widget Toolkit
Eclipse has strong ambitions to be a Rich Client Platform. Now Eclipse RCP is not possible without SWT. At early SWT days "SWT" was a buzzword. I saw AWT vs SWT, and SWT vs Swing articles, millions of discussions on forums and many authors rushed on IBM: "this is not pure Java", "what they're doing? this is not correct, you should respect standards", etc. SWT/Eclipse was innovating... Now SWT vs XYZ is not a hot topic. This means 1) SWT is mature 2) SWT must evolve or die. If Eclipse will loose in Desktop battle - Eclipse will not be Rich Client Platform anymore. I already mentioned that Eclipse is not involved in fight between JavaFX, WPF, and Flex. It means Eclipse will choose from winners, and if Eclipse chooses JavaFX - goodbye RCP, because OSGi + JavaFX != RCP, OSGi + JavaFX == Java, and Java is the best Rich Client Platform. All RCP-based projects leaves Eclipse World, second whale is dead.
Eclipse Modeling Framework
I'm very optimistic on the EMF future, and my scenario for 2010 is following: EMF is everywhere, and EMF and Eclipse Workbench is only one glue, which connects all Eclipse projects together: they all run in Workbench (4.0 != 2.0?) and interoperate via EMF models. Eclipse is still the best platform for modeling and tooling (Eclipse == EMF + Workbench)! Unfortunately there are no RCPs and Eclipse looks archaic (visually) similar to Motif UI in 2008 (Hi good old Rational Rose ;)).
There is no Total Eclipse more, sun shines again in Java Desktop town... A terrible scenario, isn't it?
Leave a comment