Community
Participate
Working Groups
This may be a regression of Bug ID 314566 or another manifestation of 468282? Create two models ModelA and ModelB in the same Papyrus project which also contains ProfileX with one stereotype <<ClassX>> extending Class. Assign ProfileX to the RootElement in both models. Create an element ModelA::ClassA and apply stereotype <<ClassX>>. In the ModelA Model Explorer, right-click ClassA and select Copy. Change to ModelB, select RootElement, then right-click and select Paste. Note in the Properties/Profile view that ModelB::ClassA no longer has a <<ClassX>> applied stereotype. The stereotype can be manually re-applied. (I'm migrating large RSA models with multiple custom profiles using the RSA Import plugin. Many of the stereotypes have tagged values. After I copy a 'ClassA' in this way and lose the stereotype, I can re-apply the <<ClassX>> stereotype in 'ModelB' and the tag values are still there, so this may be an easy fix. Contact me if you need a sample project that reproduces. It takes about 4 minutes to create this case from instructions above. The manual workaround is OK for small models, but not for models with thousands of elements.)
Are you opening the two models ModelA and ModelB in different editors or in the same editor? It should at least work as you expect in the same editor: open ModelA from the Project Explorer, then in the context menu on ModelA in the Model Explorer view use the "Import Package" action to load ModelB. Making the copying of applied stereotypes work between editors is quite a different proposition to the implementation within the one editor.
"Create two models ModelA and ModelB in the same Papyrus project which also contains ProfileX with one stereotype <<ClassX>> extending Class." The two models, ModelA and ModelB and the profile ProfileX are all in the same Papyrus Project and open in the same instance of Eclipse.
I wonder if this is one of those aspects that user's coming from RSA will find very confusing. Knowing from my own experience making the transition from RSA to Papyrus, and the fundamental difference between RSA vs. Papyrus in how models are loaded into memory and how the model editor/model explorer view works compared to how the diagram editors works in RSA. In RSA all models (.emx-files) in the workspace, disregarding if they happen to be located in the same project or in different projects, gets loaded into one huge resource set. The huge difference in Papyrus is that each model (.di/.uml/.notation) opens up in its own model editor and thus its own resource set. Two different model editors gets loaded into two separate resource sets. The model explorer view shows the contents of the current active model editor (and its resource set). Switching between two different model editors will also update the model explorer view. For users coming from RSA (which includes myself) this can be quite confusing, since you are used to having the information of the model explorer view directly shown in the project explorer view. Which makes sense since you have only one huge resource set for the complete workspace into which everything gets loaded. So, as Christian tried to explain in Comment 1, if ModelA and ModelB is opened in two different model editors is quite different compared to opening ModelA and ModelB in the same model editor, e.g. by ensuring that ModelA have a package import of ModelB. It really does not matter at all if ModelA and ModelB are located in the same project or not, it is about how they are opened in the same or different model editors. I myself was extremely confused by this myself from the beginning.Keep in mind that in RSA you have one diagram editor per diagram (the tabs at the top). In Papyrus you have one model editor per model (the tabs at the top) and the individual diagrams opened for that model have its tabs at the bottom (within that model editor). Not sure if this explains, or clarifies, anything regarding this or if it just causes further confusion.
Thank you, Christian and Peter, for the thoughtful comments. I'll try importing ModelA into ModelB with a package import, then confirm that a copy / paste from ModelA to ModelB within the same model editor (Model Explorer) preserves the stereotype. That would be an acceptable workaround. What led me to think there was a bug here was that *some* of the profile information from the ModelA element showed up in the ModelB copy of that element, that is, the tagged values. Those tagged values reappeared after then stereotype was reapplied to the ModelB copy. Should I close this as: 'acceptable workaround'? Should there be an issue created against the documentation to add a brief section on 'copying model elements between models'? If copy/paste between model editors does not work as expected, should that feature be disabled? I understand that it would take some work to make sure profile information copied correctly. If the profile versions / ids didn't match there would need to be a warning, and/or an opportunity to migrate the element to a profile currently applied to the target package of the copy.
(In reply to Jim Albers from comment #4) > Should I close this as: 'acceptable workaround'? Should there be an issue > created against the documentation to add a brief section on 'copying model > elements between models'? No, I don't think that this bug shall be closed. I would claim that users should not really have to care whether they copy-paste within the same model editor, or if the copy-paste between different model editors. > > If copy/paste between model editors does not work as expected, should that > feature be disabled? No, I would say that this bug eventually needs to be fixed. Sure, a "fix" could be at least present a dialog for any corner cases, like when the target model does not have the same profile already applied. Such corner cases of course already exist for the case when copy-paste within the same model editor and even within the same model, e.g. in cases where a profile is not applied on the root package, but only one of its sub-packages. > > I understand that it would take some work to make sure profile information > copied correctly. If the profile versions / ids didn't match there would > need to be a warning, and/or an opportunity to migrate the element to a > profile currently applied to the target package of the copy. Yes, for any such corner cases where any automatic application of the same profile, or if another version of the same profile already is applied on the target model, and other such "mismatches" of the applied profile of course needs to be handled in some way to make it clear to the user what the consequence are of the paste action (including the case if the paste for some reason is not possible to perform).
Thank you, Peter. As I help customers migrate from EA and RSA, the treatment of profiles will continue to be important. Robust copy/paste will help. This bug addresses the initial case: where applied profiles on the source and destination models are the same with respect to the set of copy/pasted elements. It makes sense for inter-model copy/paste that we expect the modelers to take care of profile application consistency/migration on the source and destination models before they start copy/paste operations. So, this bug can close when copy/paste between models with consistent profiles works correctly and there is a warning provided to the user when the source and destination models have inconsistent profile applications, insofar as the set of copy/pasted elements are concerned.
