Community
Participate
Working Groups
Copy a package and then paste it in another package. Only model elements are copied, no diagram is copied.
The paste manager plugin, in charge of copy/paste function in Papyrus, do not know which technology exists for diagrams. It should depend neither from the table framework nor the GMF notation framework. Moreover, semantic elements do not really know that representations are linked to them. => Each technology implementation should define the way diagrams/tables are duplicated when linked model elements are copied and paste with model. This could be defined using advices from Element Edit Service.
fixed in r7394. Added two advices for tables and GMf diagrams to help copy diagrams and tables. Enhanced copy commands for editing domain should be used, or the one from GMF runtime. This fix should only work on 0.8.X series, this should be really improved on 0.9 and later versions.
I have found one remaining issue: We use Papyrus in a multi-project context (one modelset/editingdomain per project, with a shared clipboard to allow inter-project copy/paste). Intra-project copy/paste does work well now, including diagrams. But inter-project copy/paste does not (diagrams are not copied). Looking quickly at the code, it seems that copied diagrams are added in the same NotationResource as the original diagram, which is not always appropriate (see org.eclipse.papyrus.diagram.common.advice.GMFDiagramDuplicateEditHelperAdvice.DuplicateDiagramCommand.doExecuteWithResult()): -There could be multiple notation resources, even in a mono-project context, due to control mode. -The copied diagram may be associated to an element copied into a different project altogether. I think the right place to store the diagram would be in the NotationResource corresponding to the UmlResource of the corresponding copied element. What do you think?
Yes, the diagrams should be placed in the notation resource corresponding to the semantic resource where the copied element is added.
fixed in branch in r7418
Actually, it still does not *quite* work in a multi-project context, because the target resource for diagram or table is looked-up in the source editingdomain's resource set, not in the target's resource set. I have modified the two functions that deal with target resource computation: -org.eclipse.papyrus.diagram.common.advice.GMFDiagramDuplicateEditHelperAdvice.getNotationResourceForDiagram(EObject, TransactionalEditingDomain) -org.eclipse.papyrus.table.common.advice.TableDuplicateEditHelperAdvice.getNewResourceForTable(EObject, TransactionalEditingDomain) In both functions, I have replaced the line that reads: Resource resource = domain.getResourceSet().getResource(targetUri, true); ... by the following lines: // By default, simply put it in the same resource set as the semantic element. ResourceSet resourceSet = containerResource.getResourceSet(); if (resourceSet == null) resourceSet = domain.getResourceSet(); // ALG: Is this case actually possible? If not, we could simply remove the domain parameter. Resource resource = resourceSet.getResource(notationURI, true); With those two changes, the right resource set is used. I cannot easily provide a patch, as I am not working on the head of branch, but it should be trivial to integrate.
"Patch" applied in r7423 Thanks!
fixes were not backport to 0.9.X => bug is reopened
Some bugs are still present. See the list of dependent tasks
Does not work anymore in 0.10.M7 (current build)
backported on trunk r11251
table duplication backported in trunk 0.10.X in r11393
