Community
Participate
Working Groups
In the Papyrus-RT tutorial it is currently described a lot of steps regarding applying additional profiles and importing additional libraries. See https://wiki.eclipse.org/Papyrus-RT/User_Guide/Getting_Started and specifically the sections "Add profiles to model" and "Add UML-RT Runtime Services Library": https://wiki.eclipse.org/Papyrus-RT/User_Guide/Getting_Started#Add_profiles_the_model https://wiki.eclipse.org/Papyrus-RT/User_Guide/Getting_Started#Add_UML-RT_Runtime_Services_Library The profiles and libraries should be made available as options already in the new model wizard using templates (and possibly using additional preferences) to avoid these extra manual steps. Currently when selecting the UML-RT DSML on the first page of the new model wizard, a model with the base UML-RT profile applied is created which is reasonable. Then a number of different templates shall be provided to create increasingly "advanced" models: 1) Only the optional state machine profile applied (To be able to do analysis behavior modeling, but with no need for detailed code generation) 2) Both the optional state machine profile and the C++ property sets profile applied, including package imports of the UML-RT Services Library model library and a library for the C++ primitive types (To be able to perform detailed behavior modeling including controlling the generated C++ code) Regarding which library to use for C++ primitive types this needs to be decided as part of Bug 478797. To avoid confusion for the user, only one library for primitive types shall be imported, and thus it shall not be needed to import the UMLPrimitiveTypes library as currently described in the tutorial.
I guess that this is highly relevant to the default language framework, and the possibility of selecting a default language when creating a model. If that framework has the possibility of keeping track of a number of related libraries, e.g. the C++ primitive types library, the run-time model library and so on, then the import of these libraries should be made based on the selected default language (potentially the import shall not be needed if the default language framework ensures that the tooling only relies on the selected default language when providing the selection of primitive types, creation of SAPs based on system protocols from the run-time model library and so on).
Regarding the default language framework as mentioned in Comment 1, see Bug 487187.
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. This could at least be seen as a first step towards providing additional choices/templates for different kinds of UML-RT models. I suggest that we break out this as a separate (smaller) Bugzilla and let it block this one.
(In reply to Peter Cigehn from comment #3) > 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. This could at least be seen as a first step towards > providing additional choices/templates for different kinds of UML-RT models. > I suggest that we break out this as a separate (smaller) Bugzilla and let it > block this one. I wrote Bug 502557 to track the specific aspect of selecting/setting the default language already in the new model wizard.
New Gerrit change created: https://git.eclipse.org/r/88033
I do not think that this bug should be blocked on Bug 502557. This bug is to address multiple templates whereas Bug 502557 is geared at implementing a way to set the default language. Also, Bug 502557 is apparently blocked by Papyrus functionality (inflexibility in modifying the dialog), that would greatly delay the release of this aspect, that I would consider important for a 0.9/1.0 release of Papyrus-RT. I would propose that, to solve this issue in the v0.9/1.0 timeframe, we provide a solution that includes three templates that would cover most needs in the short term: 1) UML-RT for structural modelling, i.e., no state machine nor default language 2) UML-RT Basic, i.e., (1) above plus the state machine profile 3) UML-RT for C++, i.e., (2) above plus the C++ profile applied (I would probably reverse the order above to target new Papyrus-RT evaluators migrating from legacy tooling - but that can be discussed) The use of these three templates could easily be explained in the release notes and demonstrated in the Getting Started guide (and video) for the release. Once we have this (and/or in parallel) we could then ask the Papyrus team to make the new project wizard more flexible so that the Papyrus-RT needs are addressed and we could then implement a "New Papyrus-RT project" wizard that is better suited for our users once the Papyrus infrascture supports our needs, without blocking our current release effort. This approach would help ensure that for a 1.0 release in the February time frame, we enable our target users to easily create the models they need.
(In reply to Charles Rivet from comment #6) > I do not think that this bug should be blocked on Bug 502557. > > This bug is to address multiple templates whereas Bug 502557 is geared at > implementing a way to set the default language. > > Also, Bug 502557 is apparently blocked by Papyrus functionality > (inflexibility in modifying the dialog), that would greatly delay the > release of this aspect, that I would consider important for a 0.9/1.0 > release of Papyrus-RT. > > I would propose that, to solve this issue in the v0.9/1.0 timeframe, we > provide a solution that includes three templates that would cover most needs > in the short term: > > 1) UML-RT for structural modelling, i.e., no state machine nor default > language > 2) UML-RT Basic, i.e., (1) above plus the state machine profile > 3) UML-RT for C++, i.e., (2) above plus the C++ profile applied > > (I would probably reverse the order above to target new Papyrus-RT > evaluators migrating from legacy tooling - but that can be discussed) > > The use of these three templates could easily be explained in the release > notes and demonstrated in the Getting Started guide (and video) for the > release. > > Once we have this (and/or in parallel) we could then ask the Papyrus team to > make the new project wizard more flexible so that the Papyrus-RT needs are > addressed and we could then implement a "New Papyrus-RT project" wizard that > is better suited for our users once the Papyrus infrascture supports our > needs, without blocking our current release effort. > > This approach would help ensure that for a 1.0 release in the February time > frame, we enable our target users to easily create the models they need. As commented in the other bug, I would go directly to a new wizard specific for Papyrus-RT, as done in SysML. Its implementation could inherit partially/totally from the current Papyrus generic one. This would allow the required customization for Papyrus-RT, and would be much more user friendly, displaying only required information and removing superfluous one.
(In reply to Remi Schnekenburger from comment #7) > (In reply to Charles Rivet from comment #6) > > I do not think that this bug should be blocked on Bug 502557. > > > > This bug is to address multiple templates whereas Bug 502557 is geared at > > implementing a way to set the default language. > > > > Also, Bug 502557 is apparently blocked by Papyrus functionality > > (inflexibility in modifying the dialog), that would greatly delay the > > release of this aspect, that I would consider important for a 0.9/1.0 > > release of Papyrus-RT. > > > > I would propose that, to solve this issue in the v0.9/1.0 timeframe, we > > provide a solution that includes three templates that would cover most needs > > in the short term: > > > > 1) UML-RT for structural modelling, i.e., no state machine nor default > > language > > 2) UML-RT Basic, i.e., (1) above plus the state machine profile > > 3) UML-RT for C++, i.e., (2) above plus the C++ profile applied > > > > (I would probably reverse the order above to target new Papyrus-RT > > evaluators migrating from legacy tooling - but that can be discussed) > > > > The use of these three templates could easily be explained in the release > > notes and demonstrated in the Getting Started guide (and video) for the > > release. > > > > Once we have this (and/or in parallel) we could then ask the Papyrus team to > > make the new project wizard more flexible so that the Papyrus-RT needs are > > addressed and we could then implement a "New Papyrus-RT project" wizard that > > is better suited for our users once the Papyrus infrascture supports our > > needs, without blocking our current release effort. > > > > This approach would help ensure that for a 1.0 release in the February time > > frame, we enable our target users to easily create the models they need. > > As commented in the other bug, I would go directly to a new wizard specific > for Papyrus-RT, as done in SysML. Its implementation could inherit > partially/totally from the current Papyrus generic one. This would allow the > required customization for Papyrus-RT, and would be much more user friendly, > displaying only required information and removing superfluous one. Thanks Rémi. As I stated in the other bug, considering our current bug load for v0.9/1.0, could your proposed solution be implemented in time (i.e., before mid-February)?
https://git.eclipse.org/r/#/c/88303/
New Gerrit change created: https://git.eclipse.org/r/88593
Removing the dependency on bug 502557. Templates can provide a default language already set, so there is no direct need for being able to set this via the UI in the wizard.
Gerrit change https://git.eclipse.org/r/88593 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=28f38b180797c905170b74077346790965f75f14
Verified to be fixed in the latest Papyrus-RT build. The three templates proposed in Comment 6 a now available for selection in the new project/model wizard. The templates provides a default language already set, i.e. 1 and 2 have "No language" set and 3 have "C++" set covering also the basic needs of Bug 502557.
Closing as verified fixed.
