Hello,
Papyrus can theoretically handle the models. However, some tools (Not sure which ones, though) make a few assumptions:
-
Uml, notation and di files are always here (No more, no less)
-
They all have the same name (Except for the extension)
These assumptions are probably too optimistic, but this is the case in 99.9% of our models…
The load/save should be fine, as we’re (supposedly) saving the ModelSet’s content, not the 3 files (I.e. we’re also saving imported models when they’re not in read-only mode). However, I suppose
the oneFile feature relies on the file’s names, as well as some tools which need to retrieve the di file from a UML file (Not sure whether UML Compare is in this category or not).
Generally, when you have an access to the *.di file, everything should be fine, as it contains all the information needed to retrieve the notation and uml files (Whatever their name is).
It seems that modifying the notation doesn’t have any negative impact for GMF. This is an EMF Resource, which is GMF-independent. It may contain objects from heterogeneous Metamodels.
The notation model is not a GMF EObject containing other EObjects ; it’s an EMF Resource containing EObjects (Including GMF ones). So, it is not a problem to add table-models inside this file (There
is one root per Diagram, not a single GMF root containing everything else).
Regards,
__________________________
Camille Letavernier
+33 (0)1 69 08 00 59 -
camille.letavernier@xxxxxx
CEA LIST - Laboratoire d'Ingénierie dirigée par les modèles pour les Systèmes Embarqués (LISE)
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de SCHNEKENBURGER Remi 211865
Envoyé : mercredi 15 février 2012 14:38
À : Papyrus Project list
Objet : Re: [mdt-papyrus.dev] EMF-Facet refactoring and Papyrus Table
Hi,
The problem I see with the notation file is that this file is provided by the {oe}.gmf.notation project. Personally, I would not add non-UML2 information in a .uml file. This would be the same for
the notation file, which corresponds to GMF diagrams.
Unless there is a specific element in GMF notation to handle/contain elements which are not GMF element, I do not see how/why we should have table information in this kind of file. Unfortunately,
I do not know if GMF notation is designed to handle this kind of information.
What are the impacts on adding one file to the set of files? Load/save, delete/create/rename? What else ? Is Papyrus not designed to accept files coming from different kind of editors?
Best regards,
Rémi
------------------------------------------------------------------------------------------------------------------------------------------------
Rémi SCHNEKENBURGER
+33 (0)1 69 08 48 48
CEA Saclay Nano-INNOV
Institut CARNOT CEA LIST
Point Courrier n°174
91 191 Gif sur Yvette CEDEX
www.eclipse.org/papyrus
Hi,
I agree with Camille, no new file please J.
I also think that it should be in the notation and not the di: perhaps notation is not a good extension name because it references the gmf notation
model but we can agree that the notation file contains all the graphical descriptions (tables + diagrams), and di is used for the window description and perhaps some other transversal information.
It seems to be the more logical for me.
Regards,
Mathieu
Hello,
I’m not favorable to a new file, as most Papyrus tools expect exactly three files (x.di, x.notation and x.uml). This would involve a lot of maintenance on these tools to take a new (and probably
optional) kind of file. The notation would probably become optional as well, as we could have a model with only tables. It seems really too complicated, and the added value is not obvious.
The notation file is probably the best place for storing the table models.
Regards,
__________________________
Camille Letavernier
+33 (0)1 69 08 00 59 -
camille.letavernier@xxxxxx
CEA LIST - Laboratoire d'Ingénierie dirigée par les modèles pour les Systèmes Embarqués (LISE)
Hi all,
As you know, EMF-Facet is finishing its refactoring. They provide new metamodels for Facet, Queries, Table, Customization, …
Of course, these API are always available in Juno, but they are deprecated. Concerning the Papyrus Table, I should create a new papyrus table metamodel to use the new EMF-Facet metamodels. I should create new table editors too to use this
new table model.
My question is the following :
In which file should we store the table ? Currently it is done in the .di, but it seems me that it would be better in the .notation or in a new file.
Best regards,
--
Vincent Lorenzo
01-69-08-17-24
CEA Saclay Nano-INNOV
Institut CARNOT CEA LIST
DILS/LISE
Point Courrier n° 174
91 191 Gif sur Yvette CEDEX
Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel.
Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos ne pourra être engagée quant au contenu de ce message. Bien
que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être engagée pour tout dommage résultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet,
the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting
from any virus transmitted.