Validation in Papyrus Model Repositories

One of the most important things we can do with our models is to validate them, testing them against general-purpose and domain-specific well-formedness rules.  Last week, we saw how to reuse packages from models stored in a repository in the Papyrus Kepler release.

This week, we take a look at validating models.  After all, you wouldn't want to share and re-use packages that aren't up to muster, would you?  See a short demonstration video after the break.

The latest code on the cdo_kepler branch in Papyrus SVN evolves the presentation of validation problems in Papyrus beyond Eclipse's workspace resource markers to support annotating model elements in CDO resources (or any other EMF resource, for that matter) with diagnostic information.  Essentially, Papyrus implements a modeled analogue of workspace markers in a new friendly UI that better presents the context of problems.

Have a look at the short video above and check out the branch to play with model validation, yourself!  Or, wait a few days for the first regular Papyrus nightly build that will actually deliver all of the CDO goodness that we have seen so far.  Integration of the branch into the development main-line is in progress as I write this post.  See bug 290952 for details of the merge.

Properties View Customization in Papyrus CDO

Last week's instalment of the CDO integration tech preview series for the Kepler release explored model validation in repository models.  This week, we take a look at customizing the Properties View.

Papyrus offers end users a powerful model-driven solution for customization of the Properties View.  This enables a convenient UI for editing model elements tailored to what's important in a specific domain, such as SysML, MARTE, or whatever you can invent yourself.  In the Juno release, the models that describe the Properties View are stored in the local workspace's metadata area.  Now, we bring them into the repository to share and access from any workspace.

Have a look at the video after the break for a quick (less than 10 minutes) tour.

The models defining the customization of the Properties View comprise three main components:

• Context model, connecting the organizational structure of views, tabs, and sections to The definitions if the UI and data context that determine the elements to which they are applicable
• EMF Facet query models defining constraints that select which elements any particular tabs or sections apply to
• XWT files containing the XML definitions of the UI: the property editor widgets

The XWT content poses an interesting conundrum:  the engine that parses these files and instantiates the UI at run-time has no knowledge of EMF models or EMF resources and uses URLs to access XML text and JAXP to parse it.  Moreover, the UML property sheet definitions comprise a large number of XWT files.  Dozens upon dozens.  Trying to retrofit all of this infrastructure onto EMF models would be a large undertaking, rather pointless (because it already works), and wouldn't scale well.  An initial naïve experiment in loading all of these files as EMF-based model resources performed horribly in a local repository on a MacBook Pro with SSD storage.

Happily, the Kepler release of CDO provides exactly what is needed for this situation:  CDOTextResource.  This is a new kind of resource node that effectively provides a URI for a CLOB (character large object storage in the database).  So, Papyrus stores customization models in the repository in a raft of text resources in the same hierarchical "file" structure as in the workspace.  The context models a loaded into plain XMI resources persisted in the CLOBs, and the XWT files are accessed directly by the UI engine via Java URLs with a custom stream handler (using EMF to get I/O streams on the CDO URIs).

The end result is efficient storage of model and non-model data in the repository.

Apart from all of this, maintaining these customization models in the repository requires some resilience in the Properties View and clean handling of the volatility of connections to the repository, which is different from the workspace that is assumed always to be "connected".  Papyrus keeps track, in the workspace metadata, of the properties view context models that it knows about. When a repository connection is opened, any contexts that it contains are discovered and made available to the UI.  When a repository connection is closed, contexts are removed from the UI.  And, because the models are in a shared repository, other users can make changes to them.  These changes are pushed into the UI of other connected Papyrus workbenches in real time.

Have a look at the video above for a taste, and then check out the latest code from the cdo_kepler branch in SVN to play with it, yourself!  And see bug 402961 for all of the gritty details.

Reusing Packages in Papyrus Model Repositories

In last week's instalment of the Papyrus Model Repository tech preview series, I showed how to create new models in a CDO repository.  This week we look at reusing model content by importing packages and applying profiles from models stored in a repository.

The latest development on the cdo_kepler branch in Papyrus SVN refactors the "Import Package From Workspace" and "Apply Profile(s)" dialogs to support pluggable model import sources, including CDO repositories in addition to the Eclipse Workspace.  Also, the workflow in these dialogs is stream-lined a bit and some of the code that handles profile migration is generalized to work with non-XMI resources.  See the video after the break to take a tour.

The guts of the package import action are factored out into a new reusable dialog with an extension point that plugs in "package import sources".  These provide the dialog with:

• a content provider to present a tree in which to browse for models
• a label provider for the tree content
• validation of user selections
• extraction of packages from the user selection

Workspace content is provided by default and the CDO integration plug-ins provide the contents of currently connected model repositories.

In the Juno release, for every model file that was selected by the user in the first package-import or apply-profile dialog, another dialog would pop up asking the user which packages(s) to import or profile(s) to apply from each file.  This repetition of the dialog is now replaced by a single dialog that presents all of the packages/profiles found in all models selected by the user.  In the case of importing packages, the dialog's selection tree has a second column in which the user elects whether to import or copy each package.

The package import dialog is sensitive to the context of the package into which the user is importing content.  Each import source is queried whether it is supports importing into the user's selected package.  This allows the CDO provider to be excluded for packages in workspace models, because dependencies from the workspace to a model repository are discouraged.  However, the workspace import source is enabled on packages in the repository.

Check out the latest cdo_kepler branch in Papyrus SVN to take this for a spin, yourself!