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.
Cédric
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)
Regards,
Camille
__________________________
Camille Letavernier
CEA LIST
Papyrus : http://www.eclipse.org/papyrus
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
