Bug 494407 - [Tooling] Copy-paste of port in structure diagram does not work and throws an exception
Summary: [Tooling] Copy-paste of port in structure diagram does not work and throws an...
Status: CLOSED FIXED
Alias: None
Product: Papyrus-rt
Classification: Modeling
Component: tool (show other bugs)
Version: 0.7.2   Edit
Hardware: PC Windows 7
: P3 normal
Target Milestone: 0.9.0   Edit
Assignee: smaoui asma CLA
QA Contact:
URL:
Whiteboard:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2016-05-24 08:46 EDT by Peter Cigehn CLA
Modified: 2017-03-02 08:14 EST (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Cigehn CLA 2016-05-24 08:46:01 EDT
Compared to the copy-paste of a capsule part, see Bug 494401 and Bug 489621, the copy-paste of a port in capsule structure diagram does not work, nothing happens, and an exception is thrown.

Steps to reproduce:

1) Create a UML-RT model
2) Create a capsule
3) Create a protocol
4) Drag-and-drop the protocol onto the structure diagram of the capsule to create a port typed by that protocol
5) Now select the port and copy it (using Ctrl-C)
6) Select the capsule itself and paste to create a second port typed by the same protocol (using Ctrl-V).
7) Nothing happens and an exception it thrown.

Based on the experience from Bug 494401, I tried to select differently prior to pasting, but it does not matter what is selected prior to pasting. The same exception seem to occur and nothing happens.

The exception in the error log:

eclipse.buildId=4.6.0.I20160512-1000
java.version=1.8.0_66
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US
Framework arguments:  -pluginCustomization C:\Users\cigehpet\eclipse\papyrusrt-nightly\eclipse\plugin_customization.ini -pluginCustomization C:\Users\cigehpet\eclipse\papyrusrt-nightly\eclipse\plugin_customization.ini -pluginCustomization C:\Users\cigehpet\eclipse\papyrusrt-nightly\eclipse\plugin_customization.ini
Command-line arguments:  -os win32 -ws win32 -arch x86_64 -pluginCustomization C:\Users\cigehpet\eclipse\papyrusrt-nightly\eclipse\plugin_customization.ini -pluginCustomization C:\Users\cigehpet\eclipse\papyrusrt-nightly\eclipse\plugin_customization.ini -data file:/C:/Users/cigehpet/eclipse/papyrusrt-nightly/workspaces/ws27/ -pluginCustomization C:\Users\cigehpet\eclipse\papyrusrt-nightly\eclipse\plugin_customization.ini

org.eclipse.ui
Error
Tue May 24 13:57:05 CEST 2016
Unhandled event loop exception

org.eclipse.e4.core.di.InjectionException: java.lang.NullPointerException
	at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:64)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:282)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:264)
	at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:132)
	at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.execute(HandlerServiceHandler.java:152)
	at org.eclipse.core.commands.Command.executeWithChecks(Command.java:494)
	at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:488)
	at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:210)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.executeCommand(KeyBindingDispatcher.java:286)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.press(KeyBindingDispatcher.java:507)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.processKeyEvent(KeyBindingDispatcher.java:558)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.filterKeySequenceBindings(KeyBindingDispatcher.java:378)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.access$0(KeyBindingDispatcher.java:324)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher$KeyDownFilter.handleEvent(KeyBindingDispatcher.java:86)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1270)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1078)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1103)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1088)
	at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1130)
	at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1126)
	at org.eclipse.swt.widgets.Widget.wmChar(Widget.java:1547)
	at org.eclipse.swt.widgets.Control.WM_CHAR(Control.java:4890)
	at org.eclipse.swt.widgets.Canvas.WM_CHAR(Canvas.java:364)
	at org.eclipse.swt.widgets.Control.windowProc(Control.java:4771)
	at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:359)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:5107)
	at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
	at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2552)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3819)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1119)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1020)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:150)
	at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:687)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:604)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:138)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:673)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:610)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1519)
