Papyrus Model Repositories: Creating New Models

Last week, I introduced the in-progress integration of CDO model repositories into Papyrus for the Kepler release.  The starting point was migration of existing models from the Eclipse workspace into a repository.  But, what if you don't have models, yet?  Do you have to create them in the workspace first, then suck them into a repository?

Not any more!

The latest development on the cdo_kepler branch in Papyrus SVN has refactored the New Papyrus Model wizard to allow creation of models in either a repository or the workspace.  See the video after the break to take a tour.

The New Model Wizard implements all of the following scenarios for model repositories:

• Create a new UML model, UML profile, or SysML model
• Initialize a new Papyrus model (especially the diagrams) from an existing domain model (UML resource)
• Choose a folder to contain the new model, which is pre-filled from the current workbench selection if possible

In the case where there isn't a workbench selection, or it doesn't provide the context of a workspace or repository in which to create the new model, a new initial page lets the user indicate in which persistent store (workspace or an available repository) to create the new model.

The same wizard implements the New Papyrus Project function, too.  But, as this is naturally workspace-centric, there is no equivalent for model repositories.

See bug 401197 for more code-level details.

Papyrus Model Repositories

The M5 milestone of the Kepler release brought support for UML models in CDO repositories to Eclipse.  I wrote then that this provides a foundation for collaborative model editing in Papyrus using CDO.  Well, that work has progressed far enough that I can offer a preview of Papyrus on CDO in action.

Here is a short video introducing, in less than 15 minutes, an early stage of CDO integration in the Papyrus workbench, including:

• Adding repositories to the Model Repositories view
• Importing models from the workspace into a repository
• Editing models and seeing changes committed by other users
• Managing locks on objects for exclusive access
• Conflicting edits and resolving conflicts
• and possibly more

You can check out the latest SVN trunk and overlay the cdo_kepler branch from Papyrus SVN, on the Kepler M5 milestone of UML2 and CDO, to play with this yourself. Development is being tracked in bug 290952 and its dependencies.  Offer your comments in these bugs.

Connect and Share Your UMLs

The Eclipse CDO and UML2 projects have both published their M5 milestones on the road to the Kepler release. In this milestone, UML models can now be shared in CDO repositories!

A lot of fixes and enhancements have gone into this milestone of both the CDO and UML2 projects to make UML models fully functional in CDO repositories. In several ways, some small and some big, UML is a peculiar EMF model. It implements some specialized structural semantics (e.g. subsetting) and awkward overrides (e.g. redefining a mutable reference as derived). It is an unique EMF model. So, quite natural that it should have required work in both CDO (to make allowances for UML) and UML2 (to conform to EMF/CDO norms) to get the two playing together nicely.

More details after the break.

All of the following peculiarities of UML modeling should work as expected in the CDO context:

• subset/superset properties
• static profiles
• dynamic profiles, both
• registered on the UML profiles extension point (and in EMF's dynamic package registry, of course)
• stored in the CDO repository
• activities and enumeration literals (both cases of feature redefinition or other semantics not supported by Ecore)

Although dynamic profiles work, there are consequences to be considered. Most importantly, because the CDO server maintains a package registry in a separate area of the data store, and every package in that registry is immutable and cannot be deleted, it is more difficult to clean up profile definition versions in CDO than in file storage. Effectively, any profile definition that is actually used (to create stereotype instances) is stored twice, and one copy is etched in stone.

The support for UML persistence leverages CDO's "legacy mode", which bolts on the CDO magic that otherwise is baked into a model by generating it specifically for CDO.  This avoids having to juggle two different UML implementations, sacrificing only some advanced data scalability features.  Thanks to Martin Flügge for his pioneering work on the legacy mode and Dawn, which provides an integration of CDO in GMF-generated diagram editors.

This milestone serves as a foundation for integration of CDO into Papyrus, for sharing of Papyrus models in CDO repositories, in the Kepler release. To follow the progress of that work, add yourself to the CC list of this bug and/or its dependencies.

In theory, all of this should work as well for persisting instances of UML-based models as well as for the UML metamodel, itself (although this has not yet been verified).  UML2 extends EMF's code generator to support such constructs as feature subsetting and redefinition and, if you happen to be using UML to build you own modeling language, even profiles.  If you use UML instead of Ecore to define your models, now they sold be compatible with CDO using the "legacy mode" (the UML2 run-time's support for subsetting doesn't work with "CDO native" models).

So, grab the Kepler M5 Modeling Package and start sharing your UML models! Please report problems in the usual way, in Eclipse Bugzilla and the forum. I suggest posting questions first in the forum so that we may determine whether the issue needs to be addressed to the CDO or the UML2 project.