Bug 429242 - [CDO] [Resource Management] Refactoring of the 3-files model and PageManager
Summary: [CDO] [Resource Management] Refactoring of the 3-files model and PageManager
Status: RESOLVED FIXED
Alias: None
Product: Papyrus
Classification: Modeling
Component: Core (show other bugs)
Version: 1.0.0   Edit
Hardware: All All
: P3 critical (vote)
Target Milestone: M6   Edit
Assignee: Christian Damus CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 429239
Blocks:
  Show dependency tree
 
Reported: 2014-02-27 09:34 EST by Christian Damus CLA
Modified: 2014-03-25 15:21 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Damus CLA 2014-02-27 09:34:10 EST
Cloned from bug 429239: [Resource Management] Refactoring of the 3-files model and PageManager

Once the refactoring of the page-manager/sash-model is completed in the referenced bug, the CDO Integration feature will have to adapt to the discontinuation of *.di resources in the persistent store.

Currently, the SashWindowsMngr element and *.di resource are used by the CDO layer as representative of a "Papyrus Model".  This is particularly evident in the Model Repositories view, which actually performs a server-side OCL query retrieving all SashWindowsMngr instances to present the containing *.di resources as logical models in the resource tree.  This query, as well as the presentation of the view and implementations of several menu actions, will have to be re-designed.
Comment 1 Christian Damus CLA 2014-03-05 08:46:56 EST
Hi, Camille,

The storage of sash models in the workspace metadata area currently (in the prototype branch) indexes the *.sash resources by model URI (in folders rooted at platform\:/resource/ for workspace resources and cdo\:/ for CDO resources).  This will not work as is for CDO because the resource URIs are unique only within a particular CDO repository (any number of repositories can have a cdo:/home/cdamus/my.uml resource).  So, the CDO Integration layer will have to be able to plug in a custom indexing scheme for the sash models.

Also, for workspace resources, move/rename/delete refactorings of Papyrus models will need a participant to update the sash model resources.  For CDO this can be simpler because we can use the OIDs of  Papyrus model resources in the repository to correlate to the sash models, eliminating move/rename refactorings and simplifying deletes.

Is the prototype in a state where I can contribute (to the branch) enhancements such as pluggable sash model indexes and refactoring participants?
Comment 2 Camille Letavernier CLA 2014-03-05 09:15:34 EST
Hi,

> Is the prototype in a state where I can contribute (to the branch) enhancements such as pluggable sash model indexes and refactoring participants?

I will push a few commits real soon. Except for the empty *.di file on new model creation (I still don't know what should be inside now), it should be close enough to the final result (At least from the model's point of view; not for the integration and bug fixes).

I've handled the "Save as" action already, but not the Refactoring participants. Some code will probably need to be refactored out of the SashModel to some public helpers.
Comment 3 Christian Damus CLA 2014-03-05 17:55:11 EST
I have pushed a few commits to the bugs/429239-models branch to support the CDO Integration layer.

Commit 8360424:

Introduces a new oep.infra.core.sashModelProvider extension point for registration of ISashModelProviders.  These plug in alternative storage schemes for *.sash resources to account for the needs of different model resource persistence domains.

Commit ef02345:

Implements a sash-model provider for CDO that accounts for the fact that resource URIs are unique only within the scope of a particular CDO repository.  Also adds the "Open With Papyrus Editor" action to the context menu of the Model Repositories view so that resources (e.g., *.uml) that don't have *.di components can be opened in the Papyrus editor.

Commit 67177b2:

Adds an optional fileExtension attribute to the oep.infra.core.model extension point to indicate the canonical resource file extension for an IModel.  This allows clients to determine whether a resource URI is recognized by Papyrus as something that it manages using an IModel in the ModelSet.  The Model Repositories view uses this to open the Papyrus editor by default when a *.uml or *.notation resource is double-clicked.

The UML (*.uml), Notation (*.notation), DI (*.di), and Sash (*.sash) models all add this attribute to their extensions. 

Commit 0a9c858:

Updates to account for the fact that we now implicitly create an empty *.di resource when opening a model in the model-set that doesn't yet have one.  Two specific changes:

  * update the server-side OCL query for DI resources to include resources
     with *.di extension that are empty (in addition to legacy resources
     containing a SashWindowsMngr element)
  * ensure that the empty *.di resource that is created when opening a model
     in the Papyrus editor that doesn't already have one is properly persisted
     in the repository
Comment 4 Christian Damus CLA 2014-03-12 09:29:57 EDT
Commit 1d4f894 fixes a problem in the server-side OCL query on repositories that do not contain any legacy models (in which the *.di resource contains a sash model).

Barring any further changes in the blocking bug 429239, that completes the CDO Integration layer's adoption of the new sash model management scheme.
Comment 5 Christian Damus CLA 2014-03-25 15:21:34 EDT
The dependency is completed.