Damus et Capimus

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.