JWT Metamodel Extension Specifications/WE

Metamodel extensions and JWT WE - overview

Or : how should the JWT Workflow Editor behave in the case of metamodel extensions ?

Now that we've got a basic idea of how it could work at model level, let's focus on what is its first use : display and edition in JWT WE.

Let's remember JWT WE comprises the following display and edition capabilities :

• JWT GEF / EMF diagram
• JWT EMF outline
• JWT EMF property view
• aditionally, the JWT EMF property view could be enhanced by custom tabs
• aditionally, custom views could be made

As said before, we prioritize manipulating metamodel extensions in a generic (i.e. JWT outline and property view) or vendor specific view. It is enough and evacuates GEF diagram extension complexities. We will here focus on what JWT WE itself provides : the JWT outline and property views, and how it should best behave in the case of metamodel extensions.

NB. What is possible with extensions should be as much as possible specified in the ecore metamodel, since not only will it improve what features the generated EMF editors provide by default, but it will also prevent any illegal, non-conforming workflow model. However we obviously won't limit features to what EMF provides. So these needs could be additionally implemented through an additional behaviour metamodel, adapted or custom UI code or UI code generation - or even through ecore customization (see http://www.ibm.com/developerworks/opensource/library/os-eclipse-emfmetamodel/ ) though it would be hard to maintain and not agile enough.

Metamodel extensions and JWT WE behaviour

How do we want extensions / Aspects to behave in the Workflow Editor ?

functional needs

Based on the previous metamodel extension ideas, and on trying things with the above sample and others, I've listed the following functionalities, from "most required" to "nice to have" ones :

• "single" and / or "unique" : to limit instanciation of an aspect of a given type to at most one, or exactly one (i.e. pre-instanciated). Useful for all aspects that model "activable features".
• (optional) "undeletable" and / or "readonly" : to forbid deleting it (or require it to be instanciated again).
• "instanciation" : to require instanciation of an aspect or aspect list on a model element. This could be 1. a globally defined list, in JWT release configuration (or possibly user preferences ?) ; 2. a user-chosen list at model element instanciation time, by letting him chose an aspect list or a profile (aspect list)
• "aspect choice list" : restrain aspect instanciation to at most one of a given list of aspect: "single" and / or "unique" property on an abstract Aspect that is a common ancestor to all aspects of the list ; ex. at most one aspect specifying what "does" a given Action, by making all such Aspect types inherit from the same ApplicationAspectTemplate, which has its "single" property set to "true", or making this abstract aspect inherit from ListConstraintAspect ; cons : requires to introspect inheritance to know the list
• restrain an aspect type to be instanciated on model elements of a given type : using aspect subtypes, ex. ActionAspect, ModelAspect ; cons : complexifies aspect creation
• other custom rules required by the extension developer

technical solutions

