What are aspect model extensions for

JWT provides a mechanism allowing to store typed custom information in workflow models, thanks to an additional *_conf file (actually, it works for any kind of EMF model). Profiles describe what kind of additional information (or Aspects) can be stored on model elements. Such profiles and aspects can be provided by JWT integrators to let their users provide complex information needed by their custom features, or designed by end users to let them add information as simple as key-value properties.

Example : open this TODO metamodel, it should show custom information.

Enabling model extensions

To enable its custom Conf in your (workflow) model : if it is not already enabled for your xxx.workflow model, i.e. if it has no custom Conf already (xxx.workflow_conf file),

start from a vanilla (workflow) model xxx.workflow and open it.

open the ManageProfiles UI. One way is to select the corresponding editor sheet, or open it if it is not already by right click > Editor sheets > Manage Profiles. Another way could be : right click and select ExternalActions > ManageProfiles, which opens the ManageProfiles dialog.

Since there is no conf yet, the ManageProfiles UI is empty and only permits to activate profiles by clicking on a button

click on this button, which creates a related, empty conf file, named xxx.workflow_conf .

Creating custom aspect model extensions

Setting up simple (key-value) additional model extensions

This can be done (without code nor EMF design) thanks to the jwt-we-conf-property official JWT metamodel extension :

put the (workflow) model file in profile design mode (also called "embeddedConf" mode, by using the ManageProfile UI, or the PropertySheet on the ConfModel). This will allow the (workflow) model to directly use profiles available in its _conf file, and not only Profiles that are provided by the JWT installation.

create your own custom Profile in the _conf file, ex. by right-click > New Child> Profile on the ConfModel in the outline. Give it a distinct name and URL.

then start designing and testing new Property aspects in it :

ex. define one (or more) aspect(s) on your Profile using right click on it > New Child > New Aspect

then select jwt.we.conf.property.Property as its aspect instance type,

also give it a unique id and select which model element type(s) it will be available on

optionally, disable "autocreated" (so it will not be automatically created on any newly created node but will have to be created explicitly), enable "multiple" (so more than one can be created) or give it a default value (works only with primitive types for now)

and when they are ok, export it using the ManageProfile UI to astandalone .conf file,

which you'll register in a plugin or put in the "conf" autodiscovery directory of your JWT installation.

Now you can put the ConfModel's "embeddedConf" property to false again, since your new profile is available among the installed ones.

Therefore you can start using your custom designed model extensions in (workflow) models as shown previously.

NB. as said, property information and configuration are stored in the *_conf file, which must be provided along with your (workflow) model file

EMF model extension alternatives

If you're developing an EMF-based tool, there are three ways to add custom information to an EMF model :

extend an existing type of the model with your own type. This is only interesting to create well identified subtypes, i.e. that could have been provided in the base model beforehand. If it is the case, please consider contributing it to JWT's core metamodel. See an example in jwt-we-plugins/jwt-we-sample-aspectchildextenders .

add instances of your own type to an openly typed reference (Any, EObject...). This is a good all-around solution but requires that such a reference exists in the model, and doesn't provide management of information coming from different third-party providers. Therefore we didn't do so in JWT.

manage instances of your own types in another model that let them refer to the main model's elements. This non-intrusive solution works with any model without prerequisite and allows to share type extensions between model types. In JWT, Aspects do this in a simple, typed way that allows for having custom-information coming from different third-party providers, while the genmodel file is a more complex example.

Allowing aspects (jwt-we-conf*) in your EMF model

put the aspects (jwt-we-conf*) plugins in your plugin Feature

let your model plugin depend from jwt-we-conf and the base classes of your EMF.edit's ItemProviders extend AspectsEnrichedBaseItemProvider rather than BaseItemProvider. This enables right-click > New Child > aspectxxx commands, as well as aspect behaviours (mainly autocreated aspects). Alternatively, you can write its code in your root generated class.

that's it ! If you want, you can now also develop a custom Property Sheet tab for your aspect, or a view, an editor sheet...