Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

MDT/Papyrus/Juno Work Description

< MDT‎ | Papyrus
Revision as of 11:08, 7 February 2012 by Cletavernier.eclipsesource.com (Talk | contribs) (New page: =Current tasks= This page lists the main current tasks in the Papyrus development, with links to the associated [http://bugs.eclipse.org/bugs Bugzilla tasks]. ==Profile Management and li...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Current tasks

This page lists the main current tasks in the Papyrus development, with links to the associated Bugzilla tasks.

Profile Management and lifecycle

This work is developed by CEA LIST and sponsored by Ericsson in the context of the Modeling Platform Industrial Working Group
Planed release date : 2012

Modeling OCL constraints

Bugzilla : Bug 370815

It should be possible to model OCL constraints for a profile, with a specific OCL editor. It should be possible to generate an EMF Validation plug-in from these constraints. The constraints should be validated either in real-time or in batch-mode, according to a user preference. It should be possible to define this preference either globally or constraint by constraint.

Concretely, this will be realized in three steps:

  • Embedding the OCL X-Text editor in the property view, and associating it to UML Opaque expressions using the OCL language
  • Creating a generator, which inputs a Profile and outputs an EMF Validation plug-in
  • If necessary, adapt the Papyrus validation framework

Profile evolution

Bugzilla : Bug 370816

Profiles defined in the workspace typically evolve quickly. They should be automatically re-applied when the users open a diagram for the first time after the profile has evolved. The user should be asked whether the modification is ok or not.

Model/Profile packaging

Bugzilla : Bug 370817

When packaging a Model on which a local profile is applied, the Profile should also be packaged, either in the same plug-in or in another plug-in.

Import by copy

Bugzilla : Bug 370818

Currently, the only import option available in Papyrus is an external reference to another model. It should also possible to import an external model (Or subset of a model) by copying it.

Flexible Drag & Drop framework

This work is developed by CEA LIST and sponsored by Ericsson in the context of the Modeling Platform Industrial Working Group
Planed release date : Unknown
Bugzilla : Bug 370819

Papyrus should provide a customizable Drag & Drop (D&D) framework, unifying the different kinds of D&D:

  • Drag & Drop between views
  • Drag & Drop between a view and a Diagram
  • Drag & Drop between a Diagram and a View
  • Drag & Drop inside a Diagram

This will require a global reflection on the different mechanisms involved, especially for the Diagram to Diagram D&D, which are currently handled by GMF generated code.

Basically, the tool should propose a few D&D policies, and the user or tool provider should be able to choose one.

Like other Papyrus customization tools, it should be possible to customize the D&D locally, in the workspace (user customization), or to deploy the customization in a plug-in (Tool provider)

Themes and preferences

This work is developed by CEA LIST and sponsored by Ericsson in the context of the Modeling Platform Industrial Working Group
Planed release date : Eclipse Juno (June 2012)
Bugzilla : Bug 370797

CSS Support

Papyrus should provide a CSS Engine for its diagrams. The stylesheets should be defined at three levels:

  • Workspace stylesheets: Applied on every elements
  • Model stylesheets: Applied on each element of the Model
  • Diagram Stylesheets: Applied on each element of the Diagram

The CSS Engine should handle three kinds of properties:

  • GMF "Style" properties
  • Papyrus style properties (From Annotated Notation model)
  • User defined properties

Regarding the CSS Selectors, they should be based on the Semantic model, plus the diagram type, i.e. :

Class { /* All GMF views representing a Class */
   bold:true; /* This is a GMF property */
}
 
ClassDiagram Class { /* All classes in a ClassDiagram */
   bold:false;
}

The selectors should also be able to test semantic properties:

Class[isAbstract=true] {
   italic:true;
}

The CSS Engine should be generic enough to handle any kind of Semantic Model (i.e. it should not depend on UML).

It should be possible to define local Style, CSS Classes and CSS ID on specific GMF Elements.

Extended CSS Support

Papyrus should provide an Extended CSS Syntax, allowing the user to define its own CSS Selectors through custom queries (OCL, EMF Facet, Java...)

This extended CSS syntax is not compatible with the standard CSS parsers. Thus, we will need to define a custom parser for CSSX files. The CSSX parser should be able to handle standard CSS files, as well as custom queries.

Class[hasStereotype("SysML::Blocks::Block")] {
   fillColor:#C3D1D5;
   gradient:white vertical;
}

Editor & Preferences

The user should be able to edit the CSS/CSSX files either textually or graphically. The graphical editor should look like the current Papyrus preferences page, which it will replace.

Documentation

This work is developed by CEA LIST and sponsored by Ericsson in the context of the Modeling Platform Industrial Working Group
Planed release date : 2012
Bugzilla : Bug 370820

The documentation for the end-user should be improved and updated. The following points will be improved in priority:

  • How to create a Model and edit Model properties
  • Model management (Model split using fragments, profile application lifecycle)
  • Model validation
  • Profile definition

Back to the top