A common usecase for a RCP is to request data from a remote repository for viewing, editing, etc. You’ll find that there are many ways to do this, but have you ever thought about requesting your domain specific data via a Team implementation and store that data in your workspace? - The following article will explain how this could work and provides a very simple example how you can use the mighty functionalities of a Team implementation under the hood, without exposing the complexity to the user.

Team, Resources, Workspace, Filesystems

If you use Eclipse as an IDE you know the general workspace for requesting your data (sourcecode) you want to edit. You need to create a remote repository location, checkout the data, browse through the data in your workspace, open a file, etc. It is worth mentioning that the integration of workspace data is one of the best ways to integrate a domain-specific datamodel in your RCP application and it also is the “eclipse-way” to manage data. Then there is the Resource-API with the ability to implement a virtual filesystem, an excellent ways to notify of Resource changes and finalyy you have the project-builder that allows you to built up your ows RCP - specific data model and validating the state of your model.

On the other hand there is the Team-API. The team API offers you the deep integration of data-synchronization with a remote data store and your IResource-based workspace data. So the Team-API is more of a framework, that handles just the workflow and the integration into a team-provider implementation such as the CVS. The Subversive project has also an implementation for SVN repositories.

Overview Resource & Team API

What has this got to do with RCP?

Perhaps the question is badly worded, to be more specific: “What differs in data handling regarding a Development Tool and your domain specific RCP?” - Not so much really. Instead of editing Java models (Class, Methods,…) you’re editing domain specific data. The rest stay pretty much the same. All models need to be persisted and sometimes models need to be synchronized with a remote repository. So why not using the same mechnanisms to synchronize this data with the Team-API?

Complexity

A common problem of Reusing Eclipse-Components is that the complexity of application workflows cannot be hidden from the user (this should be also an issue while developing e4). From a developers perspective it would be greate to have hundreds of possibilities to customize setting, from an adapter’s perspective who develops a RCP of a limited scope for a non-technical target user (I develop RCPs for marketing & sales people) this is always an issue. The hitch is that in nearly every case of reusing Eclipse components you have to patch the plugins coming from Eclipse. Let’s take a simple example: Update sites in RCPs - There will never be the reqirement that an user can add Update-Sites. A typical user wouldn’t normally know what an update-site is, namely an application internal component regarding RCP development.

The same issue arises when you integrate the team framework. A very good method for obtaining data is to use SVN, but the user has no idea where the data originally comes from. It’s simply unacceptable that the user should have to create repository locations, navigating through trunk and branches, etc. As a RCP developer there is always a consideration of how much complexity should be passed to the user. In the most cases you have to strip the original UI a lot.

The example application

Meant for a prototype I’ve developed a very simple application that allows you to define via Extension points repository providers, which typically come from another remote application, which returns the user specific repositories (e.g. via WS-Call). The data itself is located within a version control system. These repositories are checkedout using an installed team provider implementation and are stored into your local workspace as a project. After checkout you can use the mighty Resource-API to manipulate the data or organize the representation of the raw data to suit your domain specific usecase.

Defining Repository provider via Extension Point

Domain specific representation of different repositories

Editing my Domain specific data

Conclusion

Combining Resource API with Team Integration is an easy and elegant way to handle data synchronizations even for non technical RCP Applications . But it should also be mentioned that the effort fo stripping the UI is immense. In general you can not use the normal Team UI components for your non technical user-group. And then there is a fact that the controlling of accessible data is managed by the application itself or a remote system not by the user.

Appendix

Just to round off this article, I’d like to share a photo I took at the entrance of the Convention Center at EclipseCon for all those who missed the “Netbean-girls”.

Download

Download the CVS Team Project-Set
Download the Example as RCP (23 Mbyte)