Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Eclipse Summit Europe 2007 RCP Experience Workshop

Hosted by: Wayne Beaton (Eclipse Foundation)

  • Tuesday, 9:00. 4 hours
  • Seminarraum 5

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.

Planning to attend

Be advised that having your name on this list does not guarantee you a seat in the workshop. We are not taking names or checking credentials at the door. We will not prevent anybody who wants to attend from attending. Arrive early.

  • Georgios K. Nikolaidis
  • Mark Dettinger
  • Christian Hofmann
  • Kiril Mitov
  • Chris Aniszczyk
  • Tom Seidel
  • Amro Al-Akkad
  • Andrea Agili
  • Manuel Zini
  • Marco Fabbri
  • Mark Dettinger
  • Anthony Bennis
  • Christian Stellwag
  • Achim Lörke
  • Bernhard Haumacher

Results

These are just rough notes taken during the workshop. Please feel free to revise and make additions as necessary.

Authentication and Authorization

  • Start by getting involved with Riena to make sure that the authentication scheme used will be useful/compatible downstream.
  • Develop IsourceProvider extensions for Riena to allow variables like “isUserLoggedIn” and “userRoles” so that command framework can leverage.
  • Drive changes into the platform to leverage expression framework on views, editors, wizards, etc.

Security

  • Make sure that an application that is deployed is not hacked or changed in any way. If it is, display error and stop user.
  • Persistence layer security.
  • Security must start at the launch point. Can replace “eclipse.exe” with hacked version. Maybe checksums?
  • JVM-based checks.

Test Coverage

  • JUnit test template generated by PDE.
  • Eclipse Test Framework

SWT Needs more Widgets

  • Nebula
  • BIRT article on Eclipse Corner: graphs on SWT.
    • Need a way to make simple graphs with complementary look to Eclipse Forms. A 'flat' look.
    • Need simpler API for BIRT. Lighter footprint. More immediate feedback.
  • JFreeChart: SWT charting.
  • OpenGL via SWT Canvas. We believe that this is no longer supported?
  • Scale widget not configurable. Display the range.

Feedback

  • Need better tools to inform developer of when bundles are loaded.

Education

  • Formal education.
  • RCP Book
  • Eclipse Corner RCP tutorial.
  • Need more tutorials.
  • How to find the right extension points out of the thousands available.
  • Which is the “right” way when there are multiple possible ways.
  • Update of the FAQ book with 150 new questions.
  • How to use the command framework.
  • Search on newsgroups needs to be better. Using Google to search eclipse.org is just plain silly.
  • Graphical mapping on Eclipse SDK. Show where different extension points are used.
  • Best Eclipse Educator award at EclipseCon.

Different versions of your software, different access keys

  • “Lite” version that is free. “Professional” version sold for money.
  • Only paid user can access paid functionality.
  • Ties into authorization discussion.
  • Lite version contains only limited functionality. When user pays, new bundles are added to the application.
  • Security. Prevent tampering with JAR files.
  • License management. Propogate license to provisioning server.
  • Licenses expire.

Better documentation for plugin.xml options

  • Missing documentation on available adapters.
  • Better lifecycle management for views, e.g. prevent closing (5)
  • ISaveViewerPart interface on viewer.
  • Hide some editors in some perspectives.

Finer-grained views and editors

  • If there is more than one viewer in a view contributing to the workbench selection, you cannot query the selection source. You cannot easily have more than one viewer set the workbench selection.

Back to the top