Community
Participate
Working Groups
Created attachment 263051 [details] setup
Created attachment 263052 [details] 1st bug situation
Created attachment 263053 [details] 2nd bug situation
Created attachment 263054 [details] 3rd bug situation
The tool behaves strangely when drag and dropping a protocol into a package that contains another protocol. Assume we have a model as depicted on attachment 'setup.pmg': protocol p1 resides in package Protocols, and another protocol p2 resides in package Structure. Each protocol having a single message. Then drag and dropping p2 into package Protocols: 1) as captured on attachment '1st bug situation', results in p2 not moving but losing its declared message p2Msg. 2) as captured on attachment '2nd bug situation', results in p1 being overwritten by p2, and p1 seems to be lost from model. Furthermore, in model explorer it seems that p2's message is lost, while p1's message is kept. However, looking at the properties of the protocol (Real Time tab), p1's original message appears. So what is being displayed in the model explorer and what is displayed in the properties tab is inconsistent. 3) as captured on attachment '3rd bug situation', results in p2 being lost from the model. Note: if the target of the DnD operation is the package icon of the Protocols package then the result is as expected. Note: removing the 'UML-RT Protocols customization' helps in better seeing what is going on in the background and what causes this bug.
Confirmed by Peter via email. Moving to new.
New Gerrit change created: https://git.eclipse.org/r/81954
Gerrit change https://git.eclipse.org/r/81954 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=abf00b7602af4f23148f0287e9054372e42e4cff
(In reply to Eclipse Genie from comment #8) > Gerrit change https://git.eclipse.org/r/81954 was merged to [master]. Note that this fix is in the element-type advice for the protocol-container. Therefore, it will also be in effect when dragging and dropping stuff explicitly into protocol-containers when the protocol customization in Model Explorer is not active. But, that seems sensible, as protocol-containers are not interesting as general-purpose packages and the particular kind of SetRequests that Model Explorer's drop assistant processes are only useful in the context of the Model Explorer. (wholesale setting of a containment reference is, almost always, an odd thing to do)
I have tested this in the latest Papyrus-RT build. It looks like case 2 and case 3 now works. Case 2 causes p2 to be moved inside the Protocols package and it is ordered before p1 as expected. Case 3 causes nothing to happen since it does not make sense to move p2 inside of p1. You do however get a dirty indicator on the model, even though nothing should have been changed. Not sure if this is expected or not. But case 1, still seem to mess things up. Case 1 is really a "no-op", i.e. the semantic should be to still have p2 in the Structure package ordered after the Protocols package, i.e. basically it should stay "as-is". But when you do this drag-and-drop, what seem to happen is that the <<Protocol>> Collaboration of p2 gets dragged outside of its <<ProtocolContainer>> Package, which seemingly makes it loose its protocol message when you have the protocol customization enabled. Checking the .uml-file directly in the UML editor reveals that the Structure package now as packagedElements the <Package> Protocols, <<Protocol>> <Collaboration> p2 and <<ProtocolContainer>> <Package> p2, and the <<ProtocolContainer>> <Package> p2 does not contain its Collaboration. PS. When testing this I initially got very confused also that we had some naming issues of the internal elements, apart from that things moved around in a wrong way. But I discovered that using F2 to rename the protocol only renamed the collaboration. Only when renaming the protocol in the properties view you get the correct name on all relevant internal elements of the protocol. I will write a separate Bugzilla for this. DS.
New Gerrit change created: https://git.eclipse.org/r/82116
(In reply to Peter Cigehn from comment #10) > > But case 1, still seem to mess things up. Case 1 is really a "no-op", i.e. > the semantic should be to still have p2 in the Structure package ordered > after the Protocols package, i.e. basically it should stay "as-is". But when Yes, this is subtly different: the object relative to which the protocol is being dropped is not a another protocol but some other kind of element, so that Model Explorer finds the correct package to drop into but still has the wrong kind of object to drop. (In reply to Eclipse Genie from comment #11) > New Gerrit change created: https://git.eclipse.org/r/82116 This fixes that case #1, with a JUnit test for it.
Gerrit change https://git.eclipse.org/r/82116 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=ba9bd2d029fe053a359af8856946b69259d84406
New Gerrit change created: https://git.eclipse.org/r/82120
(In reply to Peter Cigehn from comment #10) > > Case 3 causes nothing to happen since it does not make sense to move p2 > inside of p1. You do however get a dirty indicator on the model, even though > nothing should have been changed. Not sure if this is expected or not. This happens because the Model Explorer tries to drop the protocol into the nestedClassifier property of the message-set interface containing the operation, but it finds that the operation is not in the nestedClassifier property and so doesn't know where to position the dropped protocol in the nested classifiers list, and so just sets the already empty nested classifiers list to an empty list. That's okay, but it is a useless command. The same happens, btw, on attempt to drop a protocol next to a port or a part in a capsule. (In reply to Eclipse Genie from comment #14) > New Gerrit change created: https://git.eclipse.org/r/82120 This ensures that any attempt to drop a protocol into the nested classifiers of a class or interface in a UML-RT model is blocked.
Gerrit change https://git.eclipse.org/r/82120 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=f51cc4396a7bed3e82c6c45757552b32fbd3c5b1
(In reply to Eclipse Genie from comment #13) > Gerrit change https://git.eclipse.org/r/82116 was merged to [master]. (In reply to Eclipse Genie from comment #16) > Gerrit change https://git.eclipse.org/r/82120 was merged to [master].
I've tested this in the latest Papyrus-RT build and all the three originally reported cases now seem to work as expected. Now when these basic ones are working, I played around a bit more with a few more cases, which did not behave as one would expect. 1) Two protocols contained in the same package. Try to reorder them by moving the first one after the other, i.e. the "head" of the move indicator should be at the same nesting level as the protocol itself and not nested inside the protocol. Nothing happens when you do this. Sure, when the "head" indicator is nested inside the protocol nothing should happen since you cannot move a protocol inside another protocol. But when you have the "head" nested at the same level I would have expected that you did a re-order of the protocols in the same package. After some more testing with 3 protocols in a package, it looks to be the border case when trying to drop and move the protocol last in the package. If you drop the first protocol after the second then you are able to reorder. But not dropping the first after the third (and last) protocol in the package. 2) Two protocols contained in the same package. If you drop the first protocol directly after itself, i.e. basically perform a "no-op" since you move to the position in the containing package that it already have, then the protocols change order. This actually seem to be also some general issue, because I can see the same kind of behavior for ordinary model elements, e.g. a class. But for classes the behavior with swapping order, when it shouldn't, happens "random". Sometimes it performs the swap (when it shouldn't) and sometimes it works as expected, i.e. nothing happens since the drop shouldn't change order. For protocols though it is consistently changing the order, even if there should be a "no-op". 3) If you have three protocols in a package and drop the the second protocol before itself, i.e. basically perform a "no-op" since dropping before itself should not change the order, then the second and third protocol in the package changes order. I am not sure if we shall try to fix these additional border cases within the scope of this Bugzilla, or if shall track them in new Bugzillas. Since there seem to be some issues also in base Papyrus with ordinary model elements, maybe there are some general issues needed to be fixed there.
(In reply to Peter Cigehn from comment #18) > > I am not sure if we shall try to fix these additional border cases within > the scope of this Bugzilla, or if shall track them in new Bugzillas. Since > there seem to be some issues also in base Papyrus with ordinary model > elements, maybe there are some general issues needed to be fixed there. Yes, the drag-and-drop implementation in Model Explorer in Papyrus needs work. I don't like that it * is not extensible to support DSML-specific drag-and-drop needs * assumes dropping into the eContainer, without regard for its own facet customizations of the tree structure * does not account for the fact that a dropped object may not be contained in the same EReference as the one it is dropped next to Basically, it needs some overhaul in Papyrus to address the residual problems that you're seeing. The issues raised by the OP are now fixed, so the rest should be tracked separately.
I wrote Bug 502556 to track the issues identified in Comment 17 and the proposed improvements in Papyrus in Commen 18. Putting this Bugzilla into verified, since the three original issues identified in Comment 5, all have been fixed in the latest Papyrus-RT build.
Closing in preparation of v0.8 release