Caused by: java.lang.NullPointerException
	at org.eclipse.papyrus.infra.gmfdiag.common.commands.DefaultDiagramPasteCommand.doExecuteWithResult(DefaultDiagramPasteCommand.java:128)
	at org.eclipse.gmf.runtime.emf.commands.core.command.AbstractTransactionalCommand.doExecute(AbstractTransactionalCommand.java:247)
	at org.eclipse.emf.workspace.AbstractEMFOperation.execute(AbstractEMFOperation.java:150)
	at org.eclipse.papyrus.commands.wrappers.GMFtoGEFCommandWrapper.execute(GMFtoGEFCommandWrapper.java:124)
	at org.eclipse.gef.commands.CompoundCommand.execute(CompoundCommand.java:129)
	at org.eclipse.gef.commands.CompoundCommand.execute(CompoundCommand.java:129)
	at org.eclipse.papyrus.commands.wrappers.GEFtoEMFCommandWrapper.execute(GEFtoEMFCommandWrapper.java:95)
	at org.eclipse.emf.workspace.EMFCommandOperation.doExecute(EMFCommandOperation.java:119)
	at org.eclipse.emf.workspace.AbstractEMFOperation.execute(AbstractEMFOperation.java:150)
	at org.eclipse.core.commands.operations.DefaultOperationHistory.execute(DefaultOperationHistory.java:488)
	at org.eclipse.papyrus.infra.emf.gmf.command.CheckedOperationHistory.doExecute(CheckedOperationHistory.java:206)
	at org.eclipse.papyrus.infra.emf.gmf.command.CheckedOperationHistory.execute(CheckedOperationHistory.java:195)
	at org.eclipse.papyrus.infra.emf.gmf.command.NotifyingWorkspaceCommandStack.doExecute(NotifyingWorkspaceCommandStack.java:264)
	at org.eclipse.emf.transaction.impl.AbstractTransactionalCommandStack.execute(AbstractTransactionalCommandStack.java:165)
	at org.eclipse.emf.transaction.impl.AbstractTransactionalCommandStack.execute(AbstractTransactionalCommandStack.java:219)
	at org.eclipse.papyrus.infra.emf.gmf.command.NestingNotifyingWorkspaceCommandStack.execute(NestingNotifyingWorkspaceCommandStack.java:130)
	at org.eclipse.papyrus.infra.gmfdiag.menu.handlers.AbstractGraphicalCommandHandler.execute(AbstractGraphicalCommandHandler.java:85)
	at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:295)
	at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:90)
	at sun.reflect.GeneratedMethodAccessor62.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:54)
	... 50 more
Comment 1 Charles Rivet CLA 2016-10-31 14:21:51 EDT
First we need to understand the importance of the copy/paste operation in day-to-day activities.


