Eclipse RCP has proven to be the premier cross-platform open tool for creating rich graphical desktop applications. With RCP, developers can create graphical applications that look and feel native, with a richness that is still very hard to achieve on the Web.

However, Eclipse RCP has also proven to be harder to program than most people would prefer. Particularly, for CRUD-based line of business applications that need rich elements, the base Eclipse RCP framework leaves many questions unanswered about architecture and code structure.

E4 presents an opportunity to address these concerns and to take RCP to the next level.

One way to improve this situation could be to integrate existing Eclipse technologies inside a radically-productive Rails-style convention-over-configuration framework.

• Make RCP as easy as Access(TM) but with a scalability, extensibility, etc., of Enterprise Java
• Be able to target rich web as well as rich client applications

In E4 and Web 2.0 - Is there a better way, I've taken a fairly in-depth look at the platform challenges.

At a lower level of granularity, there are concerns like the view/editor question that has been debated on Planet Eclipse lately. I have a proposal to rectify this situation.

Eclipse RCP currently lands on your computer as a bag of parts and a catalog listing many more parts (some free, some not). If you know what to do with each of those parts to make your application, you can be highly productive. But, the default configuration offers little assistance regarding how these parts should be most productively put together into a running build and test environment, much less a running application. This suggests that:

• Eclipse needs a “New RCP Application” wizard. The output of this wizard will be several projects:
  • A headless build/test project based on PDEBuild. This project will have an Ant script that can be run from within Eclipse or on a build server to generate nightly, milestone, and release builds. Build output would be:
    • A sample Cruise Control configuration.
    • .zip, .tar.gz files for initial install.
    • An update site.
    • A deployable RAP-based WAR file of the application.
  • Default UI architecture for a CRUD application (what does that look like?).
  • Easier O/R mapping than Hibernate–much closer to ActiveRecord
  • User login / ability to integrate with firm single sign-on directories.

The following technologies may or may not be useful toward implementing this vision:

• GUI builder
• Declarative UI
• RAP
• Riena
• Eclipse Data Binding
• Richer, more scalable SWT table control(s)
• Report builder (BIRT)
• Simple scripting (Scala, Ruby, JavaScript?)
• Modeling (EMF/GMF, ….)
• Simple data persistence
• Eclipse plugins to integrate all of this

This is related to the work being proposed/done at the upcoming E4 Summit

• Needed More Readable SWT Snippets
• Eclipse Editors for Arbitrary Types
• Implementing Login in RCP Applications

~~LINKBACK~~ ~~DISCUSSION:closed~~