Feedback

Building a DSL with Eclipse Sirius

  • Project Overview

  • Structural organization (in-short)

  • Eclipse plugins development

Project overview

Convert Rational Rose Extensions into Eclipse plugins

  • From UML stereotypes to Ecore classes

Targeted DSL was broad:

  • 300+ classes, 350+ properties

  • A lot of Stereotype packages transformed into 4 Emf Packages

Edition features

  • Few types of diagrams were expected (4)

  • but all properties to edit through Sirius:EEF and dispatched in 4 tabs.

Structural organization

In-short (not the focus)

  • Code: Maven/tycho, gerrit, Jenkins, Oomph,

  • Doc/management: Jira/Confluence Model-Driven agile

Notable elements

A replicable structure for POM as the project are divided in 3 Gits

Layout files to keep consistency between Oomph descriptors and Maven/Typho TPD

Reproducing Eclipse Nature philosophy in POMs using POM Parent and profile

  • For example: Xtend or projecting including code generation

Development: Limits of model-driven approach

  • Using Genmodel

  • Writing Sirius Model

Using Genmodel

A lot a boiler plates in code and hard to identify specific from mundane.

Poor handling of multi-inheritance.

Even with EmfLoopHole, customization of ItemProviderAdapter is painful.

Editing plugin.properties file was laborious du to size.

Writing Sirius Model

(Un)Fortunately so repetitive

  • Able/Compelled to dev of a creation wizard. [ :-( ]

  • As one-shoot strategy, wizard lacks flexibility when modifying Meta-Model.

Resulting ODesign is huge !

Retrospective analysis

Needs and constraints:

Needs ?

Extend meta-model in seamless way with the implementation.

Avoid generation for customization an Ecore Element.

Modifications of meta-model leads to compilation errors.

Constraints

Different aspects should be attached in a readable unit of code:

No structural switch splitting functional rules.

Be able to choose between:

  • grouping by feature (validation, edition, …​)

  • grouping by semantic (package or EClass)

For 1 element, Display, validation or actions could be in 1 class.

Proposition

Extending meta-model by code:

  • Readable syntax (no eAnnotation).

  • Real typed-approach: no symbolic code like in plugin.xml extensions.

Expected code

// A Emf Class is extended
XxNamedElement->label += [ name ]
XxNamedElement->diagnostic += [ name ]
  String->,
  Diagnostic->#[ // Validation Defining validation rule
    "EmptyName"->error->[XxNamedElement| name==null || name.trim.empty ],
    "HiddenCar"->warning->[XxNamedElement| name!=null && name.trim != name ],
  ]
]
// Extended features
//   EEF: Property accepts carriage return.
abstractConstrainedMethod_Precondition += multiline
abstractConstrainedMethod_Postcondition += multiline
abstractError_QualifiedName += shown
abstractError_Domain += shown
abstractExtendedReturningMethod_ReturnTypeDocumentation += #[ Tab->Tab.documentation, multiline ]
abstractReturningMethod_ReturnTypeDocumentation += #[ Tab->Tab.documentation, multiline ]
//   EEF: Property in a specific category.
abstractRootElement_StandardGeneration += Tab->Tab.generation
abstractRootElement_ErrorGeneration += Tab->Tab.generation
abstractType_AllAttributes += hidden

How to use

Project https://github.com/mypsycho/modit

Extending BOEM approach: model-by-code.

Available API

A singleton of EmfStrecher works on a group of EPackage, registers specificities and provides inheritance mechanism.

EmfContribution provides a factory to wrap singleton creation and initialization.

Major features (edit, validated, etc) can supported by 1 engine based on EmfContribution keys and running with an EmfStrecher.

Example for Sirius

Definition of singleton: EqxModelExtensions

Contribution of model: EquinoxeCoreContrib, EquinoxeComposantsMetierContrib, …​

code sample

Engine of Sirius (limited to EEF part): 1 simple class (<500 lines).

SiriusGenerator

Complements

Other available elements:

Reverse existing models

For Genmodel, Sirius, test resources, …​

EReversIt generates Xtend classes matching any EMF model.

Eases detection of pattern in models.

Use case: Round-trip with Sirius

  • Edit in run mode

  • Reverse to code

  • Update engine accordingly

I18n with Xtend

Syntax of i18n Edit plugin or Eclipse is messy and limited.

Xtend syntax leads to a Class-based approach.

Typed approach (not only String).

Using Xtend template instead of tricky pseudo MessageFormat.

Possible complements

  • ItemProviderAdapterFactory In progress

    • Customizable endlessly (unlike genmodel).

    • Functions have a overridable behavior.

  • Other fields of interest: Validation, actions …​

  • Existing POC: EEF Group for Sirius.