• solution 1 : by configuring those features in "special" properties of Aspects, like "singleton", "removable". For example, EMF / XML uses such special properties (ex. "xmlns:prefix"). However, these properties configure how the behaviour of the Aspect type (how it is instanciated etc.), and not of each of the Aspect instances, and therefore are not at the appropriate conceptual level, which complexifies their understanding.
• solution 2 : modify ecore genmodel to store these information at the right conceptual level, and the EMF ecore JET templates to exploit them at generation time. However besides being difficult to do and maintain, it has not the level of flexibility we need : supporting new Aspect behaviours by adding new information there would be just as costly.
• solution 3 : using a custom "metametamodel", that would also be in line with future jwt-views management, like Christian Saad advocates. Developing it in EMF would the development of an editor, while still allowing to package it in different ways : standalone, in a plugin.xml extension, or even bundled within a .workflow.
• other custom rules required by the extension developer would however require coding : either by implementing them in their own custom view UI, or by modifying EMF-generated code or generation templates (EMF.edit's ItemProviders), or even palette ? policies ??

specifications

A gordian knot answer to these is to say that aspects can only be

• either "singleton", i.e. instanciated along with a model element,
• or "feature" (transversal, activable feature), that can be added or removed on its own ;

configure their behaviour in an additional metamodel comprising

• singleton or feature
• extension name and version
• their assigned model element
• Instanciating a model element with different singleton aspect sets can be made available using additional "newChild" commands

and to delegate as much of the complex requirements as possible to the aspect implementors :

• choice list is done within aspects
• as well as more complex features

Metamodel extensions and JWT Views

JWT Views are a way to customize how a Model is displayed. For now it is able to configure which model elements and subelements are displayed. Note that in the future, this functional perimeter may be extended / included in the issue of JWT configuration and packaging.

How do work JWT views :

• edited in swing application jwt-view, by using the above cited code, using the ecore with harcoded path "jwt-we/src/org/eclipse/jwt/we/model/WEMetaModel.ecore" (but if there's none, allows to choose it) ; AppWindow saves the view name in the plugin*.properties files of jwt-we
• handled in the org.eclipse.jwt.we.misc.views package of jwt-we : read by ViewResourceManager, Views, list of the read ecore's packages built by AnalyseEcore

Enabling metamodel extension at JWT views level (propositions) :

• basis (works !) : Making it visible in the (outline) UI ! How : in Views.displayObject(), display by default (opposite of current behaviour), so model objects that are not specified in the view will be displayed. This is good behaviour, because, all default model elements will be specified in the view, and it is still possible to specify not to display one by setting it to false (unchecking its checkbox in jwt-view).
• better : in jwt-view, allow to choose another ecore, many ecores, to merge their properties
• later : change jwt-view to an eclipse plugin with an eclipse UI, make it the bases of the jwt-configuration/packaging/release-builder plugin

Metamodel extensions and JWT WE - finding and loading models and ecores

About extension loading among the various files, EMF has nice out of the box features. An XMI file that refers relatively to an available ecore extension file will load as dynamic EMF. If XML rather than XMI is used, EMF can be configured so an XMI file that refers relatively to an available XSD extension file will load as EMF / XML (thanks to XSDEcoreBuilder). And EMF can be configured to load unknown extensions as XML without schema (concretely, the EObject implementation is AnyTypeImpl), though it is of little use since it is not typed. However this is not enough.

Requirements for finding and providing extension definition files

• the end user must be able to provide them in a simple way, like a standard directory whose ecores will be loaded at WE startup (csaad) ; and another way to add one from the editor UI, like a button "add extension model" allowing to choose an ecore file.
• vendors will want to be able to have a more built-in way to provide their ecore extensions, like a path in a plugin jar, if necessary referred to in their plugin.xml .

Technologies available to find extension definition files (typically metamodel extension file, and possibly an additional extension configuration file) , from the lighter to the deeper :

• files in an autodiscovery directory
• zipped files in a workflow bundle (zipped .workflow + extension definition files)
• EMF model element in a workflow model, as a subtree of the root Model element ; works for EMF or EMF / XML built extension definitions
• files specified in an extension point in plugin.xml
• XML inlined in an extension point in plugin.xml ; works for XML or EMF / XML (not static EMF ?) built extension definitions
• files found in a fixed path in the classpath (i.e. in a vendor's extension jar)

Metamodel extensions and JWT WE - versioning

Another issue is versioning (csaad)

• Extension versioning : it requires a naming and versioning mechanism for extensions (a list of which must be centrally stored in the model file, e.g. in the model-element) to ensure compatibility. See proposition of Christian Saad for custom typed properties.
• Note that Model is already versioned.
• Model update algorithm : it should be modified so it can make the difference between model version error and extension version error (including unknown extension). Note that it is for now limited to the "addition only" changes in the ecore, which is enough.

Metamodel extensions and JWT WE - tabbed properties view (Christian Saad)

The change of the properties view to a version that supports multiple tabs (as described in http://www.eclipse.org/articles/Article-Tabbed-Properties/tabbed_properties_view.html) is quite simple. The “old” properties can be loaded into the view using an adapter, so there is almost no additional effort to this solution (see attachment). Concerning the new dynamic properties, probably a similar approach can be used (write a propertypage that reads the dynamic properties from the itemproviders, creates the corresponding propertyeditors and can be fitted into the propertyview using the same kind of adapter).