Jens Eckels posted a thought provoking post on EclipseZone about the state of Eclipse. I think it was an honestly written piece that identifies some weaknesses where Eclipse perhaps could do better. It got me thinking of my earlier blog entry about improvements to Eclipse, but this time more from an Eclipse marketing strategy rather than individual niggles. I put my thoughts in response to his post, but my thoughts for making Eclipse better can be summarised as:
- Bundle repository/ies, with dependencies between bundles. Want to update Xerces? No problem. None of this worrying about what versions a feature ships with, just update your bundles.
- Updated update manager. Uses the above. Overarching feature is now a bundle with vanilla bundle dependencies. Heck, make it dynamic -- if a bundle tries to start and there's no bundle dependency, go look for it. That way, you don't need a feature-rich WTP with EMF,JSP and J2EE if all you want is a Data perspective.
- Loosening the 'eclipse/plugins' structure. Get rid of features, and you don't need the 'eclipse/features' directory -- there's just plugins. Why not let them live anywhere, specified by a BUNDLE_PATH environment variable (list of directories in which bundles are stored, rather than individual bundles)? That way, I can install a bundle by dropping it into ~/Library/Application Support/Eclipse, without having to worry about pedantic 'eclipse/.eclipseproduct' turds.
- OSGi replacement for Maven. No, not maven capable of building OSGi bundles -- an OSGi build engine, where you contribute plugins as -- you guessed it -- OSGi bundles. Need a test report? Install the JUnitReport bundle, and it registers the TestListener extension point that the JUnit bundle provides. TestNG could work in a similar way.
- OSGi-based servers. Something that you can install and forget about. A mail server would be an excellent choice; a web server is also a good candiate. Want to add auto-GZip compression? Install the web.autoGzip bundle. Need something for handling .jsp files? Install the J2EE bundle. All of this is of course dynamic, and hosted by extension points (after all, you'd want a mail server that you could contribute your own bundles to run in (for example, server-side processing of incoming mail or a spam detection filter extension point).
Certainly, I think getting rid of features (or at least their implementation; they could still live on as features, but be implemented as extra metadata in an ordinary OSGi bundle) is one of the important starting points for this. The Equinox core already deals with bundles almost exclusively; it's only really the Update manager (and some configuration dialogs) that care about features. Now is the time to vote on bug 126732!