Al Blue responds to Jens Eckels’ article on the weaknesses in Eclipse. Al gives his list of the marketing strategies that could make Eclipse better.

• Bundle repositories, with dependencies between bundles: Al recommends a worry-free bundling, with no confusion regarding versions while shipping.
• Updated update manager: Al asks for a more dynamic update manager. “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,” he says.
• Loosening the eclipse/plugins structure: Al wants to get rid of the eclipse/features directory and just let the plugins be. “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,” he says.
• OSGi replacement for Maven: Al suggests an OSGi build engine, where you contribute plugins as OSGi bundles. Test reports can be generated by installing the JUnit Report bundle. It registers the TestListener extension point that the JUnit bundle provides. TestNG could work in a similar way.
• OSGi-based servers: Al wants a server that you can install and forget about. A mail server would be an excellent choice, but a web server is also a good candidate, Al says. Adding an auto-GZip compression can be done by installing the web.autoGzip bundle. Installing the J2EE bundle will aid the handling of .jsp files. “All of this is 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.”