Community
Participate
Working Groups
When moving over to the Oxygen track, a regression occurred where it was possible again to create UML-RT structure and state-machine diagrams directly in the wizard. Since it really does not make sense to be able to do so (apart from that it does not even work), the possibility of selecting them in the new project/model wizard shall be removed. Originally this was tracked by Bug 475805. See Bug 514322 Comment 68 for more regarding this issue. This needs better extensibility in base Papyrus so this bug tracks an improvement needed in base Papyrus according to Bug 516943 to be able to filter the representation kinds in the new project/model wizard.
To clarify: If the user selects to create any of the diagrams, UML-RT Capsule Structure Diagram or UML-RT State Machine Diagram, from the new project/model wizard, then an error dialog confusingly pops up briefly during the model creation, and then disappears. And the resulting model does not have any diagrams. All this will be a rather confusing user experience. So something probably needs to be done regarding this for 1.0. Not sure what can be done if a fix in Papyrus to improve the extensibility does not make its way into Oxygen.0. I suggest that this bug at least is planned for 1.0 due to the bad user experience it will give.
Assigned to 1.0 - will move if Papyrus will not fix in 1.0.
(In reply to Charles Rivet from comment #2) > Assigned to 1.0 - will move if Papyrus will not fix in 1.0. I would say that if this is not fixed in Papyrus, we probably need to look at a work-around locally in Papyrus-RT, in the same way as we had a work-around for this issue on the Oxygen track. I suggest to keep this bug for 1.0 disregarding if the bug in Papyrus gets fixed or not (which seem unlikely since RC4 is on Wednesday) to let it track if it is possible to implement some workaround.
(In reply to Peter Cigehn from comment #3) > (In reply to Charles Rivet from comment #2) > > Assigned to 1.0 - will move if Papyrus will not fix in 1.0. > > I would say that if this is not fixed in Papyrus, we probably need to look > at a work-around locally in Papyrus-RT, in the same way as we had a > work-around for this issue on the Oxygen track. I suggest to keep this bug > for 1.0 disregarding if the bug in Papyrus gets fixed or not (which seem > unlikely since RC4 is on Wednesday) to let it track if it is possible to > implement some workaround. We are looking for a workaround, but we are not confident that this would be feasible with the current infrastructure.
(In reply to Charles Rivet from comment #4) > (In reply to Peter Cigehn from comment #3) > > (In reply to Charles Rivet from comment #2) > > > Assigned to 1.0 - will move if Papyrus will not fix in 1.0. > > > > I would say that if this is not fixed in Papyrus, we probably need to look > > at a work-around locally in Papyrus-RT, in the same way as we had a > > work-around for this issue on the Oxygen track. I suggest to keep this bug > > for 1.0 disregarding if the bug in Papyrus gets fixed or not (which seem > > unlikely since RC4 is on Wednesday) to let it track if it is possible to > > implement some workaround. > > We are looking for a workaround, but we are not confident that this would be > feasible with the current infrastructure. No, I guess that was what Rémi already concluded initially when he initially looked at this as part of Bug 514322 and thus he wrote 516943. So a work around probably requires that go that extra mile... If Christian have time, maybe he can take a look and see if he can come up with something.
As explained in bug#516943 there seems to be no simple hack to work around this issue in Oxygen.
(In reply to Young-Soo Roh from comment #6) > As explained in bug#516943 there seems to be no simple hack to work around > this issue in Oxygen. I just talked to Young-Soo about this and my understanding is that, given the way the Papyrus base wizard is built, the only workaround would be to reimplement the functionality in a brand new, independent wizard for Papyrus-RT. Because much the current implementation is "private," reuse would be of the "copy and modify" variety. This is not a viable workaround given the effort required for this implementation in v1.0 and that this work would then need to be thrown away as soon as the Papyrus bug is fixed (which we are hoping in the Oxygen.1 timeframe). The team's recommendation is to leave it as is, to document this issue in the documentation (release note), and to fix it properly in the next version (1.0.1, currently planned for shortly after Oxygen.1. Moving to 1.0.1
Assigning to charles to update the release note and the getting started tutorial to explicitly mention _not_ selecting the diagrams
(In reply to Charles Rivet from comment #8) > Assigning to charles to update the release note and the getting started > tutorial to explicitly mention _not_ selecting the diagrams I guess, if this is explicitly mentioned, then it is good to mention this about create-diagrams-first approach as tracked by Bug 511187 as well (depending on what will be done with that bug for 1.0) and to point out that the primary principle of Papyrus-RT is that these diagrams are automatically created when the capsule and the state-machine are created. So it is probably a good thing to discuss these principles in general when mentioning that it does not really make sense to create the diagrams directly from the new model model/project wizard (even if they mistakenly are available for selection).
(In reply to Peter Cigehn from comment #9) > (In reply to Charles Rivet from comment #8) > > Assigning to charles to update the release note and the getting started > > tutorial to explicitly mention _not_ selecting the diagrams > > I guess, if this is explicitly mentioned, then it is good to mention this > about create-diagrams-first approach as tracked by Bug 511187 as well > (depending on what will be done with that bug for 1.0) and to point out that > the primary principle of Papyrus-RT is that these diagrams are automatically > created when the capsule and the state-machine are created. So it is > probably a good thing to discuss these principles in general when mentioning > that it does not really make sense to create the diagrams directly from the > new model model/project wizard (even if they mistakenly are available for > selection). +1
Mass changing all 1.0.1 bugs to target milestone 1.0.2, because Bug 520039 depends on Bug 526168 which depends on Bug 526167 which modifies plugin MANIFEST files and therefore requires a new service version number in accordance to the guidelines at https://wiki.eclipse.org/Version_Numbering#When_to_change_the_service_segment. Hence the solution to these bugs must be merged as a new version (1.0.1) and therefore all old 1.0.1 bugs should become 1.0.2.
