Skip to main content
Jump to: navigation, search

Demo EclipseWorld

Eclipse Home Wiki Home

EclipseWorld - Corona Collaboration Demo

Session Topic

As Eclipse becomes more popular, and takes on more roles within the enterprise as both a development and rich-client platform, the need for collaboration across these applications and tools is constantly increasing. Fortunately, the Eclipse Foundation has several projects that are focusing on aspects of collaboration, and this talk will concentrate on two of them: the Tools Services Framework (aka Corona) and the Eclipse Communication Framework.

We will show how RCP applications and Eclipse development tools can be easily extended to large or small workgroups by using Corona and ECF for sharing and synchronizing platform constructs such as projects and resources. You’ll learn that Eclipse constructs such as projects and resources can be shared within a collaborative environment—and we’ll even demonstrate workgroup collaboration in action.

Workgroup Collaboration

Corona will provide an exemplary implementation of its collaboration framework based upon the context of a Project. The word project is overloaded. There are two project scopes being discussed. First, there is the local Eclipse Workbench project. Second there is the Corona collaboration project.

We should all be familiar with the Eclipse Workbench project. Each Eclipse Workbench project can be uniquely identified by its CVS “id” (ie: cvsroot/module or subversion url). The name of each Eclipse Workbench can be different within separate machines (or even workspaces). However, they will all share the same CVS ID.

The Corona collaboration Project provides the context for collaboration. This is the exemplary implementation of a collaboration context being provided with Corona. The basic building block for collaboration is the ProjectContainer. A container can be related hierarchical to other containers by add them to a list referencing a them as related containers. In addition, a container can contain one (or more) Eclipse Workbench project(s). All collaboration containers can be uniquely defined by their ID (e.g. collaboration ID).

An Eclipse Workbench is part of a “Workgroup” when it shares the same ProjectContainer with other Eclipse Workbenches. The common ProjectContainer is the same for all members of the Workgroup.

The Project context will be used for:

  • Managing references to the Project’s resources (ProjectContainer)
  • Organizing user interface (ProjectContainerView)
  • Sharing of the Project’s collaboration events (ProjectEvents)

A Workgroup is comprised of users who participate in the same Project context. Members of a Workgroup are bound by a common set of resources and events that associated with one another within the same Project context.

Project Context

The Project collaboration context defines the entire domain for Project. This domain not only includes the ProjectContainer, but also plug-ins that provide business logic and user interfaces.


The ProjectContainer is the foundation for the Project collaboration context. It defines the configuration of collaboration and collaboration type. ProjectContainer definition consists of the following attributes and elements:

  • name
  • container-uri
  • container-path
  • container-type
  • container-description
  • repositories
  • related containers
  • container-properties
  • relationship-resource-set
ProjectContainer type

A ProjectContainer contains the element named container-type. The type is defined in any URI format and determines the business logic of the container. The field enables it identify the kind of container and allows extended processes beyond a basic container. It is the duty of processing code to define operations on the container depending on its type.


A ProjectContainer contains a list of Repository references. Each Repository defined within the ProjectContainer will have the following attributes and elements:

  • name
  • uri (used as id)
  • content-type
  • description
  • repository-configurations
    • list of connection-parameters

Components within the Project domain have the logic necessary to utilize each Repository. A component uses content-type attribute to identify the kind of repository and decide whether the component can handle the repository (e.g. team repository, bugs repository).

repository-configurations contains a list of connections and their parameters. Each connection parameters define:

  • access-type
  • name
  • list of parameters
  • list of resource-subsets

access-type is used to determine, which method should be used to access the resource (e.g. xml file, webservices, database). properties are used to actually connect to the resource.

The following defines several repositories that would be associated with Project context for the Corona project.

Home Web Site


name Home
content-type corona://
description The Eclipse project home page
access-type html
parameter (name: value) location: ./corona.html
Wiki Web Site


name Wiki
content-type corona://
description The community wiki for Eclipse projects
access-type html
parameter (name: value) location:
Team Member List


name Team member list
content-type corona://
description The list of team members assigned to the Project
connection-parameters-name xml access
access-type xmlFile
parameter (name: value) location: ./teamMemberList.xml
connection-parameters-name web services access
access-type webServices
parameter (name: value) location:
parameter (name: value) port: 8080
parameter (name: value) point: getTeamMemberList
ECF Chat
name ECF chat server
uri ecftcp://localhost:47000/corona
content-type corona://
Description ECF Chat room for the project
access-type ecftcp
parameter (name: value) location: localhost
parameter (name: value) port: 47000
parameter (name: value) path: /corona
CVS of Eclipse workbench project

The ProjectContainer can contain many Eclipse Workbench projects. These Workbench projects are uniquely defined by the CVS repository used synch the Workbench project with.

The following is an example of one of the Repository references for a Workbench project. This repository definition for each Workbench project also uses Respository Configuration attributes.


name Project container view
uri http://org.eclipse.corona.project.container.view
content-type corona://
description CVS repository/module location for Workbench project to display project container
access-type cvs
parameter (name: value) location:
parameter (name: value) protocol: pserver
parameter (name: value) user: anonymous
parameter (name: value) path: /cvsroot/technology


The ProjectContainerManager is responsible for managing all of the ProjectContainer objects within the workspace. It is an OSGi registered service that can be referenced by any bundle using a service tracker.


The ProjectContainerExplorer is a special view used to explore ProjectContainers. It provides the user with a set of interactions needed to open/close a ProjectContainer.

The set of ProjectContainers accessible from a Workbench is defined within a local configuration file. This will allow the ProjectContainerExplorer to work online, when not connected to the Corona server. When a ProjectContainer is selected to be opened, the ProjectContainerExplorer will ask the ProjectContainerManager to open the ProjectContainer. At this point, the ProjectContainerManager will load the current ProjectContainer definition.


