Re: [papyrus-rt-dev] Failure in Compare Tests: Protocol Move Change

[Philip Langer <planger@xxxxxxxxxxxxxxxxx>]

Hi Christian,

thanks for pointing that out!

I briefly debugged into the failing test but couldn't find an obvious problem. Also there doesn't seem to be a particular change in EMF Compare recently that sounds related to this... weird indeed!

Can you please @Ignore the test case, if it blocks you from merging your work into master, and open a BR with your findings? We'll have a look at this right after the Christmas break.

Thanks and best wishes,

Philip

PS: I wish you a merry Christmas / great vacation!

On Fri, Dec 23, 2016 at 4:09 PM, Christian Damus <give.a.damus@xxxxxxxxx> wrote:

Hi, Team,

For some while now, a test in the Papyrus-RT Compare tests has been failing in the nightly builds:

org.eclipse.papyrusrt.umlrt.tooling.compare.internal.UMLRTProtocolChangeTest.testMergeSingleProtocolMoveInTwoWayLeftToRight 

It has been bothering me because it is the last remaining test failure in my inheritance branch builds.  😉

The test fails on the last assertion, which requires that after the merge, there must be no differences.  However, there is a difference:  the «protocolContainer» stereotype was unapplied from the protocol-container package that was moved because it was deemed no longer to be applicable.

Debugging into, I find something strange:  at the time the protocol-container package is attached to its new parent package by the merger, the protocol-container’s stereotype application traces to the UML-RT profile loaded in the “left” resource set, but the profile that is actually applied to the model in which the merge happens is loaded in the “right” resource set.  Consequently, the UML API thinks that the profile defining the stereotype is not applied (they are two distinct copies of the same profile) and so it destroys the stereotype application, which results in the changes being detected that fail the test.

The weirder part is, if in debugging the UML API’s determination of inapplicable stereotypes (ElementOperations::unapplyAllNonApplicableStereotypes) I unwind the stack frame to try again, on the second try, the stereotype is found to be applicable and the test proceeds to pass.

Any idea what could have changed in the EMF Compare framework to cause this test failure?  And is somebody looking into it?  This will block any attempts to merge Gerrits into the Tooling component.

Thanks,

Christian

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev

--

Dr. Philip Langer

Senior Software Architect / General Manager
EclipseSource Services GmbH