| Re: [mdt-papyrus.dev] EMF-Facet refactoring and Papyrus Table |
|
I agree. At worst we can force the resource set to use a more standardized resource loader: currently the notation file is loaded with
GMFResource which as some custom code. This code is independent from gmf but it changes some behaviors regarding resource notifier and UnresolvedReferenceException
not being throwed anymore. It looks ok to me, but if someone else can check. Mathieu De : mdt-papyrus.dev-bounces@xxxxxxxxxxx
[mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de LETAVERNIER Camille 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 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
------------------------------------------------------------------------------------------------------------------------------------------------
De :
mdt-papyrus.dev-bounces@xxxxxxxxxxx
[mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de VELTEN Mathieu 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 De :
mdt-papyrus.dev-bounces@xxxxxxxxxxx
[mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de LETAVERNIER Camille 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) De :
mdt-papyrus.dev-bounces@xxxxxxxxxxx
[mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de LORENZO Vincent 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. |