The ProjectContainerView is a special multi-page view. It defines an extension point needed to register pages to be included in the ProjectContainerView. The set of pages included in the actual ProjectContainerView is dependent upon a set of attributes defined with each extension point page. These attributes define configuration values used by the ProjectContainerView to determine if the page should be displayed. A extension point page can be displayed by default or displayed if the ProjectContainer has a Repository that matches the extension point page’s attributes.

All ProjectContainerView pages must implement the interface IProjectContainerPage. In addition, there is an abstract class, AbstractProjectContainerPage available that can be extended.

Project View Page: Overview

Each ProjectContainerView will contain a default overview page. This extension point page provides a summary report of the ProjectContainer.

Project View Page: Web Browser
Project View Page: Team Member List
Project View Page: Event List
Project View Page: ECF Chat



The followin section describes how to setup the Corona demo for Project context collaboration. The demo involves 3 seperate processes, 2 Eclipse Workbenches and 1 Collaboration Server.

Eclipse Workbench

  • org.eclipse.corona.common.collaboration
  • org.eclipse.corona.common.project
  • org.eclipse.corona.client.project
  • org.eclipse.corona.project.container.view
  • (? marcin: update with name of team list view)
  • org.eclipse.corona.project.container.view.event (? marcin: update with name of project event list view)
  • org.eclipse.corona.project.container.explorer
  • org.eclipse.corona.project.container.cache
  • org.eclipse.corona.client.collaboration.event
  • org.eclipse.corona.client.collaboration.ui
  • org.eclipse.corona.client.project.builder
  • org.eclipse.corona.client.project.event
  • org.eclipse.corona.client.project.ui
  • org.eclipse.corona.project.container (? glenn/edyta: updated with name of Project Container plug-in)

Collaboration Server

  • org.apache.commons.discovery_02 (see Joel Hawkins)
  • org.apache.jakarta_commons_logging (eclipse cvs /home/tptp module platform/org.apache.jakarta_commons_logging)
  • org.apache.jakarta_log4j_logging (eclipse cvs /home/tptp/platform module org.apache.jakarta_log4j_logging)
  • org.apache.xalan.XalanImpl (see Joel Hawkins)
  • org.apache.xerces.XercesImpl (see Joel Hawkins)
  • org.eclipse.corona.common.project (eclipse cvs /home/technology module org.eclipse.corona/plugins/org.eclipse.corona.common.project)
  • (eclipse cvs /home/technology module org.eclipse.corona/incubator/
  • org.eclipse.corona.core (see Joel Hawkins)
  • (eclipse cvs /home/technology module org.eclipse.corona/incubator/
  • org.eclipse.corona.model.container (eclipse cvs /home/technology module org.eclipse.corona/incubator/org.eclipse.corona.model.container)
  • org.eclipse.corona.model.container.project (eclipse cvs /home/technology module org.eclipse.corona/incubator/org.eclipse.corona.model.container.project)
  • org.eclipse.corona.server.container.common (eclipse cvs /home/technology module org.eclipse.corona/incubator/org.eclipse.corona.server.container.common)
  • org.eclipse.corona.server.container.project (eclipse cvs /home/technology module org.eclipse.corona/incubator/org.eclipse.corona.server.container.project)
  • (eclipse cvs /home/technology module org.eclipse.corona/incubator/
  • org.eclipse.corona.server.test.container.project - for testing (eclipse cvs path /home/technology/ module org.eclipse.corona/incubator/org.eclipse.corona.server.test.container.project)
  • org.eclipse.equinox.ds (eclipse cvs path /cvsroot/eclipse module org.eclipse.equinox.ds)

CVS Server

The demo will utilize a CVS server to allow Eclipse Workbench projects to synchronize. Therefore, a CVS server must exist locally or be available someone on the network. Since the demo will initially be given at a conference, will all components running on the same laptop, a local CVS server is required.


The theme for the collaboration demo is based upon a Project context. Two Eclipse Workbench clients collaborating on changes to a common resouce.

  1. Start the first Eclipse Workbench (WB-1)
  2. Use the ProjectContainerExplorer to show the list of locally known ProjectContaines(s)
  3. Selects the ProjectContainer named Demo
    1. The ProjectContainerView is launched and its ProjectContainerView-Pages are initialized
    2. A ProjectEvent is published indicating that a ProjectContainer has been opened
      1. The Collaboration Server receives the ProjectEvent and creates the ECF chat room for the ProjectContainer
  4. Start the second Eclipse Workbench (WB-2)
  5. Use the ProjectContainerExplorer to show the list of locally known ProjectContaines(s)
  6. Selects the ProjectContainer named Demo
    1. The ProjectContainerView is launched and its ProjectContainerView-Pages are initialized
    2. A ProjectEvent is published indicating that a ProjectContainer has been opened
      1. WB-1 receives the ProjectEvent
  7. WB-1 updates local resource
    1. A ProjectEvent is published notifying the Workgroup that a common resource has been modified
      1. WB-2 receives the ProjectEvent indicating that common resource has been modified
  8. WB-2 posts a comment to the ProjectContainer's chat room inquiring about the changed resource
  9. WB-1 and WB-2 collaborate on modifying the shared resource
    1. use ECF chat room
    2. use ECF shared editor
  10. WB-1 finishes updates to common resource
    1. Shared resource is commited to CVS
    2. ProjectEvent is published notifying workgroup of synch event
  11. WB-2 receives ProjectEvent re: synch event
    1. WB-2 performs a CVS team synchronize

Back to the top