Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
2016-11-15 Architecture Committee Minutes
Contents
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.