Papyrus/Mars Work Description/Improvments/Improve CDO integration within Papyrus

Analysis

This section compares 'normal' Papyrus usage (i.e., without CDO integration) and Papyrus/CDO usage.

Normal Papyrus Usage

Normal Papyrus usage is centered around the following UI concepts:

• The Project Explorer view is used to browse workspace resources. The resources can be purely local or connected to (checked out from) a traditional SCM, such as CVS, SVN, or Git. A special CNF contribution treats DI files in a special way; it displays them as a logical folder with all associated model files as children.
• If the used resources are connected to a traditional SCM they must have been checked out before. This typically happens through an SCM-specific repository browser view, e.g., CVS Repositories, SVN Repositories, or Git Repositories.
• From the Project Explorer view the Papyrus Model editor can be opened.
• While a Papyrus model editor is open the Model Explorer view displays the model structure and allows to edit it (in contrast to the Outline view of the editor).
• There's likey a lot more to it, but I'll focus on the concepts that are relevant here.

Papyrus/CDO Usage

Papyrus/CDO users experience a slightly different workflow:

• The Project Explorer view is not used.
• The (Papyrus) Model Repositories view is used to browse connected CDO repositories and the contained CDO resources. This view is CDO-specific but not provided by CDO.
• The Papyrus Model editors are mostly used in the normal way. The fundamental difference is from where they are opened.
• The Model Explorer view is also used in the normal way.

Proposal

According to the goal of making the CDO integration a first class citizen in Papyrus I propose the following:

Provide a CDO Repositories view in CDO

This view can be used to configure connection parameters to different kinds of CDO repositories, e.g. normal remote repositories, newly created local repositories, or local offline clones. The connection parameters are remembered across IDE sessions. Following CDO's naming convention (server-only concepts are "IXyz" and client/common concepts are "CDOXyz") these connection parameters and the CDOSession state (if connected) are represented by CDORepository objects. CDOBranches and (later) CDOTags are displayed in a tree under the CDORepository object. Whether CDO resources are displayed in the tree is optional. As usually users can create "checkouts" from here (more below). Here's a screenshot of my prototype:

The main technical challenge is that this view performs well under all conditions such as network problems. The UI must never block or freeze. All access must be asynchronous. My prototype ensures this.

Another complication is that CDO (in contrast to most other traditional SCMs) offers server-triggered live updates even to the branch tree. This unique capability should be supported but that introduces subtle state issues (e.g., when should the underlying CDOSession be closed?). My prototype solves this with configurable timeouts (unless checkouts are currently open, see below).

Provide a Project Explorer extension (i.e., a CNF contribution) in CDO

In addition to the normal workspace projects and their resources this view shows CDOCheckout objects. Such a CDOCheckout represents a specific subtree of the resources (and optionally the objects) of a specific CDORepository at a specific CDOBranch or CDOTag. The association with the CDORepository object and the other configuration parameters are remembered across IDE sessions. There are two different kinds of CDOCheckouts:

• An OnlineCDOCheckout represents roughly what Christian has already implemented, a direct CDOView or CDOTransaction on top of the CDOSession that's maintained by the associated CDORepository. These checkouts have no particular local data for the contained resources and objects. They are a little bit like the CDOViews and CDOResources in the CDOSessions view. All commits go directly to the associated IRepository.

• An OfflineCDOCheckout represents a CDOWorkspace. A CDOWorkspace is an existing (not very well-known) concept in CDO that copies an entire baseline of objects from a remote repository into an internal local repository and provides normal CDOTransactions towards the developer. Commits do not go directly to the associated IRepository but stay in the internal local repository. In addition it offers CVS/SVN-like team operations (has nothing to do with the Eclipse Team API) such as update(), replace(), merge(), compare(), and checkin(). In contrast to a CDO offline clone repository a CDOWorkspace does not contain the full history of all objects.

The two types of CDOCheckouts look and behave almost identical in the Project Explorer view. Here's a screenshot of my prototype:

Again, the main technical challenge is that this view performs well under all conditions such as network problems. The UI must never block or freeze. All access must be asynchronous. Child objects should only be loaded when a tree node is expanded (i.e., not already when hasChildren() is called!). When a tree node is expanded only the not-yet-loaded children must be loaded and they must be loaded in a single server round-trip. My prototype ensures this.

Provide Consistent Commands

I plan to implement a consistent set of team functionality on top of this infra structure. Here's my vision of the available commands/menus (work in progress):

   CDORepository (connected/disconnected)
   --------------------------------------------
     Connect
     ----------------------
     New --> Branch...
             Tag...
     ----------------------
     Show In --> History
                 CDO Administration
                 CDO Sessions
     ----------------------
     Checkout
     Checkout As...
     ----------------------
     Delete...
     Disconnect
     ----------------------
     Properties...

   CDOBranch | CDOTag
   --------------------------------------------
     New --> Branch...
             Tag...
     ----------------------
     Show In --> History
                 CDO Sessions
     ----------------------
     Checkout
     Checkout As...
     ----------------------
     Rename...
     Delete...
     ----------------------
     Properties...

   CDOCheckout (open/closed)
   --------------------------------------------
     Open Checkout
     ----------------------
     New --> [allowed children...]
     ----------------------
     Open
     Open With --> [applicable editors...]
     Show In --> History
                 CDO Sessions
     ----------------------
     Compare With --> Each Other
                      ...
     Switch To --> New Branch...
                   [branch history]
                   Other...
     Merge...
     ----------------------
     Delete Checkout...
     Close Checkout
     ----------------------
     Properties...

   EObject (including CDOResourceNode)
   --------------------------------------------
     New --> [allowed children...]
     ----------------------
     Open
     Open With --> [applicable editors...]
     Show In --> History
                 CDO Sessions
     ----------------------
     Compare With --> Each Other
                      ...
     Switch To --> New Branch...
                   [branch history]
                   Other...
     Merge...
     ----------------------
     Delete...
     ----------------------
     Properties...

Provide Drag And Drop Support

I also plan to support drag and drop between CDOCheckouts, as well as between CDOCheckouts and normal workspace projects (by reusing CDO's existing resource transfer framework).

Benefits

As a result I hope to achieve the following benefits:

1. More functionality for all CDO users (including Papyrus/CDO users).
2. Better consistency between normal Papyrus usage and Papyrus/CDO usage.
3. Less CDO-specific code in Papyrus.

CDO UI Architecture

This section shows how the architecture of the CDO UI will change.

Status Quo and Plugin Removals

New CDO Explorer Plugins

CDO Explorer Design

The following diagram shows the new concepts of the CDO Explorer and how they relate to each other. The "Connection" concept is identical to the new CDORepository interface.

The following diagram shows what properties need to be managed for each "Connection" (CDORepository) type.