Papyrus/Oxygen Work Description/NewFeature/Papyrus4Toolsmiths

3 major layers for One Papyrus

Papyrus is a modeling environment, standards based, with specific Domain specific extension with many enablers [1].

Papyrus could be split into 3 major layers:

• Papyrus is composed upon Eclipse with several features embedded plugins, i.e. Papyrus-CORE
• In order to develop Papyrus-CORE, a set of plugins have been created to assist Papyrus developers. These plugins will be grouped and released as Papyrus-DEV.
• Finally in order to allow Domain specific extension, a set of plugins have been specificly developed to speed-up Papyrus customization. These plugins belong to the Papyrus-TOOLSMITHS

In parralle of these 3 layers [Papyrus-CORE, Papyrus-DEV, Papyrus-TOOLSMITHS), Papyrus have several extensions. We introduce here the "Component" concept (Component word will be changed). In this category we have for instance SysML, Marte, Designer, RobotML, Moka. All components shared a common infrastruture for release engineering. Those elements are gather inside the Papyrus-Components plugins. These plugins are managed inside the papyrus-tools repository [3].

[1]: https://www.eclipse.org/papyrus/ [2]: https://git.eclipse.org/c/papyrus/org.eclipse.papyrus.tools.git/tree/components

Problematic

Badly, these different plugins belonging the Papyrus-TOOLSMITH are scattered across the whole Papyrus repository. Even if identified, a short analysis shows also they do not have exactly the same Technology Readiness Level, analysis based on their code quality, documentation (uptodate or abscence), included (or not) tests, specific editors not only based on String, extension point provided.

To produce a useful Papyrus-TOOLSMITHS, work will be splited into 3 phases ( with a military metaphor):

• Phase 1: Identify the Soldier
  • list the plugins that could belong to the Papyrus-TOOLSMITHS
  • create a set of HIPP jobs to manage the TOOLSMITH continuous integration
  • create an initial product that integrate some of them
• Phase 2: From individual soldiers to an army
  • merge, enhance the documentation with a specific focus on how to define the minimal level of documentation, test a plugin should have to integrate the Papyrus-ToolSmiths
  • create a specific menu to gather the different tools
  • enhance the plugins with specific editors
  • homogenize the way editors are working (usage of direct object in properties and not string reference for instance)
• Phase 3: Develop a strategy for our army
  • Goal will to be able to propose specific methodology on top of those plugins, ensuring fast development of DSL products.
  • Full industrialization of the DSL and DSML application creation process

The TOOLSMITH project will require a good feedback from the developers of actual DSL,DSML like SysML...

Proposed Identification Methodology

Properties to be introspected

• identify plugin with the help of papyrus experts such as Patrick, Florian
• check if the plugin has documentation (plugin.properties, wiki, embedded)
• check if the plugin is integrated in the continuous integration
• check if the documentation is up-todate with the plugin: i am able to remark the doc/tutorial
• check if the plugin provides an extension-point
• check if the plugin is model based
• check if the model proposed a menu

Check list

• Description: X
• Doc: YES/NO/Localisation/MDE
• Extension-point: YES/NO
• POM: YES/NO
• CI: YES/NO
• Model-based: YES/NO
• Menu contribution: YES/NO

Team

• Francois Le Fevre
• Florian Noyrit
• Patrick Tessier