Community
Participate
Working Groups
Now when the core support provided by the default language framework is in place, it would be nice at least to get the support in the new model wizard to get support for setting the default language, e.g. C++, already during model creation. Bug 478799 tracks in more general terms the improvements to the new model wizard, where support for additional templates and choices should be possible in the new model wizard for creating different kinds of UML-RT models. This Bugzilla focus on the core aspect of ensuring that the user can make a selection of the default language for the new model already at model creation.
I am not sure that I agree that this should be Future. The reason why I broke it out of its "parent" Bugzilla was to make it possible to get in in either 0.9 or at least in 1.0. Since setting the default language for a model will be rather fundamental the work flow for setting it needs to be improved and best is of course is if that is done already at model creation.
Moved to 0.9 and we can discuss further when we do the 0.9 planning.
Rémi, could you please comment on this? Should this be moved to future?
No, I do agree this is important for user work flow. This is a basic block for users, and this can be something easy for a newcomer as committer. I will keep it currently in the backlog, and will assign it as soon as a newcomer comes to the project. Otherwise, it can be fixed late in the process developement of the 0.9, as this is not a critical feature.
I assume that we need to put a selection drop box for available languages. Where would be the best spot to add this? e.g, above the template selection?
(In reply to Young-Soo Roh from comment #6) > I assume that we need to put a selection drop box for available languages. > Where would be the best spot to add this? e.g, above the template selection? Papyrus model wizard is flexible to add additional widgets on the pages. Not sure how to allow user to select default languages. Need more investigation but any advice is welcome.
(In reply to Young-Soo Roh from comment #7) > (In reply to Young-Soo Roh from comment #6) > > I assume that we need to put a selection drop box for available languages. > > Where would be the best spot to add this? e.g, above the template selection? > > Papyrus model wizard is flexible to add additional widgets on the pages. Not > sure how to allow user to select default languages. Need more investigation > but any advice is welcome. not flexible. :)
See comment in Bug 478799: https://bugs.eclipse.org/bugs/show_bug.cgi?id=478799#c6 regarding this bug blocking that work.
(In reply to Charles Rivet from comment #9) > See comment in Bug 478799: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=478799#c6 regarding this bug > blocking that work. From the content of that comment, this bug should be moved to future (1.0.1?).
When dealing about this task, I was thinking about implementing a new specific wizard, as it is done by SysML extension. There is a "new SysML Model" and "new SysML project", which allows to simplify / extend the wizard itself. That means that you could for example remove the diagram page (as there are no diagrams available for Papyrus-RT), and you can customize/override the page to create more content, as for example default language selection. And in a simplified Papyrus-RT environment, we could imagine to remove the display of the generic Papyrus wizards for model and projects, and only display the specific Papyrus-RT ones.
(In reply to Remi Schnekenburger from comment #11) > When dealing about this task, I was thinking about implementing a new > specific wizard, as it is done by SysML extension. > > There is a "new SysML Model" and "new SysML project", which allows to > simplify / extend the wizard itself. > That means that you could for example remove the diagram page (as there are > no diagrams available for Papyrus-RT), and you can customize/override the > page to create more content, as for example default language selection. > And in a simplified Papyrus-RT environment, we could imagine to remove the > display of the generic Papyrus wizards for model and projects, and only > display the specific Papyrus-RT ones. Thanks Rémi. Considering our current bug load for v0.9/1.0, could your proposed solution be implemented in time (i.e., before mid-February)?
(In reply to Charles Rivet from comment #12) > (In reply to Remi Schnekenburger from comment #11) > > When dealing about this task, I was thinking about implementing a new > > specific wizard, as it is done by SysML extension. > > > > There is a "new SysML Model" and "new SysML project", which allows to > > simplify / extend the wizard itself. > > That means that you could for example remove the diagram page (as there are > > no diagrams available for Papyrus-RT), and you can customize/override the > > page to create more content, as for example default language selection. > > And in a simplified Papyrus-RT environment, we could imagine to remove the > > display of the generic Papyrus wizards for model and projects, and only > > display the specific Papyrus-RT ones. > > Thanks Rémi. Considering our current bug load for v0.9/1.0, could your > proposed solution be implemented in time (i.e., before mid-February)? I won't be able to ;-) . But that's the kind of task that someone willing to start contributing to the project can do. This does not require deep knowledge in Papyrus internals, and there is already an example ;) More precisely, at least 2, as SysML 1.4 proposes some extensions also. See gui/sysml1.4ui in the sysml dedicated repo of the Papyrus project.
(In reply to Charles Rivet from comment #10) > From the content of that comment, this bug should be moved to future > (1.0.1?). As I already indicated in Comment 1, I personally think that this kind of functionality is fundamental to get into 1.0 release, since so much of our tooling implementations relies an a default language being properly set, and the main reason why I broke out this specific functionality from Bug 497289 was to ensure that we could get this functionality in before having additional templates (which I feel is something that could come later). Sure, if we can solve the setting of the default language using templates, i.e. the template already have the default language set, then that is of course a possible solution also. I would just to make it clear, that my personal opinion is that we *must* have the setting of a default language for a create model in place for 1.0. If that is solved by a new specific wizard with some dropdown list or other UI elements, or if it is solved by providing some appropriate templates (with the default language "pre-set" in the template), for example based on the templates as proposed in Bug 478799 Comment 6, then with the addition that template 3 should have default language C++ set as default. Not sure if the intention is that template 2 should have "No language" or "C++" set.
(In reply to Peter Cigehn from comment #14) Thanks, Peter. Young-Soo is looking into the solution proposed by Rémi. We should know more today.
New Gerrit change created: https://git.eclipse.org/r/88303
My solution does not use templates. Added new wizard page for UMLRT settings after the diagram kind page. (Initially I tried to use the diagram kind page instead of creating a new page but it is not easy since base wizard and pages are not implemented in a way that they can be extended by sub-classes.) In the new page you can select your preference for state machine and default language settings. The settings in the page are remembered so it may help users to easily create same models without actually going into sub pages.
Moving to 0.9 as this is considere blocking by a major user.
(In reply to Young-Soo Roh from comment #17) > My solution does not use templates. > > Added new wizard page for UMLRT settings after the diagram kind page. > (Initially I tried to use the diagram kind page instead of creating a new > page but it is not easy since base wizard and pages are not implemented in a > way that they can be extended by sub-classes.) > > In the new page you can select your preference for state machine and default > language settings. > > The settings in the page are remembered so it may help users to easily > create same models without actually going into sub pages. I quickly tested the the Gerrit change. At first I could not understand why I could not see any additional page in the wizard, until I realized that it was a completely new wizard. You have to first select File > New > Other... and then browse to the Papyrus folder and select "Papyrus UML RealTime Project" (or "Papyrus UML RealTime Model"). I was using simply New > Papyrus Project... as I always am. If we are going to use this approach, then this probably requires us to make a custom Papyrus-RT perspective (which we probably need to do anyway, especially when the code snippet view in Bug 494288 is introduced), to make these two wizards available directly on the File > New menu without having to use File > New > Other... I am not sure either what to think when it comes to extensibility, e.g. when making a DSML on top of UML-RT. Will they be forced into making their completely own wizard? I do know that some experiments already have been made by adding additional DSML choices in the standard wizard (this page is now completely gone). And what about users that mixes UML-RT and ordinary UML models, e.g. when doing documentation kind of models. Also, since we now keep all the "bad" stuff that we maybe would like to improve (as discussed in Bug 482923 Comment 27 and a few following comments), like the default naming of the root element and the page with diagrams and templates, which you always have to skip over. Since the setting of the default language, as discussed, is pretty fundamental, I would really prefer to have that one much earlier, and possibly even should have been shown to the user before the user can press finish, possibly making the choice of default language to be mandatory (at least to make the user aware of that it is important to make that selection). I am really not sure in which direction to go here... :( I have some more comments regarding terminology and spelling but I leave that for now until we understand in which direction to go.
Please see comments inline. > > I quickly tested the the Gerrit change. At first I could not understand why > I could not see any additional page in the wizard, until I realized that it > was a completely new wizard. You have to first select File > New > Other... > and then browse to the Papyrus folder and select "Papyrus UML RealTime > Project" (or "Papyrus UML RealTime Model"). I was using simply New > Papyrus > Project... as I always am. If we are going to use this approach, then this > probably requires us to make a custom Papyrus-RT perspective (which we > probably need to do anyway, especially when the code snippet view in Bug > 494288 is introduced), to make these two wizards available directly on the > File > New menu without having to use File > New > Other... You need to refresh the perspective by Window -> Perspective -> Reset Perspective then it will be available from File > New. New users will see it right away. > > I am not sure either what to think when it comes to extensibility, e.g. when > making a DSML on top of UML-RT. Will they be forced into making their > completely own wizard? I do know that some experiments already have been > made by adding additional DSML choices in the standard wizard (this page is > now completely gone). And what about users that mixes UML-RT and ordinary > UML models, e.g. when doing documentation kind of models. We can make our wizard extensible or we can ask base Papyrus wizard to be extensible later but I don't think we would have enough time for this release. > > Also, since we now keep all the "bad" stuff that we maybe would like to > improve (as discussed in Bug 482923 Comment 27 and a few following > comments), like the default naming of the root element and the page with > diagrams and templates, which you always have to skip over. > > Since the setting of the default language, as discussed, is pretty > fundamental, I would really prefer to have that one much earlier, and > possibly even should have been shown to the user before the user can press > finish, possibly making the choice of default language to be mandatory (at > least to make the user aware of that it is important to make that selection). > At this point, we cannot put UMLRT settings page before the template page until base CreateModelWizard is updated so that it allows users to add pages in certain order. The only thing I can do is that I can force users to select a default language if never been selected before. > I am really not sure in which direction to go here... :( > > I have some more comments regarding terminology and spelling but I leave > that for now until we understand in which direction to go.
Updated gerrit. Wizard requires language selection before it can finish.
(In reply to Young-Soo Roh from comment #20) > > You need to refresh the perspective by Window -> Perspective -> Reset > Perspective then it will be available from File > New. New users will see it > right away. > That was not that obvious. But this is at least much better. Personally I am still not sure what to think about this though. I would really like to hear other's opinion about this approach. I think that it will be a bit confusing for new users to find two separate sets of menu choices, and risk is always that they will pick the wrong one... > > We can make our wizard extensible or we can ask base Papyrus wizard to be > extensible later but I don't think we would have enough time for this > release. If we go for the proposed solution, with two separate sets of menu choices, where you also can access the original wizard, then maybe the aspect of extensibility that I raised is not relevant since you still have the possibility of adding your own DSML to that standard Papyrus wizard. > > At this point, we cannot put UMLRT settings page before the template page > until base CreateModelWizard is updated so that it allows users to add pages > in certain order. The only thing I can do is that I can force users to > select a default language if never been selected before. > Okay, if we are limited in what order the pages comes, and just have to accept that the additional page always comes last, then I am not fully sure about how to solve this about "forcing" the user to make a conscious decision regarding default language. My initial comment about this was really under the assumption that the language decision could be made already on some first, or at least earlier page of the wizard. I am not sure what to think about "forcing" the user to the last page of the wizard. This in combination with this how that selection seem to be remembered in the current workspace, at least if you choose C++ as default language, makes this a bit confusing since you are only forced to the last page the first time when you select C++, but not if you select "No language". But maybe this is a good thing, I am not sure. I would really like someone else to take a look at this and hear their view as well. But if I assume that this is the direction we will go I have some more detailed comments: 1) The name of the menu choices/wizard currently are named "Papyrus UML RealTime Project" respectively "Papyrus UML RealTime Model". According the naming principles that we concluded in Bug 491235, it should be a hyphen in Real-Time. But I would actually propose to use the shorter form "UML-RT" instead of "UML Real-Time" instead, i.e. "Papyrus UML-RT Project" and "Papyrus UML-RT Model". This goes for both the menu choice and the title in the wizard. 2) The phrasing regarding state machines could be improved to make it more clear to the user what it is about. The header maybe could be "Select support for behavior modeling" and the label next to the check box maybe could be "Apply the optional UML-RT StateMachines profile" 3) The header for the language selection could also be improved. First of all we have a long time outstanding issue here regarding terminology, which I have discussed with numerous people off-line (Charles, Rémi). Since the word "language" is rather overloaded we need to make it a bit more specific, e.g. you have the "Languages" section on the Welcome page in the model editor which deals more with "modeling language", i.e. UML-RT and UML. What we are referring to here is the "action language", or possibly "target language". In earlier discussions it was concluded that "action language" is a better term (since we very well might have "target agnostic action languages", e.g. Alf). It has also been discussed that the label on the UML-RT sub-tab "Language" should be "Default Action Language", but this unfortunately did not happen. Not sure if we easily can include that change in the scope of this work, but since they are highly related, I would propose so. The proposal would then be to name the header to "Select default action language" (skip the part with "to apply" which just confuses). At the same time, update the label next to the corresponding field on the UML-RT sub-tab "Language" to "Default action language" (the name of the sub-tab I guess we still keep short as only "Language"). 4) I assume that the list of default action languages are collected automatically in some way from all registered default languages. It has been discussed to add a "Natural Language" action language, which only have the run-time model library associated with it (no primitive types library as the C++ language have). The "No Language" action language does not have any libraries or profiles associated with it. Any such additions of additional languages of course needs to be picked up automatically by the wizard. With that said, I am still not fully sure if this is "good enough" for the 0.9/1.0 release or not. Let's hear someone else view also. I still think that Charles proposal to add some templates, according to Bug 478799 Comment 6, should be considered (even if we add this additional page in the wizard). Those templates should then already have the correct action languages assigned, and the correct profiles applied. If that is done then I guess we need to consider if the user already have selected a template or not, in which case this about "forcing" the user to the last page to make the language setting really is needed. It must of course also be considered that the user already have selected a profile where the state-machines profile already is applied to avoid getting the profile applied twice.
Please see comments inline. I think Remi should take a look at this as well. (In reply to Peter Cigehn from comment #22) > (In reply to Young-Soo Roh from comment #20) > > > > You need to refresh the perspective by Window -> Perspective -> Reset > > Perspective then it will be available from File > New. New users will see it > > right away. > > > > That was not that obvious. But this is at least much better. Personally I am > still not sure what to think about this though. I would really like to hear > other's opinion about this approach. I think that it will be a bit confusing > for new users to find two separate sets of menu choices, and risk is always > that they will pick the wrong one... > One possible solution to this is to add UMLRT perspective. Without our own UMLRT wizard the only solution that we can provide is through templates. Template selection is optional so this could confuse users as well. In addition you have to repeat the process of selecting a template every time you use wizard to create the model. I implemented this way since Remi's suggestion of following wizard extension done in SysML. Let's see if what Remi says. > > > > We can make our wizard extensible or we can ask base Papyrus wizard to be > > extensible later but I don't think we would have enough time for this > > release. > > If we go for the proposed solution, with two separate sets of menu choices, > where you also can access the original wizard, then maybe the aspect of > extensibility that I raised is not relevant since you still have the > possibility of adding your own DSML to that standard Papyrus wizard. > Again we need to determine if we need to use our own wizard (with possible UMLRT perspective to hide default one) or use default wizard by extending it which is not possible until such extensibility is provided by the base. > > > > At this point, we cannot put UMLRT settings page before the template page > > until base CreateModelWizard is updated so that it allows users to add pages > > in certain order. The only thing I can do is that I can force users to > > select a default language if never been selected before. > > > > Okay, if we are limited in what order the pages comes, and just have to > accept that the additional page always comes last, then I am not fully sure > about how to solve this about "forcing" the user to make a conscious > decision regarding default language. My initial comment about this was > really under the assumption that the language decision could be made already > on some first, or at least earlier page of the wizard. > > I am not sure what to think about "forcing" the user to the last page of the > wizard. This in combination with this how that selection seem to be > remembered in the current workspace, at least if you choose C++ as default > language, makes this a bit confusing since you are only forced to the last > page the first time when you select C++, but not if you select "No > language". But maybe this is a good thing, I am not sure. > Users are forced to select default language if no previous selection was made or No Language option was selected. We can reorder the page if base wizard makes simple change of making a page variable protected not private. Again this is change in the base so not sure if it is something that can be done soon. > I would really like someone else to take a look at this and hear their view > as well. > > But if I assume that this is the direction we will go I have some more > detailed comments: > > 1) The name of the menu choices/wizard currently are named "Papyrus UML > RealTime Project" respectively "Papyrus UML RealTime Model". According the > naming principles that we concluded in Bug 491235, it should be a hyphen in > Real-Time. But I would actually propose to use the shorter form "UML-RT" > instead of "UML Real-Time" instead, i.e. "Papyrus UML-RT Project" and > "Papyrus UML-RT Model". This goes for both the menu choice and the title in > the wizard. > > 2) The phrasing regarding state machines could be improved to make it more > clear to the user what it is about. The header maybe could be "Select > support for behavior modeling" and the label next to the check box maybe > could be "Apply the optional UML-RT StateMachines profile" > > 3) The header for the language selection could also be improved. First of > all we have a long time outstanding issue here regarding terminology, which > I have discussed with numerous people off-line (Charles, Rémi). Since the > word "language" is rather overloaded we need to make it a bit more specific, > e.g. you have the "Languages" section on the Welcome page in the model > editor which deals more with "modeling language", i.e. UML-RT and UML. What > we are referring to here is the "action language", or possibly "target > language". In earlier discussions it was concluded that "action language" is > a better term (since we very well might have "target agnostic action > languages", e.g. Alf). It has also been discussed that the label on the > UML-RT sub-tab "Language" should be "Default Action Language", but this > unfortunately did not happen. Not sure if we easily can include that change > in the scope of this work, but since they are highly related, I would > propose so. The proposal would then be to name the header to "Select default > action language" (skip the part with "to apply" which just confuses). At the > same time, update the label next to the corresponding field on the UML-RT > sub-tab "Language" to "Default action language" (the name of the sub-tab I > guess we still keep short as only "Language"). > > 4) I assume that the list of default action languages are collected > automatically in some way from all registered default languages. It has been > discussed to add a "Natural Language" action language, which only have the > run-time model library associated with it (no primitive types library as the > C++ language have). The "No Language" action language does not have any > libraries or profiles associated with it. Any such additions of additional > languages of course needs to be picked up automatically by the wizard. > > > With that said, I am still not fully sure if this is "good enough" for the > 0.9/1.0 release or not. Let's hear someone else view also. > > I still think that Charles proposal to add some templates, according to Bug > 478799 Comment 6, should be considered (even if we add this additional page > in the wizard). Those templates should then already have the correct action > languages assigned, and the correct profiles applied. If that is done then I > guess we need to consider if the user already have selected a template or > not, in which case this about "forcing" the user to the last page to make > the language setting really is needed. It must of course also be considered > that the user already have selected a profile where the state-machines > profile already is applied to avoid getting the profile applied twice.
(In reply to Peter Cigehn from comment #22) > If that is done then I guess we need to consider if the user already have > selected a template or not, in which case this about "forcing" the user to > the last page to make the language setting really is needed. I have a bad habit of missing some vital "not". The sentence above should of course end with "...to make the language setting is really not needed."
(In reply to Peter Cigehn from comment #24) > (In reply to Peter Cigehn from comment #22) > > If that is done then I guess we need to consider if the user already have > > selected a template or not, in which case this about "forcing" the user to > > the last page to make the language setting really is needed. > > I have a bad habit of missing some vital "not". The sentence above should of > course end with "...to make the language setting is really not needed." By the way, we have no way of know if the template is selected nor force default template selection until base wizard and template selection page is modified.
(In reply to Young-Soo Roh from comment #25) > (In reply to Peter Cigehn from comment #24) > > (In reply to Peter Cigehn from comment #22) > > > If that is done then I guess we need to consider if the user already have > > > selected a template or not, in which case this about "forcing" the user to > > > the last page to make the language setting really is needed. > > > > I have a bad habit of missing some vital "not". The sentence above should of > > course end with "...to make the language setting is really not needed." > > By the way, we have no way of know if the template is selected nor force > default template selection until base wizard and template selection page is > modified. One advantage of using our own wizard is that we can completely remove dependency to base wizard so we can fully customize pages by adding or removing pages we don't need.
(In reply to Young-Soo Roh from comment #26) > > One advantage of using our own wizard is that we can completely remove > dependency to base wizard so we can fully customize pages by adding or > removing pages we don't need. Yes, making a completely own wizard of course have that benefit. As discussed (rather off topic) in Bug 482923 Comment 27 (and forward), there are definitively things that can be made better in this wizard, e.g. always naming the root element the same as the model file itself. If I compare with the legacy tooling for example, the wizard is mainly driven by templates, i.e. the user selects a template first from a list of categories where each category has its list of templates, including good template descriptions, something that the base Papyrus wizard does not handle very well with a single drop down menu for selecting templates. And the legacy tooling wizard don't have an explicit field for the name of the root element, but always names it the same as the model file, which makes much more sense than having this default name of "RootElement" which is rather annoying. Then actually the selected template "drives" the rest of the pages of the wizard, so that each template can have its own set of pages in the wizard. The more I have been thinking about ut, I really like this approach... In the legacy tooling, the selection of default action language is only made implicitly by selecting an appropriate template, e.g. a Capsule C++ Model or a plain Capsule Model. But I cannot make the call for going all the way and implement a completely new wizard from scratch...
(In reply to Peter Cigehn from comment #27) > (In reply to Young-Soo Roh from comment #26) > > > > One advantage of using our own wizard is that we can completely remove > > dependency to base wizard so we can fully customize pages by adding or > > removing pages we don't need. > > Yes, making a completely own wizard of course have that benefit. As > discussed (rather off topic) in Bug 482923 Comment 27 (and forward), there > are definitively things that can be made better in this wizard, e.g. always > naming the root element the same as the model file itself. > > If I compare with the legacy tooling for example, the wizard is mainly > driven by templates, i.e. the user selects a template first from a list of > categories where each category has its list of templates, including good > template descriptions, something that the base Papyrus wizard does not > handle very well with a single drop down menu for selecting templates. And > the legacy tooling wizard don't have an explicit field for the name of the > root element, but always names it the same as the model file, which makes > much more sense than having this default name of "RootElement" which is > rather annoying. > > Then actually the selected template "drives" the rest of the pages of the > wizard, so that each template can have its own set of pages in the wizard. > The more I have been thinking about ut, I really like this approach... > > In the legacy tooling, the selection of default action language is only made > implicitly by selecting an appropriate template, e.g. a Capsule C++ Model or > a plain Capsule Model. > > But I cannot make the call for going all the way and implement a completely > new wizard from scratch... It would probably take a few days to fully customize the page by implementing our own creation wizard. It is something that Charles should decide.
I was approved to implement our own wizard base so that we can customize the second page and get rid of the third one. This will allow us to customize any pages to suit our needs. I will upload new gerrit once the changes are ready.
(In reply to Young-Soo Roh from comment #29) > I was approved to implement our own wizard base so that we can customize the > second page and get rid of the third one. This will allow us to customize > any pages to suit our needs. I will upload new gerrit once the changes are > ready. In which direction do we then aim for going related to the creation of Papyrus-RT specific perspective? Will this wizard completely replace the current wizard from base Papyrus, or will we still have two separate sets of menu choices/wizards? I think it is important to consider use cases where Papyrus-RT are being used in combination with ordinary UML modeling, creation of profiles, and the creation of DSMLs on top of UML-RT, i.e. the first page of the wizard where you currently make the selection between UML model, UML profile, or any DSML that has been installed for the DSML section in the wizard probably should still be there to support these use cases. The previous prototype proposal with double sets of wizards had removed this pages. Will the new wizard also have this page removed?
(In reply to Peter Cigehn from comment #30) > (In reply to Young-Soo Roh from comment #29) > > I was approved to implement our own wizard base so that we can customize the > > second page and get rid of the third one. This will allow us to customize > > any pages to suit our needs. I will upload new gerrit once the changes are > > ready. > > In which direction do we then aim for going related to the creation of > Papyrus-RT specific perspective? Will this wizard completely replace the > current wizard from base Papyrus, or will we still have two separate sets of > menu choices/wizards? > > I think it is important to consider use cases where Papyrus-RT are being > used in combination with ordinary UML modeling, creation of profiles, and > the creation of DSMLs on top of UML-RT, i.e. the first page of the wizard > where you currently make the selection between UML model, UML profile, or > any DSML that has been installed for the DSML section in the wizard probably > should still be there to support these use cases. The previous prototype > proposal with double sets of wizards had removed this pages. Will the new > wizard also have this page removed? Sorry for jumping in so late in the discussion but I fully agree with Peter that it must be possible to easily adapt the wizard to DSMLs on top of UML-RT. If you disable the old/current wizard in Papyrus-RT how would you create e.g. a new profile? Again, it is important that we don't see Papyrus-RT as the top of DSML tool chain, it will be extended and thus we need a simple way to customize the Papyrus-RT new wizard for new DSMLs on top of it. Currently I'm extending the 'old' wizard in Papyrus-RT. How will this work affect this? Another thing, I'm not sure about forcing the user to select a default language, not all UML-RT models are using the language at all and it must be possible to disable that page all together. (I guess this would work fine as long as I can use the old wizard)
Peter, Patrik, At this point, in order to meet the requirements listed by Peter, both from specifying them and from rejecting alternatives, we simply cannot do it with the current Papyrus capabilities without creating our own, standalone wizard ( by extending and modifying large chunks of Papyrus code ). Contact Young-Soo if you have more questions about the actual implementation. Note that the simplest short term solution - templates in the UML-RT wizrds - was not deemed adequate. (would that change if this was released as v0.9 and not 1.0?) I would suggest you review this bug's comments to see the options that have been proposed (and abandoned). If you still need the base Papyrus wizard, we can keep it so that there are two "New project" wizards available (one for Papyrus and one for Papyrus-RT , but then that would become confusing for new Papyrus-RT users...especially since they could create UML-RT models using either (but get slightly different results). Yes, that duality can be addressed, to a certain extent, through documentation, but I would consider it to be far from ideal. For this particular issue, our plan is to: 1(a). Implement our own, Papyrus-RT specific new project wizard, as indicated above. 1(b). Create bug(s) on Papyrus to improve the extensibility of their New Project wizard. However, we have no guarantees as to when this could be done and it would certainly not be in time for the Ericsson-requested February release (I would suspect Oxygen at the earliest). An alternative could be to move the current wizard from Papyrus to Papyrus-RT (i.e., Papyrus-RT would "own" that source code in its repository). See Bug 510380. 2. When (if?) the extensibility we need has been added to the Papyrus New Project Wizard (or we control the code for that capability), we use it to more properly add/modify the Papyrus-RT new project creation experience. This solution not only provides us with desirable capabilities for the Papyrus-RT DSML, but also for any DSML based on Papyrus or Papyrus-RT. Note that one of the requirements for any Papyrus product managed by the Papyrus IC is composability. As such, it must be possible to have "Papyrus UML" and Papyrus-RT coexist in the same workbench. (In reply to Peter Cigehn from comment #30) >In which direction do we then aim for going related to the creation of >Papyrus-RT specific perspective? The creation of a Papyrus-RT perspective is not being considered as part of this bug. >Will this wizard completely replace the >current wizard from base Papyrus, or will we still have two separate sets of >menu choices/wizards? Addressed above > >I think it is important to consider use cases where Papyrus-RT are being used >in combination with ordinary UML modeling, creation of profiles, and the >creation of DSMLs on top of UML-RT, i.e. the first page of the wizard where you >currently make the selection between UML model, UML profile, or any DSML that >has been installed for the DSML section in the wizard probably should still be >there to support these use cases. The previous prototype proposal with double >sets of wizards had removed this pages. Will the new wizard also have this page >removed? I believe this is addressed by the Papyrus IC's composability requirement and by the plan, above. It would also be interesting to understand how you have built your own wizard(s) in the current context. This may help us in what we are currently doing, especially if you have solutions for problems we have met. (In reply to Patrik Nandorf from comment #31) >Another thing, I'm not sure about forcing the user to select a default >language, not all UML-RT models are using the language at all and it must be >possible to disable that page all together. (I guess this would work fine as >long as I can use the old wizard) There would be a "no default language" to address this concern.
Quick update on plan...I seem to have copied the wrong one (I prefer using real text editor...) See changes inline below using CriticMArkup. (In reply to Charles Rivet from comment #32) [...snip...] > > For this particular issue, our plan is to: > [Deleted: {-- 1(a). Implement our own, Papyrus-RT specific new project wizard, as indicated above.--} ] [Inserted: {++ 1(a) Implement the template-based solution previously presented ++} > > 1(b). Create bug(s) on Papyrus to improve the extensibility of their New > Project wizard. However, we have no guarantees as to when this could be done > and it would certainly not be in time for the Ericsson-requested February > release (I would suspect Oxygen at the earliest). An alternative could be to > move the current wizard from Papyrus to Papyrus-RT (i.e., Papyrus-RT would > "own" that source code in its repository). See Bug 510380. > > 2. When (if?) the extensibility we need has been added to the Papyrus New > Project Wizard (or we control the code for that capability), we use it to > more properly add/modify the Papyrus-RT new project creation experience. > > This solution not only provides us with desirable capabilities for the > Papyrus-RT DSML, but also for any DSML based on Papyrus or Papyrus-RT. > > Note that one of the requirements for any Papyrus product managed by the > Papyrus IC is composability. As such, it must be possible to have "Papyrus > UML" and Papyrus-RT coexist in the same workbench. [...snip...]
Moving to 1.0.0 as per plan shown in https://bugs.eclipse.org/bugs/show_bug.cgi?id=502557#c33. Papyrus bug scheduled for Oxygen (3.0.0).
Please also change status back to NEW when assigning back to the inbox. It is so confusing with bugs in status ASSIGNED but with the "Assigned To" field set to the project inbox. What does that really mean?
