Community
Participate
Working Groups
Created attachment 262233 [details] State machine diagram with duplicated transitions After moving the ComputerSystem sample model from Papyrus-RT 0.7.2 to the Neon stream, I get duplicated transition shown in the newly created UML-RT State Machine Diagram (see attachment). I can remove them from the diagram (after making the diagram unsynchronized), in which case the diagram is fine, but closing and opening Eclipse brings back the diagram with duplications. I took the following steps when upgrading the diagram to Neon: 1) Imported (with copy) the model into a new workspace 2) Opened the model, updated the profile. 3) Created a new UML-RT Capsule Diagram for each capsule, cleaned up the diagram and removed the old composite structure diagram. 4) Created a new UML-RT State Machine Diagram for each state machine and cleaned up the diagram. Note that, at this point, no duplicates are shown. 5) Closed and re-opened Eclipse 6) duplicated transitions are found. 7) Note that removing the new ones (i.e., the ones that do not look "correct", e.g., not rectilinear) results in in the same scenario as see from step 5. Removing he old one (i.e., the one cleaned up in step 4) results in both the transition and its "shadow" being removed.
Some further characterization... This seems to only happen for external self-transitions (I haven't tried internal...). If I add a junction point in the self transition (i.e., one transition from state to junction point and another transition from the junction point back to the state), this does not happen. Error with: +-------+ | state | | +-----------+ | | | | +<----------+ | | +-------+ But not with: +-------+ | state | jct | +---->( )---+ | | | | +<----------+ | | +-------+
Also, the fact that this model was "upgraded" from Mars to Neon is a red herring. I created the same model from scratch and get the same problem. Installed software: Basic code-generation functions (Incubation) 0.7.0 org.eclipse.papyrus.designer.languages.common.base Eclipse Modeling Project C/C++ Development Tools 9.0.0.201605310053 org.eclipse.cdt.feature.group Eclipse CDT Code generation extensionpoints (Incubation) 0.7.0 org.eclipse.papyrus.designer.languages.common.extensionpoints Eclipse Modeling Project Eclipse Platform 4.6.0.v20160519-2118 org.eclipse.platform.feature.group Eclipse.org Eclipse Platform 4.6.0.I20160519-1730 org.eclipse.platform.ide Eclipse.org Eclipse RCP 4.6.0.v20160519-2118 org.eclipse.rcp.feature.group Eclipse.org Oomph Setup 1.4.0.v20160601-0622 org.eclipse.oomph.setup.feature.group Eclipse Oomph Project Papyrus C++ profile, view and code generation (Incubation) 0.7.0 org.eclipse.papyrus.designer.languages.cpp.feature.feature.group Eclipse Modeling Project Papyrus C/C++ profile (Incubation) 0.7.0 org.eclipse.papyrus.designer.languages.cpp.library Eclipse Modeling Project Papyrus CDT editor integration (Incubation) 0.7.0 org.eclipse.papyrus.designer.languages.cpp.cdt.texteditor Eclipse Modeling Project Papyrus DSML Validation Feature (Incubation) 1.2.0.201606011305 org.eclipse.papyrus.extra.dsml.validation.feature.feature.group Eclipse Modeling Project Papyrus RT Feature (Incubation) 0.7.2.201606010947 org.eclipse.papyrusrt.feature.feature.group Eclipse Modeling Project Papyrus UML 2.0.0.201606011253 org.eclipse.papyrus.sdk.feature.feature.group Eclipse Modeling Project Papyrus-RT Code Generator 0.7.2.201606010948 org.eclipse.papyrusrt.codegen-feature.feature.group Zeligsoft (2009) Limited Papyrus-RT Run-Time System 0.7.2.201606010948 org.eclipse.papyrusrt.rts-feature.feature.group Zeligsoft (2009) Limited
(In reply to Charles Rivet from comment #2) > Also, the fact that this model was "upgraded" from Mars to Neon is a red > herring. I created the same model from scratch and get the same problem. If that is the case, maybe it is good if the summary could be updated to avoid the confusion that this should be a migration/regression issue, but that it in fact then is a general issue with duplicated external self transitions. I've tested this myself, and indeed if you add an external self transition to a state and then close the model and re-open it again, the self transition becomes duplicated in the diagram.
Not sure if this is related in any way, but the external self transitions is incorrectly shown on the "inside" of a composite state, i.e if you add an external self transition to a sinple state, and then turn this state into a composite state by double-clicking on it, then that external self transition is shown in the state machine diagram of the composite state. Only local self transitions should be shown in the "inside" of the composite state. External self transitions should only be shown on the "outside" of the composite state. Maybe the duplication is due to this incorrect display of external self transitions, causing them to actually be duplicated on the "outside".
*** Bug 498456 has been marked as a duplicate of this bug. ***
I don't think this bug occurs only for models migrated from Mars to Neon. It happens with models created on Neon too. See Bug 498456.
(In reply to Ernesto Posse from comment #6) > I don't think this bug occurs only for models migrated from Mars to Neon. It > happens with models created on Neon too. See Bug 498456. I've made a few tests. As Ernesto said, the error can already be reproduced with a simple model with a single state and a self transition. It does not occur with the standard Papyrus state-machine diagram. It only occurs in a UML-RT state-machine diagram and with states that have the <<RTState>> stereotype (I realized that since I dragged the states of the "normal" SM diagram that I created earlier into the UML/RT diagram). The duplication occurs in the moment, that the <<RTState>> stereotype is applied. Since it's a specific UML/RT rather than general state-machine diagram issue, Asma will look more deeply into the error.
New Gerrit change created: https://git.eclipse.org/r/79641
I tested this bug and found while debugging that the this method in the DefaultUMLSemanticChildrenStrategy is the cause of the duplication: public List<EObject> caseVertex(Vertex object) { result.addAll(object.getOutgoings()); result.addAll(object.getIncomings()); return super.caseVertex(object); } it added the self transition twice in the resulting list : once as an outgoing transition and once as an incoming transition I proposed a fix for Papyrus RT by modifying the RTStateMachineSemanticChildrenStrategy (removing the duplicated transitions) but may be an appropriate fix could be in Papyrus itself, in DefaultUMLSemanticChildrenStrategy itself (do not return a result with duplicated transitions) because for each transition, a view (edge) will be created Asma
(In reply to Ernesto Posse from comment #5) > *** Bug 498456 has been marked as a duplicate of this bug. *** (In reply to Ernesto Posse from comment #6) > I don't think this bug occurs only for models migrated from Mars to Neon. It > happens with models created on Neon too. See Bug 498456. it happens also for Papyrus RT Mars version : I tested this bug for 19/02/2016 commit 83b36f2382635abc6b7079de30ae3de26a6c394e and the self external transitions are duplicated when reopening the sm diagram.
Hi Christian, while it seems logical to me that the nested class ConnectionsSwitch (in DefaultUMLSemanticChildrenStrategy) should not return duplicate entries, I'm a bit reluctant due to possible side effects. Since you are the primary author: do you see any negative side effects of filtering duplicates there? (In reply to smaoui asma from comment #9) > I tested this bug and found while debugging that the this method in the > DefaultUMLSemanticChildrenStrategy is the cause of the duplication: > > public List<EObject> caseVertex(Vertex object) { > result.addAll(object.getOutgoings()); > result.addAll(object.getIncomings()); > return super.caseVertex(object); > } > > it added the self transition twice in the resulting list : once as an > outgoing transition and once as an incoming transition > > I proposed a fix for Papyrus RT by modifying the > RTStateMachineSemanticChildrenStrategy (removing the duplicated transitions) > but may be an appropriate fix could be in Papyrus itself, in > DefaultUMLSemanticChildrenStrategy itself (do not return a result with > duplicated transitions) because for each transition, a view (edge) will be > created > > Asma
(In reply to Ansgar Radermacher from comment #11) > Hi Christian, > > while it seems logical to me that the nested class ConnectionsSwitch (in > DefaultUMLSemanticChildrenStrategy) should not return duplicate entries, I'm > a bit reluctant due to possible side effects. Since you are the primary > author: do you see any negative side effects of filtering duplicates there? No, I don't. It's a pretty obvious oversight, and there are several other cases where we do filter out self-edges in this way. Even in the PapyrusCanonicalEditPolicy, itself, if I'm not mistaken!
New Gerrit change created: https://git.eclipse.org/r/79925
Gerrit change https://git.eclipse.org/r/79925 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=00da8629f652e8f9f0597a133a40054378f75764
New Gerrit change created: https://git.eclipse.org/r/79931
Gerrit change https://git.eclipse.org/r/79931 was merged to [streams/2.0-maintenance]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=e9952d19bbc996fabb891f26d9b21af5cc7980cb
Ansgar, as the patchs have been integrated in Papyrus, should this bug still be opened? Did you plan to write some tests on that issue?
(In reply to Remi Schnekenburger from comment #17) > Ansgar, as the patchs have been integrated in Papyrus, should this bug still > be opened? > > Did you plan to write some tests on that issue? No, I propose to close.
The impacted class should be easily tested using JUnit tests. Reopening bug, please implement JUnit tests before closing.
New Gerrit change created: https://git.eclipse.org/r/88851
(In reply to Eclipse Genie from comment #20) > New Gerrit change created: https://git.eclipse.org/r/88851 I get a bit confused here. Why do we have a Papyrus-RT bug, that involves changes in Papyrus (including unit tests)? Shouldn't we have had Papyrus bug for that, which blocks this Payprus-RT bug? We currently have an off-line discussion related to how to get control over changes that needs to be made in Papyrus, which Papyrus-RT depends on. And "hiding" changes in Papyrus, by having a Papyrus-RT-only bug, with no "depends on" to any Papyrus bug, like this, makes it very hard to keep track of those kinds of dependencies. I guess that the actual change was already merged and being part of Neon.2, and it was just the missing unit test that now came post-Neon.2 and which will part of Neon.3 (or an intermediate release of Papyrus), right?
(In reply to Peter Cigehn from comment #21) > I guess that the actual change was already merged and being part of Neon.2, > and it was just the missing unit test that now came post-Neon.2 and which > will part of Neon.3 (or an intermediate release of Papyrus), right? I even see that the Gerrit change for the unit test is targeting master, and will only make its way into Oxygen (which probably is okay for unit tests). So the question remains: The actual change (to avoid duplicated transitions) was already merged and part of Neon.2, right?
(In reply to Peter Cigehn from comment #22) > (In reply to Peter Cigehn from comment #21) > > I guess that the actual change was already merged and being part of Neon.2, > > and it was just the missing unit test that now came post-Neon.2 and which > > will part of Neon.3 (or an intermediate release of Papyrus), right? > > I even see that the Gerrit change for the unit test is targeting master, and > will only make its way into Oxygen (which probably is okay for unit tests). > So the question remains: The actual change (to avoid duplicated transitions) > was already merged and part of Neon.2, right? Yes, the actual change is already available for Neon.2. I have done the missing unit test first for master (as usual, unless specific for a maintenance branch). If it gets accepted, I will cherry-pick it to neon. Yes, we should have created an additional Papyrus bug and mark it as blocking this one - after discovering that it is indeed a Papyrus issue. Should we do that now or is it a bit late, since the corrective patch has already been merged and refers to this bug?
(In reply to Ansgar Radermacher from comment #23) > Yes, the actual change is already available for Neon.2. I have done the > missing unit test first for master (as usual, unless specific for a > maintenance branch). If it gets accepted, I will cherry-pick it to neon. > > Yes, we should have created an additional Papyrus bug and mark it as > blocking this one - after discovering that it is indeed a Papyrus issue. > Should we do that now or is it a bit late, since the corrective patch has > already been merged and refers to this bug? No, personally I do not think that is necessary to add any additional administration overhead at this point in time, since the actual fix already is include in the Neon.2 release of Papyrus, and the only remaining aspect was the missing unit tests. But maybe someone else have some other opinion about it. Personally I just wanted to get confirmation that I had understood what this was about.
Gerrit change https://git.eclipse.org/r/88851 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=d767d384224d89f97f0506b3787a3412bdad23ab
New Gerrit change created: https://git.eclipse.org/r/89177
Gerrit change https://git.eclipse.org/r/89177 was merged to [streams/2.0-maintenance]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=d053ab0e57db25303604ea58c7e82b2d22dd7ce4
Resolved with gerrit commits for master and 2.0-maintenance.
Verified to be fixed in the latest Papyrus-RT build. Not duplicated external self transitions, not even "duplicated" on the inside of composite state. The external self transition is only shown on the "outside" of the composite state. Only local self transitions are shown on the inside of the compoiste state. Putting into verified fixed, and Charles can close, or reopen if needed.
Closing
