Community
Participate
Working Groups
In the Juno release, Papyrus supports creation, editing, and application of Properties View customization models stored in the workspace preferences and edited by means of a hidden project in the workspace that links to a folder in the workspace metadata area. This use of the workspace is an expedient to support standard Eclipse editors on the customization models. However, because the actual storage is in the workspace metadata, these models are not shareable with a team. Storing these models in a CDO repository would allow them to be shared, in real-time. To this end, extensibility of the Properties View infrastructure is required: - pluggable storage providers for the customization models, allowing the ConfigurationManager to discover them in connected repositories. The current workspace metadata storage would be refactored as a provider - pluggable implementations of the "Copy", "Edit", and "Remove" action buttons in the customization dialog. In the case of Copy, the dialog provides different "Copy to ..." buttons to copy a Context to each supported store. In the Edit and Remove cases, the buttons behaviour is polymorphic according to the selected Context's storage provider - update the Context model to allow a Context to reference its "prototype", the Context from which it was copied. The "Property Views" preference page caches this prototype reference when a custom context is activated. This allows the ConfigurationManager to fall back to a context's prototype in the case that the selected context is not available (such as when the repository is not connected or a directory in the workspace metadata goes AWOL). Ultimately, the prototype chain traces to a deployed standard Context that is always available.
I can work on this.
r10523 implements a CDO storage provider for Properties View customization models. Storage in the repository is implemented by CDOTextResources in CDOResourceFolders mirroring the structure in the workspace metadata area. CDOTextResources are a kind of CDOResourceNode that, unlike the CDOResource which stores EObjects as usual in EMF, stores text in a CLOB in the database. This allows for very efficient uploading of the large number of XWT files that define UML property sheets as text resources in the repository. Loading these models from the repository is fairly straight-forward. Essentially, the CDOTextResources' CLOBs are used as the persistent storage for regular XMI resources (or simply XML text in the case of the XWT files). For the *.ctx and *.querySet files that store the context model, XMI resources use a custom URIHandler to load and save the text in the CLOBs. This custom URIHandler uses a "papyrus.cdo.text" URI scheme and delegates storage to the CDOTextNode in the appropriate CDOView attached to the resource set maintained by the ConfigurationManager. The XWT API requires URLs to access the *.xwt files to parse their XML. The Java Platform provides no URL stream handler that can access CDO resources, so I created an EMFURLStreamHandler that does. It uses a URIConverter to obtain input streams in the URLConnections. When the URIConverter has the custom URIHandler described above for CDOTextResources, the XWT engine can properly load their contents. However, this does require a couple of small fixes in Papyrus's XWT implementation. So, the org.eclipse.papyrus.xwt plug-in is branched on the cdo_kepler branch. The problem was that XWT would take the string values of URLs and create new URLs, sometimes by combining strings, without accounting for the fact that the URL originally passed in from the client may have had a custom URLStreamHandler assigned. This is fixed in a distinct commit r10522 by ensuring that the baseURL is always propagated in the construction of new URLs based on it, so that the stream handler is also propagated. Finally, because CDO repository connections may come and go, the context storage provider notifies the ConfigurationManager of available contexts when a repository is connected and deletes contexts when a repository is disconnected.
r10548: This latest commit adds the "prototype" model. When a context is copied, it gets a reference to its prototype, the context from which it was copied. The preferences model caches the prototype references (in the descriptors) so that, in the case where a context that the user had applied is temporarily unavailable, the one from which it was copied can be implicitly enabled so that the user doesn't lose property editors.
r10549: Added an additional "deleted" attribute to the ContextDescriptor in the Preferences model. This allows to distinguish between the two reasons why a context may be unavailable: * it has been deleted by the user * it has gone missing because its persistent store (e.g., CDO repository) is temporarily off-line The ConfigurationManager now provides API to obtain proxies (not the EMF kind) for Contexts that are missing, and these are shown in the preference page with the usual enablement state and a "(missing)" decoration in the label. This allows a user to deselect these if necessary while they are not available because, as per the earlier commit, they may cause prototypes to be implicitly enabled. It's also just useful to the user to know which contexts that are expected to be available currently aren't. Deleted contexts are still retained by the preferences model as before, to keep the "applied" state, but now have "deleted" state to distinguish them from missing contexts.
r10550: Added handling of remote commits to property view contexts stored in the repository, triggering refresh in the ConfigurationManager. Also introduced pop-up notifications to inform users when the currently applied contexts change due to storage provider events: * contexts coming on-line when repository connected * contexts going off-line when repository disconnected * contexts edited by another user
This enhancement was merged to trunk in r10701, which is in M7 milestone. Some lingering issues still need to be addressed, so it remains open.
Created attachment 229104 [details] Patch for extraneous "missing" descriptors in preference page Attached a patch to address the problem of workspaces migrated from Papyrus 0.9 (or previous milestones of 0.10) showing extraneous "Xyz (missing)" context descriptors in the Properties Views preference page. This patch introduces a version number to the Preferences model. The default value is 1 (the Juno and earlier model). The current value for Kepler is 2. A new migration step is introduced in the initialization of the ConfigurationManager to migrate the Preferences model from a previous version to the current version. So far, there is only one migration step (from version 1 to version 2) and the only action performed is to identify contexts that look like they must have been deleted under the Preferences version 1 regime and mark them as such so that they will not be presented as "missing".
Hi, Camille, I have attached a patch that addresses the problem you raised to me about extraneous "missing" properties view contexts appearing in the Properties View preference page. I have tested it by introducing a bunch of fake contexts in the preferences XMI (with 'applied="false"') and seeing that they do not appear in the preferences page. When you get a chance, I would appreciate your review of these changes. Thanks!
Created attachment 229106 [details] Updated patch for extraneous "missing" descriptors Updated the patch with a missing abort of the migration when an unknown version number (probably mostly likely to be a future version) is encountered.
Sounds good, it now behaves as expected
r10749: Committed the patch (attachment 229106 [details]) described in comment #7 and comment #9.
