Eclipse Community Forums: Papyrus » How to copy UML Objects keeping stereotypes

Home » Modeling » Papyrus » How to copy UML Objects keeping stereotypes(issue in keeping stereotypes when copying UML Elements)

Show: Today's Messages :: Show Polls :: Message Navigator

How to copy UML Objects keeping stereotypes [message #1832876]

Mon, 28 September 2020 12:57

Dylan Trenti

Messages: 7
Registered: March 2019

Junior Member

Hi everyone,

I'm trying to copy an UML Object (Class o Package) by keeping the stereotyes.
The first thing I tried was to copy the element by using the EcoreUtil.copy and I managed to copy classes or Packages but they where not keeping the stereotypes.
Then I tried something like this:

for (Stereotype s : classToCopy.getAppliedStereotypes()) {
newClass.applyStereotype(s);
}

by doing this way I managed to copy the class and apply all the stereotypes but there is still a problem, the informations about the values of their fields are gone.

For last I noticed that by copy-pasting an element form the UI everything was copied correctly so Taking a look into Papyrus source code I found the commands used to copy and paste elements,

org.eclipse.papyrus.views.modelexplorer.handler.CopyHandler;
org.eclipse.papyrus.views.modelexplorer.handler.PasteHandler;

but this isn't what I'm actually looking for since the copy/paste is done by using commands.

So here is my question:
Is there a way to Copy an UML element (Specifically Classes, Packages or Properties) keeping the stereotyes an the values associated to their fields??

thanks

Dylan

Report message to a moderator

Re: How to copy UML Objects keeping stereotypes [message #1832877 is a reply to message #1832876]

Mon, 28 September 2020 13:56

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi

Yes, but only by manually repairing the EcoreUtil 'oversights'.

NB. It not an EcoreUtil bug. It stems from an incompetent XMI design by OMG whereby stereotype applications are magic irregular inadequately modeled root objects unrelated to other model elements. Eclipse UML2 sadly followed the OMG stupidity all too faithfully with the result that many regular EMF-based modeling activities fail for Eclipse UML2. Many of thse deficiencies explain why an Eclipse UML2 project is needed. One might have hoped that a project whose aspiration was to just implement a model would find that EMF got it all right out of the box. Sadly not. Fixing OCL-based validation of these irregular objects is a comparatively recent innovation that has a nasty tendency to break when Papyrus evolves.

You can perhaps contribute to a UMLUtil.copier or maybe even find one in Papyrus ...

Regards

Ed Willink

Report message to a moderator