Community
Participate
Working Groups
Currently, much of the ModelSet/IModel and related API is defined in terms of IFiles and IPaths. This ties the API to persistence of UML models in the Eclipse workspace. For the CDO context, a more abstract API based on URIs or some other suitable abstraction is required. As much as possible, this should be a backwards-compatible evolution of the current IFile-centric API.
I'll take this on.
The scope of this enhancement includes a CDO-aware implementation of the ModelSet service, for which I have a prototype in progress.
r9981 on cdo_kepler branch: Deprecated all of the methods in ModelSet and IModel that accept IFiles as identifiers of the "model" resources, replacing them with equivalent API using URIs. As much as possible, the IFile-based implementations delegate to the URI-based implementations for backwards compatibility. Clients of the ModelSet and IModel, in editors, wizards, etc. are updated to use the new URI-based APIs. Additionally, the ReadOnlyManager for determining whether resources are not editable by the user, although the API is based on URIs, still depends largely on IFiles. In particular, all of the IReadOnlyHandlers currently implemented assume that there is a file either in the workspace, or in SVN, or whatever that has read/write permission state. Because CDO resources do not trace to files of any kind, the default file-based handlers just assume that they are not editable (i.e., they are read-only) because they must be in plug-in JARs or something. A CDO-aware IReadOnlyHandler can indicate that the resources are not read-only, but all handlers of lower priority are still consulted until one returns a read-only answer. Therefore, a new IReadOnlyHandler2 interface is defined that may be implemented to tell the ReadOnlyManager that the handler definitively knows the read-only-ness of a resource, and no other handlers of lower priority should be consulted.
Also in r9981 on cod_kepler branch: The ModelSet::registerModel(IModel) API is changed to add only the most specific IModel implementation for the same key, to avoid creation of repeated resources when creating a model. Also, the AbstractBaseModel::createModel(...) API is updated to check whether the resource to be created already exists, instead of creating a duplicate. For example, previously, both the NotationModel and the CSSNotationModel (which specializes it) would be added to a ModelSet. When, later, the ModelSet::createModel(...) API is called, both of these IModels would create their xyz.notation resources in the ModelSet. This is not a problem in a regular EMF ResourceSet, because the first xyz.notation is the only one that is "visible" or "addressable"; the other one is shadowed and doesn't have any effect. However, in a CDO-managed resource set, this is an error and a transaction with duplicate resource URIs in its resource set will fail to commit.
r9996 on cdo_kepler branch: Committed initial implementation of CDO-aware implementations of various Papyrus services, including: - CDOAwareModelSet (specializing OnDemandLoadingModelSet) - CDOAwareTransactionalEditingDomain - CDOReadOnlyHandler - PapyrusDawnResourceImpl The last item above is a specialization of Dawn's specialization of the CDOResourceImpl, which caches the resource URI for access without locking the transaction, to prevent deadlocks in the UI caused by interactions with the ReadOnlyManager.
r10380 These changes have been merged to trunk. Some new IPath-based API, the IVersionableModel interface, was added since the initial refactoring. But this API will not be applicable in the CDO context, so it is not in the scope of this enhancement.
