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

Difference between revisions of "MDT/Papyrus/Juno Work Description"

< MDT‎ | Papyrus
(Current tasks)
(Current tasks)
Line 1: Line 1:
=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].
 
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 lifecycle==
+
=Profile Management and lifecycle=
  
This work is developed by [http://www-list.cea.fr CEA LIST] and sponsored by [http://www.ericsson.com Ericsson] in the context of the [http://wiki.eclipse.org/Polarsys]<br />
+
This work is developed by [http://www-list.cea.fr CEA LIST] and sponsored by [http://www.ericsson.com Ericsson] in the context of Plarsys [http://wiki.eclipse.org/Polarsys]<br />
 
Planed release date : 2012<br/>
 
Planed release date : 2012<br/>
  
===Modeling OCL constraints===
+
==Modeling OCL constraints==
 
Bugzilla : [https://bugs.eclipse.org/bugs/show_bug.cgi?id=370815 Bug 370815]
 
Bugzilla : [https://bugs.eclipse.org/bugs/show_bug.cgi?id=370815 Bug 370815]
  
Line 19: Line 17:
 
* If necessary, adapt the Papyrus validation framework
 
* If necessary, adapt the Papyrus validation framework
  
===Profile evolution===
+
==Profile evolution==
 
Bugzilla : [https://bugs.eclipse.org/bugs/show_bug.cgi?id=370816 Bug 370816]
 
Bugzilla : [https://bugs.eclipse.org/bugs/show_bug.cgi?id=370816 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.
 
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===
+
==Model/Profile packaging==
 
Bugzilla : [https://bugs.eclipse.org/bugs/show_bug.cgi?id=370817 Bug 370817]
 
Bugzilla : [https://bugs.eclipse.org/bugs/show_bug.cgi?id=370817 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.
 
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===
+
==Import by copy==
 
Bugzilla : [https://bugs.eclipse.org/bugs/show_bug.cgi?id=370818 Bug 370818]
 
Bugzilla : [https://bugs.eclipse.org/bugs/show_bug.cgi?id=370818 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.
 
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==
+
=Flexible Drag & Drop framework=
  
This work is developed by [http://www-list.cea.fr CEA LIST] and sponsored by [http://www.ericsson.com Ericsson] in the context of the [[ModelingPlatform | Modeling Platform Industrial Working Group]]<br />
+
This work is developed by [http://www-list.cea.fr CEA LIST] and sponsored by [http://www.ericsson.com Ericsson] in the context of Plarsys [http://wiki.eclipse.org/Polarsys]<br />
 
Planed release date : Unknown<br/>
 
Planed release date : Unknown<br/>
 
Bugzilla : [https://bugs.eclipse.org/bugs/show_bug.cgi?id=370819 Bug 370819]
 
Bugzilla : [https://bugs.eclipse.org/bugs/show_bug.cgi?id=370819 Bug 370819]
Line 53: Line 51:
 
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)
 
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==
+
=Themes and preferences=
  
This work is developed by [http://www-list.cea.fr CEA LIST] and sponsored by [http://www.ericsson.com Ericsson] in the context of the [[ModelingPlatform | Modeling Platform Industrial Working Group]]<br />
+
This work is developed by [http://www-list.cea.fr CEA LIST] and sponsored by [http://www.ericsson.com Ericsson] in the context of Plarsys [http://wiki.eclipse.org/Polarsys]<br />
 
Planed release date : Eclipse Juno (June 2012)<br/>
 
Planed release date : Eclipse Juno (June 2012)<br/>
 
Bugzilla : [https://bugs.eclipse.org/bugs/show_bug.cgi?id=370797 Bug 370797]
 
Bugzilla : [https://bugs.eclipse.org/bugs/show_bug.cgi?id=370797 Bug 370797]
  
===CSS Support===
+
==CSS Support==
  
 
Papyrus should provide a CSS Engine for its diagrams. The stylesheets should be defined at three levels:
 
Papyrus should provide a CSS Engine for its diagrams. The stylesheets should be defined at three levels:
Line 97: Line 95:
 
It should be possible to define local Style, CSS Classes and CSS ID on specific GMF Elements.
 
It should be possible to define local Style, CSS Classes and CSS ID on specific GMF Elements.
  
===Extended CSS Support===
+
==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...)
 
Papyrus should provide an Extended CSS Syntax, allowing the user to define its own CSS Selectors through custom queries (OCL, EMF Facet, Java...)
Line 110: Line 108:
 
</source>
 
</source>
  
===Editor & Preferences===
+
==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.
 
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==
+
=Documentation=
  
This work is developed by [http://www-list.cea.fr CEA LIST] and sponsored by [http://www.ericsson.com Ericsson] in the context of the [[ModelingPlatform | Modeling Platform Industrial Working Group]]<br />
+
This work is developed by [http://www-list.cea.fr CEA LIST] and sponsored by [http://www.ericsson.com Ericsson] in the context of Plarsys [http://wiki.eclipse.org/Polarsys]<br />
 
Planed release date : 2012<br/>
 
Planed release date : 2012<br/>
 
Bugzilla : [https://bugs.eclipse.org/bugs/show_bug.cgi?id=370820 Bug 370820]
 
Bugzilla : [https://bugs.eclipse.org/bugs/show_bug.cgi?id=370820 Bug 370820]

Revision as of 04:51, 16 March 2012

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 Plarsys [1]
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 Plarsys [2]
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 Plarsys [3]
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 Plarsys [4]
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