We need to have an investigation on the cause - assigning to 0.9
Comment 2 Peter Cigehn CLA 2016-11-11 07:16:09 EST
(In reply to Charles Rivet from comment #1)
> First we need to understand the importance of the copy/paste operation in
> day-to-day activities.
> 
> 
> We need to have an investigation on the cause - assigning to 0.9

I am not fully sure why I was assigned this Bugzilla. 

When it comes to understanding the importance of copy/paste, my own experience is that modelers do copy/paste of all kinds of model elements to reduce the time it takes to build up models. I have been surprised so many times learning what kinds of copy/paste operations are performed. Based on this experience, I would expect some users to perform copy/paste on lots of things, including copy/paste between different capsules. 

The steps to reproduce use the example of pasting in the same capsule as the copy was made from, but a more expected scenario is probably that the user makes a copy from one capsule and then paste it into another capsule (possibly simply switching conjugation).

So I would say in general that copy/paste is used by some users to speed up the construction of models, and thus copy/paste operations needs to work consistently to avoid the confusion when a few copy/paste operations does not work (as this is one example of).

I will unassign this from myself, since I am not sure what more I can with this Bugzilla.
Comment 3 Charles Rivet CLA 2016-11-11 08:05:21 EST
(In reply to Peter Cigehn from comment #2)
> (In reply to Charles Rivet from comment #1)
> > First we need to understand the importance of the copy/paste operation in
> > day-to-day activities.
> > 
> > 
> > We need to have an investigation on the cause - assigning to 0.9
> 
> I am not fully sure why I was assigned this Bugzilla. 
> 
> When it comes to understanding the importance of copy/paste, my own
> experience is that modelers do copy/paste of all kinds of model elements to
> reduce the time it takes to build up models. I have been surprised so many
> times learning what kinds of copy/paste operations are performed. Based on
> this experience, I would expect some users to perform copy/paste on lots of
> things, including copy/paste between different capsules. 
> 
> The steps to reproduce use the example of pasting in the same capsule as the
> copy was made from, but a more expected scenario is probably that the user
> makes a copy from one capsule and then paste it into another capsule
> (possibly simply switching conjugation).
> 
> So I would say in general that copy/paste is used by some users to speed up
> the construction of models, and thus copy/paste operations needs to work
> consistently to avoid the confusion when a few copy/paste operations does
> not work (as this is one example of).
> 
> I will unassign this from myself, since I am not sure what more I can with
> this Bugzilla.

You were assigned to provide the perspective expressed in your comment. Thank you for putting it back in the pool so we can properly address it.
Comment 4 Charles Rivet CLA 2016-11-16 14:04:34 EST
Assigned to Rémi for re-assignment.
Comment 5 Remi Schnekenburger CLA 2016-11-17 03:08:33 EST
Assigning to Asma for evaluation
Comment 6 Eclipse Genie CLA 2017-02-02 05:54:34 EST
New Gerrit change created: https://git.eclipse.org/r/90169
Comment 8 Eclipse Genie CLA 2017-02-10 06:48:46 EST
New Gerrit change created: https://git.eclipse.org/r/90821
Comment 10 Peter Cigehn CLA 2017-02-14 09:22:48 EST
I tested this a bit and the exact steps to reproduce now works, i.e. if I select the capsule frame prior to pasting it now works without exceptions.

But if I now don't select anything prior to pasting, then lots of exceptions happens. This feels like the same as Bug 494401 where the behavior differs depending on what is selected prior to pasting. In general I would like to see a behavior for capsule structure diagrams, that selecting the capsule frame, or not selecting anything, i.e. the diagram in itself is selected, should have the same semantic. One should really see the capsule frame as the same as the diagram (the capsule frame could be seen just as a diagram border). You never ever have multiple capsules as the root of a capsule structure diagram, so pasting directly into the diagram should have the same behavior as selecting the capsule frame and pasting.

Testing a bit more (based on the experience from Bug 494401), and selecting the structure compartment of the capsule, then the paste produces yet another exception.

This feels like a general problem with Papyrus, where the paste behavior is so different and produces so different exceptions depending on what you have selected prior to pasting. In this specific case, I would say that all the three cases, 1) selecting nothing, i.e. the diagram is implicitly selected, 2) the capsule frame, 3) the structure compartment of the capsule, should all behave exactly the same and produce the same result.

I guess we should focus on not producing exception, but in the long term the consistency should be looked into, as tracked by Bug 494401.
Comment 11 smaoui asma CLA 2017-02-15 05:29:58 EST
I agree with you Peter, I can propose another fix to avoid exceptions, but since Bug 494401 is scheduled for future and it depends on Bug 490804 (a Papyrus bug aslo scheduled for future), I propose to close this bug and raise an other bug to track the issue of having the same behavior while pasting independently from the element selected before the paste (just like you have done with capsule part)

In fact, I think that the global fix should be in Papyrus for Bug 490804 for both cases: capsule part and ports.
Comment 12 smaoui asma CLA 2017-03-01 11:41:52 EST
Bug 512895 tracks the remaining issue in case of not selecting the capsule before pasting
Comment 13 Peter Cigehn CLA 2017-03-02 08:13:52 EST
The basic case selection the capsule frame prior to pasting has been verified to be fixed in the latest Papyrus-RT build. The remaining cases of selections prior to pasting still throws exceptions. This will be tracked by Bug 512895.
Comment 14 Peter Cigehn CLA 2017-03-02 08:14:06 EST
Closing as verified fixed.