Sphinx/digests

Dynamic workflows

• Based on MWE2 workflows
• Can be written in Java or Xtend
• Can operate on EMF models (handed in and out via slots)
• Dymamic execution of workflows located in workspace (i.e., within same JVM instance)
• Execution of binary workflows located in workflow contributor plug-ins

Extras

• Command line execution
• Workflow handlers (pre/post run hooks)
• Support of metamodels without Sphinx integration

How-tos

Create a new dyamic/binary workflow

• Create a plug-in project in runtime/development workspace
• Add a dependency to the org.eclipse.sphinx.emf.mwe.dynamic plug-in
• Create a Java or Xtend class that extends WorkspaceWorkflow
• Create Java or Xtend classes that extend AbstractWorkspaceWorkflowComponent or AbstractModelWorkflowComponent
• Add workflow components to workflow

Contribute a binary workflow

• Use org.eclipse.sphinx.emf.mwe.dynamic.workflowContributors extension point

Run a dynamic or binary workflow interactively

• Right-click on workflow file to execute or model file(s)/element(s) to operate on
• Select Run Workflow > Run...

Run a dynamic or binary workflow from the command line

• Use org.eclipse.sphinx.emf.mwe.dynamic.headless.WorkflowRunner application
• Specify workspace-relative workflow path or qualified workflow class name using -workflow option
• Specify absolute/relative model file/element URI using -model option

Create a workflow handler

• Use org.eclipse.sphinx.emf.mwe.dynamic.workflowHandlers extension point

Check validation

• Lightweight approach to model validation
• Based on EMF's EValidator and Diagnostician
• Constraint logic in Java or Xtend classes with @Check annotated methods
• Optional externalization of severities, messages, etc. to EMF-based check catalog
• Organization of checks in categories
• Produces EMF Diagnostics and Eclipse problem markers
• Dedicated Check Validation view

Extras

• Navigation from Check Validation view entries to related model element
  • Double-click => associated editor
  • Show-In menu => Model Explorer, Project Explorer, Properties view
• Execution of EMF's intrinsic model integrity constraints (EObjectValidator)
• Execution of check validations in workflows

How-tos

Create a new check validator

• Create a Java or Xtend class that extends AbstractCheckValidator
• Create check method(s) that have
  • an @Check annotation
  • precisely one parameter through which the model element to be checked can be passed
• Implement check logic and issue findings using protected error()/warning()/info()/issue() methods
• Contribute check validator using org.eclipse.sphinx.emf.check.checkvalidators extension point

Run a check validation interactively

• Right-click on model file(s)/element(s) to be checked
• Select Validate > Check-based Validation
• View result in Check Validation view

Create and use a check catalog

• Create a copy of /org.eclipse.sphinx.emf.check.catalog/model/samples/Empty.checkcatalog and open it in Sample Reflective Ecore Model Editor
• Edit Catalog properties and add Category and Constraint children as appropriate
• Associate check methods in check validators with constraints by adding a constraint field to the check method's @Check annotation that refers to the id of the corresponding constraint in the check catalog
• Optionally restrain applicability of the check method by adding a categories field to @Check annotation that lists only a subset of the categories referenced by corresponding constraint in the check catalog
• Issue check findings using protected issue() method rather than error()/warning()/info() methods
• Contribute check catalog and associate it with contributed check validators using org.eclipse.sphinx.emf.check.checkvalidators extension point

Reference information

Diagnostic usage

• severity => Constraint severity as per error()/warning()/info() method invocation or check catalog
• source => Qualified check validator class name
• code => not used, always 0
• message => Constraint message as per error()/warning()/info() method invocation or check catalog
• data =>
  • DiagnosticLocation referencing affected model object and feature in first position
  • SourceLocation referencing underlying check validator class, check method and constraint id in second position
  • optional user-defined data as per error()/warning()/info() method invocation on subsequent positions

Check Problem marker usage

• EValidator.URI_ATTRIBUTE &arr; URI of affected model object
• IMarker.LOCATION &arr; Name of affected model object class and feature extracted from diagnostic data
• IMarker.SEVERITY &arr; Diagnostic severity
• IMarker.MESSAGE &arr; Diagnostic message
• IMarker.SOURCE_ID &arr; Constraint id or name of underlying check validator class and method extracted from diagnostic data if available or diagnostic source otherwise