Community
Participate
Working Groups
Papyrus-RT shall migrate to Oxygen version for version 1.0.
A new branch will be created for migration, with a new set of gerrit jobs.
I'll take care of updating the developer and tester Oomph setup models.
New Gerrit change created: https://git.eclipse.org/r/94000
This is really a P1 from a product management point of view and, as such, should be investigated and dealt with sooner rather than later! (just in case it is not "trivial"...)
The RSA import, on which the RSARTE import depend, is moving to a new Git and p2 repo, see Bug 514747. Shall we track the needed changes due to this within the scope of this bug, or should we track that separately?
(In reply to Peter Cigehn from comment #5) > The RSA import, on which the RSARTE import depend, is moving to a new Git > and p2 repo, see Bug 514747. Shall we track the needed changes due to this > within the scope of this bug, or should we track that separately? I think that should be tracked in that bug, no need to run too much administrative work.
(In reply to Remi Schnekenburger from comment #6) > (In reply to Peter Cigehn from comment #5) Yes, this will have to be accounted for in the TPDs (Rémi) and the Oomph setups (me).
Gerrit change https://git.eclipse.org/r/94000 was merged to [committers/rschnekenbu/oxygen]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=12057e610539c2809987d3cf24b23917f6661a1b
Another move is in progress as well, related to the DSML Validation, see Bug 512989. I assume we need to handle that as well, in the corresponding was as for the RSA import in Comment 5, at least for the developer setup. Not sure if we actually have any mandatory dependencies from Papyrus-RT itself, they should only be optional if I have understood it correctly.
New Gerrit change created: https://git.eclipse.org/r/94796
Gerrit change https://git.eclipse.org/r/94796 was merged to [committers/rschnekenbu/oxygen]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=4c96b8b7f5449233b0cc64d280d9395d839b9880
New Gerrit change created: https://git.eclipse.org/r/94831
New Gerrit change created: https://git.eclipse.org/r/95339
Gerrit change https://git.eclipse.org/r/95339 was merged to [committers/rschnekenbu/oxygen]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=8187d346c87638dd711f4f97af417b067c83f6d5
New Gerrit change created: https://git.eclipse.org/r/95872
New Gerrit change created: https://git.eclipse.org/r/95871
New Gerrit change created: https://git.eclipse.org/r/95870
Gerrit change https://git.eclipse.org/r/94831 was merged to [committers/rschnekenbu/oxygen]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=5c36a28a24b7382356875e04d378fbd2ca1d0201
Gerrit change https://git.eclipse.org/r/96037 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=782809266cdd1fa308b8997d15818e427f7c8e32
New Gerrit change created: https://git.eclipse.org/r/96140
Gerrit change https://git.eclipse.org/r/96140 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=400c075d6baa53caeb548faa7b56c5d1367fa65a
New Gerrit change created: https://git.eclipse.org/r/96161
New Gerrit change created: https://git.eclipse.org/r/96160
Gerrit change https://git.eclipse.org/r/96160 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/papyrus-rt.git/commit/?id=cbfdf181aef16132dbd20cd0b45e9ac6214bbfec
New Gerrit change created: https://git.eclipse.org/r/96226
Gerrit change https://git.eclipse.org/r/96226 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=1f1ef78b8d5670f54cd87175b05e808c0eff6613
New Gerrit change created: https://git.eclipse.org/r/96301
Gerrit change https://git.eclipse.org/r/96301 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=9bdfd395ef24a26f20fbf47197322cab85e017e8
New Gerrit change created: https://git.eclipse.org/r/96322
Gerrit change https://git.eclipse.org/r/96322 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=e7a4695cee5903e8aac534a56bbe51db06d76e61
New Gerrit change created: https://git.eclipse.org/r/96328
New Gerrit change created: https://git.eclipse.org/r/96383
Gerrit change https://git.eclipse.org/r/96383 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=cf5df64eb597bbcd728566f5da8acf251a861797
New Gerrit change created: https://git.eclipse.org/r/96394
New Gerrit change created: https://git.eclipse.org/r/96396
Gerrit change https://git.eclipse.org/r/96394 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=9466886e927779c5bad1661f5ba38b1f1229d7d0
New Gerrit change created: https://git.eclipse.org/r/96422
Gerrit change https://git.eclipse.org/r/96422 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/papyrus-rt.git/commit/?id=cfbdfdda4ea392fe1c78835e3d4cd293d2d131aa
New Gerrit change created: https://git.eclipse.org/r/96427
Gerrit change https://git.eclipse.org/r/96427 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=7aa1ce1e9508e783aa833b76c0ce199d19313f07
New Gerrit change created: https://git.eclipse.org/r/96431
Gerrit change https://git.eclipse.org/r/96396 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=c203cdab4849a87f787b6a3396660df39af2fec5
New Gerrit change created: https://git.eclipse.org/r/96444
Gerrit change https://git.eclipse.org/r/96444 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=7f4f57b4639d31375e433717d65aac6df0783ae9
New Gerrit change created: https://git.eclipse.org/r/96575
Gerrit change https://git.eclipse.org/r/96431 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/papyrus-rt.git/commit/?id=47088e912adba7c9b6b744c7c623be1467266576
New Gerrit change created: https://git.eclipse.org/r/96648
Gerrit change https://git.eclipse.org/r/96648 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=23f6c906ebaafe1166eb7b0299e60e1984ce54eb
New Gerrit change created: https://git.eclipse.org/r/96812
Gerrit change https://git.eclipse.org/r/96812 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=42879ea34807cbdf608622629f354c9fc14e94c5
New Gerrit change created: https://git.eclipse.org/r/96854
New Gerrit change created: https://git.eclipse.org/r/96862
Gerrit change https://git.eclipse.org/r/96854 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=8d41c6b6f553f6a4c999b1eefbce44d1a4424ed3
Gerrit change https://git.eclipse.org/r/96862 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=44ed118eea33110d4aa9dfb759ebfcca75221428
New Gerrit change created: https://git.eclipse.org/r/96940
Before we go ahead and write new separate bugs I will provide some feedback regarding regressions that can be seen after the move to the Oxygen track: 1) New model wizard adds an additional . in the name of the model files, i.e. the names becomes name..di, name..notation, name..uml. 2) The new model wizard shows the UML-RT Capsule Structure Diagram and UML-RT State Machine Diagram in the list of reprentation kinds. Bug 475805 originally tracked the removal of these diagram from the new model wizard. 3) The possibility of applying an additional profile is removed. Has this been made intentional? Not sure how important this is, but to be consistent with the base Papyrus new model wizard, the possibility of applying an additional profile (below the template drop-down menu) maybe should be kept as we had in 0.9. Not sure why and how this one went missing (I have a feeling that the widgets for selecting a profile has come and gone in the new model wizard a few times after the move to Oxygen). 4) When creating a new Papyrus project/model, a number of .properties files gets created (Ecore.metamodel.properties, Ecore.profile.properties, EcorePrimitiveTypes.libary.properties, Standard.profile.properties, UML.metamodel.properties, UMLPrimitiveTypes.libary.properties). I have a strong feeling that this is related to the new internalization feature. When testing in base Papyrus I cannot see the same effect with additional .properties files being created, so it seem to be an issue specifically in Papyrus-RT. 5) When adding a protocol message to a protocol, the protocol does not automatically expand and selects the protocol message for editing. This was originally tracked by Bug 480403, and this has apparently now had a regression. We had a work around for this, where Bug 502351 trackes the reversal of the work around. But apparently the work around in itself does not work anymore. 6) When creating the first parameter of a protocol message it is no longer named 'data' as it should be. Originally tracked by Bug 479635. Seems to be related also that when creating a protocol message parameter, the popup menu for selecting the type of the parameter, i.e. C++ primitive types, existing types, new class or enumeration. 7) The initial layout of a state-machine diagram is even worse than before, causing the scrollbar that we managed to remove to always appear. I guess this could be tracked by the already existing Bug 506265. The problem is that Bug 506265 is currently planned for Future so then we need to replan that for 1.0. Or at least fix the regression after the move to Oxygen to make sure that the initial placement is not partly outside the frame causing the scroll bar to appear (and causes the transition to not even be shown). 8) Deleting a state in a state-machine diagram, causes a "Region" to be left "dangling" in the diagram causing it to be corrupt. Closing the diagram and re-opening it, causes an exception to be thrown java.lang.ClassCastException: org.eclipse.papyrusrt.umlrt.uml.internal.impl.RegionRTImpl cannot be cast to org.eclipse.uml2.uml.State 9) When establishing state-machine inheritance, the layout is not inherited by default, i.e. the diagram in the subclass does not have the "Follow superclass view" enabled for the elements, seemingly causing even more refresh issues for the layout inheritance in state-machine diagrams (have not tested yet if the same issue exist for structure diagrams). These are just a few on top of my head. I am not sure if we shall start writing separate bugs or not (I am just afraid that we will get too much overhead if we start writing separate bugs too early).
Some additional observations: 10) The general feeling is that the Oxygen version have some severe performance issues. It feels that most operations take longer time, and some specific operations is extremely slow, e.g. removing a model element takes a very long time or bringing up a dialog in the properties view using the pen edit button or the green + create button. Not sure if this specific to Papyrus-RT or if this general "sluggishness" exist in base Papyrus. Feels like some pretty fundamental issue (which does not seem related at all to the size of the model, even the smallest "toy example" feels very sluggish when working with it). 11) The issue seen in bullet 9 (in Comment 57) can also be seen in the structure diagram. When having established a generalization the structure diagram layout in the subclass does not follow along the layout in the superclass view. You have to explicitly select all elements (using Ctrl+A for example) and then use the "Follow position in superclass view"-button in the toolbar to enable that the layout in the subclass follows the superclass. 12) Redefining the type of a capsule part and port does not show the capsule part or port label in bold (if I remember correctly some unit test that was suppressed already had detected this regression).
Yet one more observation which I forgot to mention: 13) The "New Diagram" menu is empty again. We had the a similar regression when moving from Mars to Neon, which was originally tracked with Bug 492359. When the model have the UML-RT architecture context enabled, the "New Diagram" menu is completely empty so you cannot create any ordinary UML diagrams. Maybe this is intentional. This is then highly related to Bug 511187 and the discussion about the create-diagrams-first work flows, including creating a UML-RT Capsule Structure Diagram first (which then would create the capsule and the diagram nested in it as usual).
Concerning the comment 57, bullet 4: A bug was created (https://bugs.eclipse.org/bugs/show_bug.cgi?id=516712) and a patch proposed. This will be available soon.
New Gerrit change created: https://git.eclipse.org/r/97225
Gerrit change https://git.eclipse.org/r/97225 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=6a367ed83c649eab912f422888763f7bf4acf779
(In reply to Nicolas FAUVERGUE from comment #60) > Concerning the comment 57, bullet 4: > A bug was created (https://bugs.eclipse.org/bugs/show_bug.cgi?id=516712) and > a patch proposed. This will be available soon. I can confirm that the issue in Comment 57 bullet 4 has been fixed with the Gerrit change for Bug 516712 being merged. The additional .properties files are no longer created.
Another issue that can be seen: 14) The decorator for showing if an element is redefined in a state-machine diagram, e.g. on states and transitions, does not refresh correctly. When either redefining, or reinheriting, the decorator is not shown respectively removed correctly. You have to explicitly refresh the diagram using F5 to get the decorator to be updated.
(In reply to Peter Cigehn from comment #57) > Before we go ahead and write new separate bugs I will provide some feedback > regarding regressions that can be seen after the move to the Oxygen track: > > 1) New model wizard adds an additional . in the name of the model files, > i.e. the names becomes name..di, name..notation, name..uml. That was caused by an empty string for model extension in uml-rt core plugin. Value has been unset to null, so that no "."+emptyString+".di" is added to the model name for file name. > 2) The new model wizard shows the UML-RT Capsule Structure Diagram and > UML-RT State Machine Diagram in the list of reprentation kinds. Bug 475805 > originally tracked the removal of these diagram from the new model wizard. This one will require an evolution on the wizard or the architecture framework metamodel, as the workaround cannot be used anymore. This will require some work in Papyrus, to allow Papyrus-RT to customize the wizard itelf, as for example a boolean in the representation kind definition to show or not in wizard or the wizard should check if the diagram can really be created or not (but not sure this would be easy to do). Another solution is also to let users create a capsule diagram, but selecting this should create an additional capsule, as done for the UML diagrams. (Same for state machine, this should create a capsule containing the state machine). > > 3) The possibility of applying an additional profile is removed. Has this > been made intentional? Not sure how important this is, but to be consistent > with the base Papyrus new model wizard, the possibility of applying an > additional profile (below the template drop-down menu) maybe should be kept > as we had in 0.9. Not sure why and how this one went missing (I have a > feeling that the widgets for selecting a profile has come and gone in the > new model wizard a few times after the move to Oxygen). I do not have this issue in my version, I still have the apply profile from workspace or registered profile. > > 4) When creating a new Papyrus project/model, a number of .properties files > gets created (Ecore.metamodel.properties, Ecore.profile.properties, > EcorePrimitiveTypes.libary.properties, Standard.profile.properties, > UML.metamodel.properties, UMLPrimitiveTypes.libary.properties). I have a > strong feeling that this is related to the new internalization feature. When > testing in base Papyrus I cannot see the same effect with additional > .properties files being created, so it seem to be an issue specifically in > Papyrus-RT. This one is handled by Papyrus, see comment 60 > > 5) When adding a protocol message to a protocol, the protocol does not > automatically expand and selects the protocol message for editing. This was > originally tracked by Bug 480403, and this has apparently now had a > regression. We had a work around for this, where Bug 502351 trackes the > reversal of the work around. But apparently the work around in itself does > not work anymore. The element types for model explorer were still registered using extension point and not the architecture model, so the workaround advice is not added to the umlrt.architecture context. This is an easy fix (already fixed locally). This is a good reason to work also on having RCPTT back again working on Papyrus-RT, as a test was written for that workaround. > > 6) When creating the first parameter of a protocol message it is no longer > named 'data' as it should be. Originally tracked by Bug 479635. Seems to be > related also that when creating a protocol message parameter, the popup menu > for selecting the type of the parameter, i.e. C++ primitive types, existing > types, new class or enumeration. Wrong element type selected during migration, fixed with an incoming patch > 7) The initial layout of a state-machine diagram is even worse than before, > causing the scrollbar that we managed to remove to always appear. I guess > this could be tracked by the already existing Bug 506265. The problem is > that Bug 506265 is currently planned for Future so then we need to replan > that for 1.0. Or at least fix the regression after the move to Oxygen to > make sure that the initial placement is not partly outside the frame causing > the scroll bar to appear (and causes the transition to not even be shown). To be investigated furthermore, I did not have the issue on quick testing. > 8) Deleting a state in a state-machine diagram, causes a "Region" to be left > "dangling" in the diagram causing it to be corrupt. Closing the diagram and > re-opening it, causes an exception to be thrown > java.lang.ClassCastException: > org.eclipse.papyrusrt.umlrt.uml.internal.impl.RegionRTImpl cannot be cast to > org.eclipse.uml2.uml.State As mentionned, there is a CCException during deletion of the state, which may cause the phantom region. The label is probably refreshed after deletion, and in this case, edit part is targeting nothing so its parent. At least a check on cast should remove this issue. > > 9) When establishing state-machine inheritance, the layout is not inherited > by default, i.e. the diagram in the subclass does not have the "Follow > superclass view" enabled for the elements, seemingly causing even more > refresh issues for the layout inheritance in state-machine diagrams (have > not tested yet if the same issue exist for structure diagrams). This may be perhaps better that Christian get an eye on it, he may know faster than me the probable cause of this issue. > > These are just a few on top of my head. I am not sure if we shall start > writing separate bugs or not (I am just afraid that we will get too much > overhead if we start writing separate bugs too early).
New Gerrit change created: https://git.eclipse.org/r/97315
(In reply to Remi Schnekenburger from comment #65) > (In reply to Peter Cigehn from comment #57) > > 2) The new model wizard shows the UML-RT Capsule Structure Diagram and > > UML-RT State Machine Diagram in the list of reprentation kinds. Bug 475805 > > originally tracked the removal of these diagram from the new model wizard. > > This one will require an evolution on the wizard or the architecture > framework metamodel, as the workaround cannot be used anymore. This will > require some work in Papyrus, to allow Papyrus-RT to customize the wizard > itelf, as for example a boolean in the representation kind definition to > show or not in wizard or the wizard should check if the diagram can really > be created or not (but not sure this would be easy to do). Another solution > is also to let users create a capsule diagram, but selecting this should > create an additional capsule, as done for the UML diagrams. (Same for state > machine, this should create a capsule containing the state machine). Okay, maybe it is best to allow the creation of the diagrams, but as you say, this would then also create the capsule (in which the diagram will be contained). This would then be some kind of extension to the aspects tracked by Bug 511187 regarding the create-diagram-first workflows, which then would include create-diagram-first already in the new model wizard. There are however some aspects to consider here, e.g. if the user chooses a template which does *not* have the state-machine profile applied then it does not make sense to be able to create a state-machine diagram. And what should happen if the user selects both to create a structure diagram *and* a state-machine diagram? Should that create only one capsule (containing both diagram types) or should two separate capsules be created? I am not sure that allowing the creation of diagrams directly from the wizard is especially useful and probably just cause more confusion. But if this is a limitation in base Papyrus I guess there is not much we can do at this point in time. I suggest that we extend Bug 511187 to cover the aspects of creating the diagrams in the new project/model wizard. > > 3) The possibility of applying an additional profile is removed. Has this > > been made intentional? Not sure how important this is, but to be consistent > > with the base Papyrus new model wizard, the possibility of applying an > > additional profile (below the template drop-down menu) maybe should be kept > > as we had in 0.9. Not sure why and how this one went missing (I have a > > feeling that the widgets for selecting a profile has come and gone in the > > new model wizard a few times after the move to Oxygen). > > I do not have this issue in my version, I still have the apply profile from > workspace or registered profile. I don't have the profile application widget, neither in the tester setup installation based on the nightly builds, nor when I test Gerrit changes in my development environment. It shall be noted that it is only missing when I select the UML-RT architecture context. If I for example select the UML architecture context, then the profile selection widget is there. Selection the Profile context, the it does not exist either (someone probably have thought that you should not apply a profile on a profile, which is still a valid scenario). Strange that you still have it for the UML-RT context. If I only would have had this issue with the tester setup installation, but not in my run-time workbench, then one could have suspected some classic build.properties issue with missing stuff in the binary build. But now it is lacking in both scenarios for me... > > 7) The initial layout of a state-machine diagram is even worse than before, > > causing the scrollbar that we managed to remove to always appear. I guess > > this could be tracked by the already existing Bug 506265. The problem is > > that Bug 506265 is currently planned for Future so then we need to replan > > that for 1.0. Or at least fix the regression after the move to Oxygen to > > make sure that the initial placement is not partly outside the frame causing > > the scroll bar to appear (and causes the transition to not even be shown). > > To be investigated furthermore, I did not have the issue on quick testing. It shall be noted, that the issue with the elements being placed too far up, only happens on the first opening of the diagram. If you close the diagram, and reopen it again, then the elements are placed further down and the scrollbar does not appear. It is an issue only on the first automatic layout.
(In reply to Peter Cigehn from comment #67) > (In reply to Remi Schnekenburger from comment #65) > > (In reply to Peter Cigehn from comment #57) > > > 2) The new model wizard shows the UML-RT Capsule Structure Diagram and > > > UML-RT State Machine Diagram in the list of reprentation kinds. Bug 475805 > > > originally tracked the removal of these diagram from the new model wizard. > > > > This one will require an evolution on the wizard or the architecture > > framework metamodel, as the workaround cannot be used anymore. This will > > require some work in Papyrus, to allow Papyrus-RT to customize the wizard > > itelf, as for example a boolean in the representation kind definition to > > show or not in wizard or the wizard should check if the diagram can really > > be created or not (but not sure this would be easy to do). Another solution > > is also to let users create a capsule diagram, but selecting this should > > create an additional capsule, as done for the UML diagrams. (Same for state > > machine, this should create a capsule containing the state machine). > > Okay, maybe it is best to allow the creation of the diagrams, but as you > say, this would then also create the capsule (in which the diagram will be > contained). This would then be some kind of extension to the aspects tracked > by Bug 511187 regarding the create-diagram-first workflows, which then would > include create-diagram-first already in the new model wizard. > > There are however some aspects to consider here, e.g. if the user chooses a > template which does *not* have the state-machine profile applied then it > does not make sense to be able to create a state-machine diagram. And what > should happen if the user selects both to create a structure diagram *and* a > state-machine diagram? Should that create only one capsule (containing both > diagram types) or should two separate capsules be created? > > I am not sure that allowing the creation of diagrams directly from the > wizard is especially useful and probably just cause more confusion. But if > this is a limitation in base Papyrus I guess there is not much we can do at > this point in time. > > I suggest that we extend Bug 511187 to cover the aspects of creating the > diagrams in the new project/model wizard. I will try to push a patch for hiding some representation kinds from the wizards, which would avoid the questions about what happens if SM profile is not applied, etc. > > > 3) The possibility of applying an additional profile is removed. Has this > > > been made intentional? Not sure how important this is, but to be consistent > > > with the base Papyrus new model wizard, the possibility of applying an > > > additional profile (below the template drop-down menu) maybe should be kept > > > as we had in 0.9. Not sure why and how this one went missing (I have a > > > feeling that the widgets for selecting a profile has come and gone in the > > > new model wizard a few times after the move to Oxygen). > > > > I do not have this issue in my version, I still have the apply profile from > > workspace or registered profile. > > I don't have the profile application widget, neither in the tester setup > installation based on the nightly builds, nor when I test Gerrit changes in > my development environment. It shall be noted that it is only missing when I > select the UML-RT architecture context. If I for example select the UML > architecture context, then the profile selection widget is there. Selection > the Profile context, the it does not exist either (someone probably have > thought that you should not apply a profile on a profile, which is still a > valid scenario). > > Strange that you still have it for the UML-RT context. If I only would have > had this issue with the tester setup installation, but not in my run-time > workbench, then one could have suspected some classic build.properties issue > with missing stuff in the binary build. But now it is lacking in both > scenarios for me... Still surprising for me, as when I look to the code, I find this method: org.eclipse.papyrus.uml.diagram.wizards.pages.SelectRepresentationKindPage.createControl(Composite), which creates in one shot all composites for the page (name, representation kind, template, profile). > > > > 7) The initial layout of a state-machine diagram is even worse than before, > > > causing the scrollbar that we managed to remove to always appear. I guess > > > this could be tracked by the already existing Bug 506265. The problem is > > > that Bug 506265 is currently planned for Future so then we need to replan > > > that for 1.0. Or at least fix the regression after the move to Oxygen to > > > make sure that the initial placement is not partly outside the frame causing > > > the scroll bar to appear (and causes the transition to not even be shown). > > > > To be investigated furthermore, I did not have the issue on quick testing. > > It shall be noted, that the issue with the elements being placed too far up, > only happens on the first opening of the diagram. If you close the diagram, > and reopen it again, then the elements are placed further down and the > scrollbar does not appear. It is an issue only on the first automatic layout. ELK being installed or not perhaps?
(In reply to Remi Schnekenburger from comment #68) > (In reply to Peter Cigehn from comment #67) > > (In reply to Remi Schnekenburger from comment #65) > > > (In reply to Peter Cigehn from comment #57) > > > > 3) The possibility of applying an additional profile is removed. Has this > > > > been made intentional? Not sure how important this is, but to be consistent > > > > with the base Papyrus new model wizard, the possibility of applying an > > > > additional profile (below the template drop-down menu) maybe should be kept > > > > as we had in 0.9. Not sure why and how this one went missing (I have a > > > > feeling that the widgets for selecting a profile has come and gone in the > > > > new model wizard a few times after the move to Oxygen). > > > > > > I do not have this issue in my version, I still have the apply profile from > > > workspace or registered profile. > > > > I don't have the profile application widget, neither in the tester setup > > installation based on the nightly builds, nor when I test Gerrit changes in > > my development environment. It shall be noted that it is only missing when I > > select the UML-RT architecture context. If I for example select the UML > > architecture context, then the profile selection widget is there. Selection > > the Profile context, the it does not exist either (someone probably have > > thought that you should not apply a profile on a profile, which is still a > > valid scenario). > > > > Strange that you still have it for the UML-RT context. If I only would have > > had this issue with the tester setup installation, but not in my run-time > > workbench, then one could have suspected some classic build.properties issue > > with missing stuff in the binary build. But now it is lacking in both > > scenarios for me... > > Still surprising for me, as when I look to the code, I find this method: > org.eclipse.papyrus.uml.diagram.wizards.pages.SelectRepresentationKindPage. > createControl(Composite), which creates in one shot all composites for the > page (name, representation kind, template, profile). I tried resizing the new model/project wizard dialog, and then it appeared. So this seem to be some refresh/layout issue, where it is not shown initially, but if you just resize the dialog window slightly to trigger a refresh, then it appears. Both for the UML-RT context as well as the Profile context. Could it be related to the fact only the UML context have a full list of diagram types, whereras both UML-RT and Profile only have two diagram kinds causing a much shorter list. > > > > 7) The initial layout of a state-machine diagram is even worse than before, > > > > causing the scrollbar that we managed to remove to always appear. I guess > > > > this could be tracked by the already existing Bug 506265. The problem is > > > > that Bug 506265 is currently planned for Future so then we need to replan > > > > that for 1.0. Or at least fix the regression after the move to Oxygen to > > > > make sure that the initial placement is not partly outside the frame causing > > > > the scroll bar to appear (and causes the transition to not even be shown). > > > > > > To be investigated furthermore, I did not have the issue on quick testing. > > > > It shall be noted, that the issue with the elements being placed too far up, > > only happens on the first opening of the diagram. If you close the diagram, > > and reopen it again, then the elements are placed further down and the > > scrollbar does not appear. It is an issue only on the first automatic layout. > > ELK being installed or not perhaps? ELK is not installed by the tester setup anymore. Christian (temporarily?) removed the installation of the RSARTE import and the ELK stuff (two ELK related features). Should ELK be installed to get this working again?
Gerrit change https://git.eclipse.org/r/97315 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=8a88da77481d51f5d5ab1688d4f427f970708925
New Gerrit change created: https://git.eclipse.org/r/97341
(In reply to Peter Cigehn from comment #59) > Yet one more observation which I forgot to mention: > > 13) The "New Diagram" menu is empty again. We had the a similar regression > when moving from Mars to Neon, which was originally tracked with Bug 492359. > When the model have the UML-RT architecture context enabled, the "New > Diagram" menu is completely empty so you cannot create any ordinary UML > diagrams. Maybe this is intentional. This is then highly related to Bug > 511187 and the discussion about the create-diagrams-first work flows, > including creating a UML-RT Capsule Structure Diagram first (which then > would create the capsule and the diagram nested in it as usual). Gerrit 97341 provides a fix for this issue. The 2 viewpoints defined initially are: - basic(default): only UML-RT diagrams (capsule structure & state machine) - advanced (not by default): UML-RT diagrams & all UML diagrams. I added a new plugin so that advanced viewpoint can be removed from a simplified Papyrus-RT product. So to have access to advanced diagrams, you may activate advanced viewpoint.
(In reply to comment #65) > (In reply to Peter Cigehn from comment #57) > > > > 9) When establishing state-machine inheritance, the layout is not inherited > > by default, i.e. the diagram in the subclass does not have the "Follow > > superclass view" enabled for the elements, seemingly causing even more > > refresh issues for the layout inheritance in state-machine diagrams (have > > not tested yet if the same issue exist for structure diagrams). > > This may be perhaps better that Christian get an eye on it, he may know faster > than me the probable cause of this issue. The deferred layout of the diagram views created by the CanonicalEditPolicy on the initial opening of a diagram now is triggering the InheritanceEditPolicy to automatically disable "following" of the superclass view, because it thinks the user is moving state views deliberately. This didn't happen on Papyrus Neon. I suspect that the reason isn't that now we are getting layout performed by CanonicalEditPolicy that wasn't before, but rather that now it actually has to move these views because they are now initially created in the wrong location (whereas on Neon they were created in the right location, so layout didn't have to move them). I need to debug some more to verify this hypothesis. In any case, it will take some thinking to determine what we can do about it. It is frustrating that there is nothing in the GEF requests that can indicate that a request is initiated by user interaction, because that should be what decides whether to disconnect the view inheritance or not.
(In reply to Peter Cigehn from comment #69) > (In reply to Remi Schnekenburger from comment #68) > > (In reply to Peter Cigehn from comment #67) > > > (In reply to Remi Schnekenburger from comment #65) > > > > (In reply to Peter Cigehn from comment #57) > > > > > 3) The possibility of applying an additional profile is removed. Has this > > > > > been made intentional? Not sure how important this is, but to be consistent > > > > > with the base Papyrus new model wizard, the possibility of applying an > > > > > additional profile (below the template drop-down menu) maybe should be kept > > > > > as we had in 0.9. Not sure why and how this one went missing (I have a > > > > > feeling that the widgets for selecting a profile has come and gone in the > > > > > new model wizard a few times after the move to Oxygen). > > > > > > > > I do not have this issue in my version, I still have the apply profile from > > > > workspace or registered profile. > > > > > > I don't have the profile application widget, neither in the tester setup > > > installation based on the nightly builds, nor when I test Gerrit changes in > > > my development environment. It shall be noted that it is only missing when I > > > select the UML-RT architecture context. If I for example select the UML > > > architecture context, then the profile selection widget is there. Selection > > > the Profile context, the it does not exist either (someone probably have > > > thought that you should not apply a profile on a profile, which is still a > > > valid scenario). > > > > > > Strange that you still have it for the UML-RT context. If I only would have > > > had this issue with the tester setup installation, but not in my run-time > > > workbench, then one could have suspected some classic build.properties issue > > > with missing stuff in the binary build. But now it is lacking in both > > > scenarios for me... > > > > Still surprising for me, as when I look to the code, I find this method: > > org.eclipse.papyrus.uml.diagram.wizards.pages.SelectRepresentationKindPage. > > createControl(Composite), which creates in one shot all composites for the > > page (name, representation kind, template, profile). > > I tried resizing the new model/project wizard dialog, and then it appeared. > So this seem to be some refresh/layout issue, where it is not shown > initially, but if you just resize the dialog window slightly to trigger a > refresh, then it appears. Both for the UML-RT context as well as the Profile > context. Could it be related to the fact only the UML context have a full > list of diagram types, whereras both UML-RT and Profile only have two > diagram kinds causing a much shorter list. I don't know, for this one, I can't reproduce the issue. I tried to swith architecture context, go back and forward, but could not get the composite hidden. Can you enter a bug on Papyrus for this one, with screenshots? > > > > > 7) The initial layout of a state-machine diagram is even worse than before, > > > > > causing the scrollbar that we managed to remove to always appear. I guess > > > > > this could be tracked by the already existing Bug 506265. The problem is > > > > > that Bug 506265 is currently planned for Future so then we need to replan > > > > > that for 1.0. Or at least fix the regression after the move to Oxygen to > > > > > make sure that the initial placement is not partly outside the frame causing > > > > > the scroll bar to appear (and causes the transition to not even be shown). > > > > > > > > To be investigated furthermore, I did not have the issue on quick testing. > > > > > > It shall be noted, that the issue with the elements being placed too far up, > > > only happens on the first opening of the diagram. If you close the diagram, > > > and reopen it again, then the elements are placed further down and the > > > scrollbar does not appear. It is an issue only on the first automatic layout. > > > > ELK being installed or not perhaps? > > ELK is not installed by the tester setup anymore. Christian (temporarily?) > removed the installation of the RSARTE import and the ELK stuff (two ELK > related features). Should ELK be installed to get this working again? Not sure it should be there or not, but when diagram works for me, ELK is installed.
(In reply to Peter Cigehn from comment #58) > Some additional observations: > > 10) The general feeling is that the Oxygen version have some severe > performance issues. It feels that most operations take longer time, and some > specific operations is extremely slow, e.g. removing a model element takes a > very long time or bringing up a dialog in the properties view using the pen > edit button or the green + create button. Not sure if this specific to > Papyrus-RT or if this general "sluggishness" exist in base Papyrus. Feels > like some pretty fundamental issue (which does not seem related at all to > the size of the model, even the smallest "toy example" feels very sluggish > when working with it). I also have the performances issues on Papyrus (example, deleting a class in a simple model with a diagram and a class displayed in this diagram is quite slow, 2-3 seconds). But after a few actions, it seems performances were improving. Do you have the same feeling? > 11) The issue seen in bullet 9 (in Comment 57) can also be seen in the > structure diagram. When having established a generalization the structure > diagram layout in the subclass does not follow along the layout in the > superclass view. You have to explicitly select all elements (using Ctrl+A > for example) and then use the "Follow position in superclass view"-button in > the toolbar to enable that the layout in the subclass follows the superclass. Will be probably handled by Christian while investigating the issue on state machine > > 12) Redefining the type of a capsule part and port does not show the capsule > part or port label in bold (if I remember correctly some unit test that was > suppressed already had detected this regression). This is indeed a regression, I don't understand why bold was not working where all other parameters are working. An annotated failing test is covering that regression.
Gerrit change https://git.eclipse.org/r/97341 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=4577d42ced0df84df1050bd66847fd8a33ff424f
New Gerrit change created: https://git.eclipse.org/r/97353
New Gerrit change created: https://git.eclipse.org/r/97365
Gerrit change https://git.eclipse.org/r/97353 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=25fa249658695d86357e6c5f1ef7309718c0ba62
Gerrit change https://git.eclipse.org/r/97365 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=de7fc2f8fdac94b903ea9dfa65abba8161407a6f
(In reply to comment #80) > Gerrit change https://git.eclipse.org/r/97365 was merged to [master]. This fixes the inherited view "following" not being enabled for shapes in a new subclass diagram, from comment 57 item 9 and comment 58 item 11.
(In reply to Remi Schnekenburger from comment #74) > (In reply to Peter Cigehn from comment #69) > > (In reply to Remi Schnekenburger from comment #68) > > > (In reply to Peter Cigehn from comment #67) > > > > (In reply to Remi Schnekenburger from comment #65) > > > > > (In reply to Peter Cigehn from comment #57) > > > > > > 3) The possibility of applying an additional profile is removed. Has this > > > > > > been made intentional? Not sure how important this is, but to be consistent > > > > > > with the base Papyrus new model wizard, the possibility of applying an > > > > > > additional profile (below the template drop-down menu) maybe should be kept > > > > > > as we had in 0.9. Not sure why and how this one went missing (I have a > > > > > > feeling that the widgets for selecting a profile has come and gone in the > > > > > > new model wizard a few times after the move to Oxygen). > > > > > > > > > > I do not have this issue in my version, I still have the apply profile from > > > > > workspace or registered profile. > > > > > > > > I don't have the profile application widget, neither in the tester setup > > > > installation based on the nightly builds, nor when I test Gerrit changes in > > > > my development environment. It shall be noted that it is only missing when I > > > > select the UML-RT architecture context. If I for example select the UML > > > > architecture context, then the profile selection widget is there. Selection > > > > the Profile context, the it does not exist either (someone probably have > > > > thought that you should not apply a profile on a profile, which is still a > > > > valid scenario). > > > > > > > > Strange that you still have it for the UML-RT context. If I only would have > > > > had this issue with the tester setup installation, but not in my run-time > > > > workbench, then one could have suspected some classic build.properties issue > > > > with missing stuff in the binary build. But now it is lacking in both > > > > scenarios for me... > > > > > > Still surprising for me, as when I look to the code, I find this method: > > > org.eclipse.papyrus.uml.diagram.wizards.pages.SelectRepresentationKindPage. > > > createControl(Composite), which creates in one shot all composites for the > > > page (name, representation kind, template, profile). > > > > I tried resizing the new model/project wizard dialog, and then it appeared. > > So this seem to be some refresh/layout issue, where it is not shown > > initially, but if you just resize the dialog window slightly to trigger a > > refresh, then it appears. Both for the UML-RT context as well as the Profile > > context. Could it be related to the fact only the UML context have a full > > list of diagram types, whereras both UML-RT and Profile only have two > > diagram kinds causing a much shorter list. > > I don't know, for this one, I can't reproduce the issue. I tried to swith > architecture context, go back and forward, but could not get the composite > hidden. Can you enter a bug on Papyrus for this one, with screenshots? > I tested on my laptop at home, with Windows 10, and then I cannot see the issue. I have this issue at the office with a Windows 7 machine. So I guess this could be a platform specific issue. Anyway, I wrote Bug 516859 on base Papyrus to track this issue.
(In reply to Christian W. Damus from comment #81) > (In reply to comment #80) > > Gerrit change https://git.eclipse.org/r/97365 was merged to [master]. > > This fixes the inherited view "following" not being enabled for shapes in a > new subclass diagram, from comment 57 item 9 and comment 58 item 11. I can confirm after testing a bit in the latest Papyrus-RT build (#676) that this now works much better. The inherited view "following" are now enabled and the inherited layout now works more as it did for Neon (there are still refresh issues that can be seen, e.g. as tracked by Bug 514536, but the elements at least have their "follow" mode set correctly). What can be noted though is that the specific refresh issues in Bug 513811 seem to be "fixed" or at least behave much better. When following the steps to reproduce for that bug (including ensuring a model migration to Oxygen and activating the UML-RT achitecture context) the layout in the subclass follows the superclass nicely and there is no need to explicitly hit F5 to refresh. So the layout refresh issues seem to have improved for state-machine diagrams, but still remains as is for capsule structure diagrams.
One more element-type/new child menu issue: 15) When right-clicking on a port, there is a UML-RT new child menu available where you can create an attribute (which really does not make sense). This did not exist in Neon.
New Gerrit change created: https://git.eclipse.org/r/97459
Gerrit change https://git.eclipse.org/r/97459 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=8371fd7d3715c9c84594bfa56174584739be9552
> 1) additional . in the name of the model files Fixed > 2) UML-RT representation kinds back in wizard Needs evolution from Papyrus: bug 516943 opened on Papyrus. > 3) Additional profile application in wizard Tracked to Papyrus bug 516859. Issue on layout. > 4) translation files created for ecore, etc. Fixed in Papyrus bug 516712 (to be closed?). > 5) Model explorer expansion Wrong element types in configuration during migraton, fixed > 6) protocol message creation. Wrong element types in configuration during migraton, fixed > 7) Initial layout of state machine & scroll bar. More investigation needed, ELK interaction? > 8) CCE in state name edit part (ghost region left on deletion) Fixed in Papyrus, bug 516806 > 9) State Machine inheritance. Fixed (canonical edit policy) > 10) Performances Partially fixed, issue with Cache adapter. Mix between user model and tooling model in same resource set, should be fixed on Papyrus > 11) Capsule structure diagram inheritance Still present (same as State machine _ 9)? > 12) bold labels Known during migration, junit tests annotated as failing. Needs more investigation > 13) The "New Diagram" menu is empty again Fixed (need to activate Advanced viewpoint to have all papyrus UML diagrams available) > 14) decorator for showing if an element is redefined in a state-machine diagram does not refresh correctly. status unknown > 15) When right-clicking on a port, there is a UML-RT new child menu available where you can create an attribute (which really does not make sense). This did not exist in Neon. Should be trivial (additional advice on ports, to avoid Property creation)
> 16) Migration from Neon to Oxygen This is a "new" item in the list, but very important for current users. Currently, when opening a neon model, the context of the model is not the UML-RT one, which causes issue on creation. A patch exists (gerrit 96940), but only migrates the model if it detects the UML-RT language. So the diagrams themselves still have to be opened to be migrated to Oxygen, as the migration tool from Papyrus is lazy. So currently, even if the patch 96940 is applied, there is still something needed to handle the case for existing diagrams. A solution would be to force migration of all diagrams on first opening, or to provide a migration facility on models that would run on one shot all the required migrations. Also, legacy models migration tool may be upgraded to migrate to Papyrus-RT 1.0, to ensure a stable version. This is not required, as the models are supposed to be migrated by Papyrus-RT itself. This would only "clean" the Papyrus-RT history from incubation.
(In reply to Remi Schnekenburger from comment #87) > > 14) decorator for showing if an element is redefined in a state-machine diagram does not refresh correctly. > status unknown > I wrote Bug 517078 to track this separately. It was a bit tricky this case, since it only seem to appear for models newly created from scratch. The issue cannot be seen for models saved and then re-opened again, i.e. it was not possible to attach an example model to the bug, but the steps to reproduce has to be followed from "scratch".
I have two more issues which I feel could be related, since the involve transitions both of them 16) The derived name label, i.e. the name of the protocol message for the first trigger with a possible + as suffix if multiple triggers, of a transition is not shown in the model explorer. It is shown in the diagram as expected, but in the model explorer this is no longer shown as it did before. 17) The direct editor for a transition is no longer the simplified name-only editor, but seem to have regressed back to the more complex direct editor that we once had (seem to include editing of the effect and guard). Let's take them for a spin within the scope of this bug, before deciding if we should track these two issues with separate bugs or not.
I wrote Bug 517123 for a pretty fundamental issue where you get class cast exceptions and corrupt diagrams whenever deleting a port or capsule part.
(In reply to Remi Schnekenburger from comment #87) > > 5) Model explorer expansion > Wrong element types in configuration during migraton, fixed I still don't get this to work. When creating a protocol message in a "closed" protocol, the protocol is not expanded to select the created protocol message. So the direct edit of the newly created protocol message does not work. It only works if you manually "flip" the protocol open in the model explorer before creating a new protocol message.
New Gerrit change created: https://git.eclipse.org/r/97785
last patch is fixing comment 92.
Gerrit change https://git.eclipse.org/r/97785 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=f515a531b7ae33115011a9c630d5b3baa538d6c5
(In reply to Remi Schnekenburger from comment #94) > last patch is fixing comment 92. I have tested the latest Papyrus-RT build (#703), and indeed, the protocol now automatically expands to show, and activate the director editor for, the created protocol message as it did before.
New Gerrit change created: https://git.eclipse.org/r/97875
Gerrit change https://git.eclipse.org/r/97875 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=2b62b18f3ab813856e3eb729e6b425849a3a854b
> 16) The derived name label, i.e. the name of the protocol message for the first trigger with a possible + as suffix if multiple triggers, of a transition is not shown in the model explorer. It is shown in the diagram as expected, but in the model explorer this is no longer shown as it did before. > 17) The direct editor for a transition is no longer the simplified name-only editor, but seem to have regressed back to the more complex direct editor that we once had (seem to include editing of the effect and guard). Both of them are fixed with last patch. So the content of this bug should now be "reduced" to the content of dependent bugs, if I did not miss anything else?
(In reply to Remi Schnekenburger from comment #99) > Both of them are fixed with last patch. So the content of this bug should > now be "reduced" to the content of dependent bugs, if I did not miss > anything else? Yes, most of the issues raised in this bug have been resolved, tracked separately, or have a disabled unit test, e.g. the missing bold label. But one thing I feel is still not resolved and that is this about being able to create an attribute as a child of port. This is a regression on the Oxygen track, and this issue did not exist before. I suggest that we fix that one as part of this bug, and then try to close this one and start tracking any additional issues separately. For the Papyrus bugs that this bug depends on, I suggest that we create separate tracking bugs for Papyrus-RT, so that we can close this one. This means that we should have tracking bugs for Bug 516859 and Bug 516943. For the other remaining depends on, Bug 517078 and Bug 517123, we can "decouple" them from this bug and simply track them separately. It should really not be needed to make them block this one from being closed.
(In reply to Remi Schnekenburger from comment #99) > > 16) The derived name label, i.e. the name of the protocol message for the first trigger with a possible + as suffix if multiple triggers, of a transition is not shown in the model explorer. It is shown in the diagram as expected, but in the model explorer this is no longer shown as it did before. > > > 17) The direct editor for a transition is no longer the simplified name-only editor, but seem to have regressed back to the more complex direct editor that we once had (seem to include editing of the effect and guard). > > Both of them are fixed with last patch. I have tested the latest Papyrus-RT build (#705) and both these now works as they used to. The derived name label is shown in the model explorer, and the simple named based only director editor is used again in the state-machine diagram.
New Gerrit change created: https://git.eclipse.org/r/98145
Gerrit change https://git.eclipse.org/r/98145 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=021e029d0bbeb94f7dd9a6d9131f9686e1b4e107
New Gerrit change created: https://git.eclipse.org/r/98219
Gerrit change https://git.eclipse.org/r/98219 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=f442382d78299444925db4235f4daf4086b8c36b
(In reply to Eclipse Genie from comment #105) > Gerrit change https://git.eclipse.org/r/98219 was merged to [master]. > Commit: > http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/ > ?id=f442382d78299444925db4235f4daf4086b8c36b Last remaining issue in the scope of this bug has been fixed, it is not possible to create property (or sub-kind of elements) inside Ports. A JUnit test was also added to check we have no regressions later on.
(In reply to Remi Schnekenburger from comment #106) > (In reply to Eclipse Genie from comment #105) > > Gerrit change https://git.eclipse.org/r/98219 was merged to [master]. > > Commit: > > http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/ > > ?id=f442382d78299444925db4235f4daf4086b8c36b > > Last remaining issue in the scope of this bug has been fixed, it is not > possible to create property (or sub-kind of elements) inside Ports. > A JUnit test was also added to check we have no regressions later on. I have tested this in the latest Papyrus-RT build (#728) and it is no longer possible to create an attribute as child of a port. With that the issues tracked by this bug should all be resolved, and any remaining issues shall be tracked separately. I suggest that we put this one into state resolved fixed, possibly removing the three remaining depends on. As indicated in Comment 100 the two of these depending Papyrus probably should have separate trackings bugs for Papyrus-RT. The remaining Papyrus-RT only can simply be left "decoupled" and tracked separately. Then we can finally close this one... :)
(In reply to Peter Cigehn from comment #107) > (In reply to Remi Schnekenburger from comment #106) > > (In reply to Eclipse Genie from comment #105) > > > Gerrit change https://git.eclipse.org/r/98219 was merged to [master]. > > > Commit: > > > http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/ > > > ?id=f442382d78299444925db4235f4daf4086b8c36b > > > > Last remaining issue in the scope of this bug has been fixed, it is not > > possible to create property (or sub-kind of elements) inside Ports. > > A JUnit test was also added to check we have no regressions later on. > > I have tested this in the latest Papyrus-RT build (#728) and it is no longer > possible to create an attribute as child of a port. With that the issues > tracked by this bug should all be resolved, and any remaining issues shall > be tracked separately. > > I suggest that we put this one into state resolved fixed, possibly removing > the three remaining depends on. As indicated in Comment 100 the two of these > depending Papyrus probably should have separate trackings bugs for > Papyrus-RT. The remaining Papyrus-RT only can simply be left "decoupled" and > tracked separately. > > Then we can finally close this one... :) I wrote Bug 517485 to track Bug 516943 regarding the filtering of representation kinds in the new project/model wizard. Bug 516859 regarding the profile application widget not always being visible already had a separate tracking Bug 516890. And finally I simply "decoupled" Bug 517123 and only have it as a "See Also" reference. That means that this bug no longer have any still open "depends on" bugs and we should not be able to resolve it as fixed. Or do you see that we have anything left to do before being able to do so, Rémi?
No, that bug can be finally closed! Thanks to the team for support during migration :-)
Verified to be fixed in the latest Papyrus-RT build (#733). Papyrus-RT are now based on Oxygen. Several regression issues have been resolved as part of this bug, and remaining issues will be tracked separately. I leave this in state verified fixed, and Charles can close (or reopen if needed).
Closing. New issues related to the move to Oxygen to be handled on an individual basis.
New Gerrit change created: https://git.eclipse.org/r/99182
Gerrit change https://git.eclipse.org/r/99182 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=98b83679fac0b68ee458c1b5708aa66180a0164a
