2016-11-15 Architecture Committee Minutes

Attendees

• Per (Saab)
• Reibert (Ericsson)
• Philip (EclipseSource)
• Florian (CEA)
• Simon (Zeligsoft)
• Rémi (CEA/chair)

Topics

Task Forces

Florian: Product line support/ splitting of the repos

Goal: prepare for sub-projects with the TLP

Initial work from CEA: scenario for the extra plugins, to be published very soon

5 migrations options:

• (default) Remove things pointless on Papyrus core and get rid of it
• Move the extra plugin as a new sub-project of Papyrus umbrella project. Trying to define new criterias to identify such projects
• Papyrus repo dedicated to incubation, fitting in Papyrus core
• Move as github project (publicly available but not part of Eclipse project)
• Core tool project for release engineering commons

Now having a map of existing projects / extras. Ongoing work, to be approved by Papyrus committers, will then be published by the PL: What about the builds? Papyrus team will help to setup Hudson jobs / configurations. PL proposed help for collaborative modeling.

Philip: DSML task force

Goal: based on the information modeling support, start guidelines about customization the product

Current: Documentation on information modeling exiting. Demo with a profile would be part of the presentation, to complete the information modeling stuff (no profile yet).

Juergen Dingle, Ernesto Posse & JM Bruel discussions: master thesis topic to look at IM modeling, profile, papyrus-rt, etc. and do something equivalent to maven archetypes. Perhaps a xtext file + maven build to have everything to start from scratch.

Discussions on Papyrus SDK on Papyrus mailing list (link here): tooling to create Papyrus based products/

Simon: Textual / graphical modeling

Goal: provide hybrid approach for modeling, based on different representations.

Update: research project approved and label. 24 months

Additional participants? Saab?

Investigation on using UML2 metamodel rather than intermediate model

Per: Dependency management, dependencies from Papyrus

Goal: remove the UI dependencies in the core plugins, reduce dependencies

Results: initial findings, but how to communicate? Papyrus Facet may drag a lot of dependencies.

Proposal: to write on papyrus dev, and giving some introduction there.

Additional topics

Automatic layout

Historically: need for automatic layout for products based on Papyrus (Papyrus-RT for example) Sequence diagram were one of the key subject. New ELK project (ex-Kieler) is dedicated to automatic layout. Papyrus provided some integration as experimentation. No particular strategy for sequence diagram in ELK, but prototype existing on KIELER integration. ELK status: incubation (only extra plugin until it is out and stable), with APIs moving. Sequence diagram layout algorithm is only a prototype Also ELK is dedicated to the whole diagram, not local layouting. User should not perform any manual editing of the Papyrus-RT: on short term, should not rely on Papyrus-RT. “Smart layout improvement”, not relying on ELK, improving UX. For Hybrid approach, maybe ELK could be a solution. Canonical diagram creation: only GMF layout algorithm based, not ELK one.