Eclipse Rich Client Platform is being used by many organizations. While demand for RCP development skills continues to rise, it has not reached the kind of fantastic level that is indicative of wholesale adoption. What’s stopping organizations from adopting Eclipse RCP for their applications? What roadblocks need to be removed to enable more organizations to realize success with Eclipse RCP?

Is the way that RCP is packaged and distributed a problem? The code that is referred to as the Eclipse RCP is produced by the platform subproject. This code contains significant functionality but does lack key features that are required for enterprise development. This functionality (at least some of it) is present in other projects, and is distributed separately. Should a more broadly-scoped "RCP" package be distributed? If so, then in what form? Is education a problem? What can/should we do to reduce the learning curve for RCP adopters?

This symposium aims at collecting experiences and requirements "from the field"; that is, it aims to collect real-world experiences from developers who have done real work for real clients building rich client applications (not necessarily using Eclipse RCP). As a minimal goal we hope to produce in a wish list for further development, distribution, and marketing of the Eclipse RCP.

Submitting a position paper in advance is not required to attend this workshop. All ESE conference participants are welcome to participate. Please send an email to Wayne and Christian to reserve a seat.

Format

Since the RCP Experience Workshop is not a symposium, it is difficult to follow the symposia format proposed by the conference organizer. In particular, while a few people did submit position papers, most did not, so it is difficult to base the workshop content on those. Instead, we will start the workshop by having everybody present themselves and describe their experiences with RCP. We'll keep this brief and limit each person to approximately 2 minutes. During this round, attendees can nominate themselves to describe their experience in greater detail. We'll capture these nominations on a list.

We'll then set it to a vote where each member of the workshop can vote for the three experience reports they'd like to hear more about. Based on the vote, we'll select the 2-3 most interesting experience reports for presentation. Additional experience reports may be presented depending on how much time is available. Each presentation will be limited to 20 minutes + 5 minutes for questions.

The Riena project will be presented with questions afterward.

Next will come issue identification. This will likely to have already started during the experience reports, but this time will be used to formalize the identification of issues. Specifically, this is concerned with defining how the RCP experience can be made better, encompasing all aspects of RCP development including (but not limited to) runtime, tools, education, help, and marketting.

Next, we will discuss what changes need to be made to make RCP development better, stronger, and faster. We'll start laying out a strategy for making improvements to RCP. Ideally, we'll be looking for individuals to step and take some responsibility for making things actually happen.