Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Papyrus: CSS Support for GMF

Hi and thanks for the heads-up.

You're right this would impact every GMF modeler out there (EcoreTools being one of them) and lead to issues quite difficult to identify and fix.
Which lead me to this question : why don't you, in the papyrus code, directly refers to the Factory you want to use (here the one having the CSS support) - or even define your own extension point to retrieve the right one in the context of papyrus ? What is the rationale to override the GMF one for all the Eclipse Installation ?

Even if this does not introduce any specific bug or issue, just that fact that it might lookup the ResourceSet for the CSS support could lead to performance penalty for all the modelers - not something we could afford for no gain on the other hand. Furthermore your code might assume things which are just not true for other modelers, like the fact that the model is in a ResourceSet or even in a Resource.


Le 17/12/2013 18:13, LETAVERNIER Camille a écrit :

Hi all,



In Papyrus, we’ve implemented a component to support CSS Stylesheets for GMF-based diagrams. This component has been introduced in Papyrus/Juno, and we now consider it stable.


It has never been included in the Simultaneous Release because of one specific issue: this component overrides the GMF Notation metamodel implementation (Though the org.eclipse.emf.ecore.factory_override extension point). Because the EMF Factory is a singleton, there is a risk of introducing conflicts, if more than one component uses this extension point for the same metamodel. The CSSNotation elements have been designed to delegate to the standard Notation implementation when the CSS support is not installed on the resource set, which means that this component, in theory, doesn’t introduce any change in the behavior of non-Papyrus diagrams.


Now, we’d like to distribute this component as part of the Papyrus project for Luna, directly in the Release Train, whereas it was only proposed as an optional, extra component in Juno and Kepler. My idea is that we might introduce this feature in M4, and remove it before M6 if major issues (incompatibilities) are introduced.


Is there any objection, or suggestion? (Especially for GMF-based projects)





Camille Letavernier


Papyrus :


cross-project-issues-dev mailing list

Back to the top