Bugzilla – Full Text Bug Listing
| Summary: | [Core] AnsiCLibrary not available as a registered library | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] Papyrus-rt | Reporter: | Peter Cigehn <peter.cigehn> | ||||
| Component: | core | Assignee: | Christian Damus <give.a.damus> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | ansgar.radermacher, charles, papyrus-bugs, rschnekenburger | ||||
| Version: | 0.7.2 | ||||||
| Target Milestone: | 0.8.0 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| See Also: |
https://git.eclipse.org/r/82302 https://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=8d98588b9370ce74f80498794a7f2b0da7055e5b https://git.eclipse.org/r/82395 https://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=96c44f552451e5d01ff2c3aa41c7cdea1b0883ed |
||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Peter Cigehn
I'm assigning this to v0.8 because I got tripped by this exact scenario and I would think users may experience this if moving from Papyrus-RT v0.7. Peter, as author: I believe this has been addressed by other bugs. At least, I am no longer seeing this problem. Is it still an issue for you? Created attachment 264341 [details]
Screen shot showing list of available libraries in Paprus-RT
I just tested in the latest build of Papyrus-RT, based on the tester Oomph setup file, and the issue is still there. Following the steps to reproduce, the AnsiCLibrary is still not available for selection in the list of libraries/packages.
The screen shot shows the list of available libraries in which one can see that AnsiCLibrary is missing. In contrast, it can be seen that the UML-RT Runtime Services is available.
(In reply to Peter Cigehn from comment #3) > Created attachment 264341 [details] > Screen shot showing list of available libraries in Paprus-RT > > I just tested in the latest build of Papyrus-RT, based on the tester Oomph > setup file, and the issue is still there. Following the steps to reproduce, > the AnsiCLibrary is still not available for selection in the list of > libraries/packages. > > The screen shot shows the list of available libraries in which one can see > that AnsiCLibrary is missing. In contrast, it can be seen that the UML-RT > Runtime Services is available. Thanks Peter. Do you see a need to do this without setting the language for the model? What is interesting is that if I create a new model, set it language to C++, close it and re-open it, the AnsiCLibrary appears. Disregarding for now the bug that one needs to close and open the model for AnsiCLibrary to appear, would you see that as a better workflow? (In reply to Charles Rivet from comment #4) > Do you see a need to do this without setting the language for the model? No sure what you mean. But using a package import should not replace the need for setting the default language of the model. The default language for the model is used for other UI aspects, e.g. what elements should be made available on the popup menus. So setting the default language of the model (which preferably should be made already at model creation using selections in the new model wizard) should be done anyway. So yes, I could see a need where a user want to have an explicit package import of the AnsiCLibrary, even though the a default language has been assigned and the default language framework makes that library to get loaded and made available in the UI. > > What is interesting is that if I create a new model, set it language to C++, > close it and re-open it, the AnsiCLibrary appears. Yes, it appears as loaded into the resource set, but you do not have the explicit package import. This is the same for other situations where you have established some kind of relation to a (leaf) model element in another model, and the lazy loading ensures that the other model also appears in the model explorer. You do not need an explicit package (or element) import for this either. But I guess some users would like to make the dependency more clear by adding an explicit package (or possibly element) import. > > Disregarding for now the bug that one needs to close and open the model for > AnsiCLibrary to appear, would you see that as a better workflow? I am not sure that I see this as a workflow aspect. It is more an aspect that the user wants to make it more explicitly, and semantically, clear that the model is using the AnsiCLibrary by having an explicit package import. This of course is completely optional, and should not be required or something that you need to do for improving the workflow. From a workflow perspective, the UI that we provide for directly selecting the primitive type from the popup when creating for example a protocol message parameter is better, or the content assist in type fields where you simply can user the keyborad to enter the name of a primitive type in the library associated with the default language assigned to the model. I also see this as an consistency aspect: Why should the UML-RT Runtime Services Library be available for selection (see the attached screen shot), but not the Ansi C Library? That just does not make sense either. Make sure that all libraries are available for those users that wants to establish a package import to both the UML-RT Runtime Services Library and/or the Ansi C Library, for whatever reason that user have for doing so. (In reply to Peter Cigehn from comment #5) > (In reply to Charles Rivet from comment #4) > > Do you see a need to do this without setting the language for the model? > > No sure what you mean. But using a package import should not replace the > need for setting the default language of the model. I was rather wondering whether setting the language for the model obviates the need to explicitly set the package import(s) associated with that language. From your description below, this is not the case. This was, however, not apparent from the behaviour of the tool (it still looks like setting the language resulted in a the import of the library). >The default language for > the model is used for other UI aspects, e.g. what elements should be made > available on the popup menus. So setting the default language of the model > (which preferably should be made already at model creation using selections > in the new model wizard) should be done anyway. When you say The default language for the model is used for other UI aspects", do you mean this in an exclusive way (i.e., not, for example, for the import of the required libraries)? > > So yes, I could see a need where a user want to have an explicit package > import of the AnsiCLibrary, even though the a default language has been > assigned and the default language framework makes that library to get loaded > and made available in the UI. I am interpreting that statement as that the language framework dynamically loads that library on startup and that there is no modification to the model file. Is that correct? > > > > > What is interesting is that if I create a new model, set it language to C++, > > close it and re-open it, the AnsiCLibrary appears. > > Yes, it appears as loaded into the resource set, but you do not have the > explicit package import. This is the same for other situations where you > have established some kind of relation to a (leaf) model element in another > model, and the lazy loading ensures that the other model also appears in the > model explorer. You do not need an explicit package (or element) import for > this either. But I guess some users would like to make the dependency more > clear by adding an explicit package (or possibly element) import. Do you guess or do you know? That is the difference between a potential future requirement or one that needs to be addressed now. > > > > > Disregarding for now the bug that one needs to close and open the model for > > AnsiCLibrary to appear, would you see that as a better workflow? > > I am not sure that I see this as a workflow aspect. It is more an aspect > that the user wants to make it more explicitly, and semantically, clear that > the model is using the AnsiCLibrary by having an explicit package import. > This of course is completely optional, and should not be required or > something that you need to do for improving the workflow. However, our documentation, and especially tutorials, will have to describe workflows, so we need to understand them. Your description has thus far indicated two potential paths, which is useful in helping our users make the right choices. > > From a workflow perspective, the UI that we provide for directly selecting > the primitive type from the popup when creating for example a protocol > message parameter is better, or the content assist in type fields where you > simply can user the keyborad to enter the name of a primitive type in the > library associated with the default language assigned to the model. Marking as NEW and adding the documentation tag. (In reply to Peter Cigehn from comment #6) > I also see this as an consistency aspect: Why should the UML-RT Runtime > Services Library be available for selection (see the attached screen shot), > but not the Ansi C Library? That just does not make sense either. Make sure > that all libraries are available for those users that wants to establish a > package import to both the UML-RT Runtime Services Library and/or the Ansi C > Library, for whatever reason that user have for doing so. I agree that the UML-RT Runtime Services library shall be available for all UML-RT models (as long as it can removed by DSMLs based on UML-RT) and that the AnsiCLibrary shall be available for all UML-RT models that define their language as C/C++. However, I was under the impression that the language framework would take care of that in an explicit manner. Your previous post explained the actual behaviour and corrected my understanding and I believe this is now just a matter of documentation. (In reply to Charles Rivet from comment #7) > (In reply to Peter Cigehn from comment #5) > > (In reply to Charles Rivet from comment #4) > > > Do you see a need to do this without setting the language for the model? > > > > No sure what you mean. But using a package import should not replace the > > need for setting the default language of the model. > > I was rather wondering whether setting the language for the model obviates > the need to explicitly set the package import(s) associated with that > language. From your description below, this is not the case. This was, > however, not apparent from the behaviour of the tool (it still looks like > setting the language resulted in a the import of the library). I feel that this is getting rather confusing, since we are discussing some many things at the same time. Yes, setting the default language of the current model should really be the only thing that the user really needs to do. The package import that I am referring to should be completely optional and only be used whenever a user wants to have an explicit modeled relation to the library using a UML package import. I really think that we must separate the difference between UML package/element import versus simply loading the library into the resource set. What you have been seeing is that the library is loaded, it is not imported (using a UML package or element import). > >The default language for > > the model is used for other UI aspects, e.g. what elements should be made > > available on the popup menus. So setting the default language of the model > > (which preferably should be made already at model creation using selections > > in the new model wizard) should be done anyway. > > When you say The default language for the model is used for other UI > aspects", do you mean this in an exclusive way (i.e., not, for example, for > the import of the required libraries)? What I mean here is that the tooling of the UI should only consider the default language of the assigned to the current model, when filling in the list of primitive types, or system protocols, in different menus. Please see my followings in Bug 477730 related to this, i.e. Bug 477730 Comment 10 and Bug 477730 Comment 11. So yes, the tooling should (in my opinion) only use the API of the default language framework to retrieve the set of primitive types, system protocols, base protocol, and system classes, and disregard from any package imports. As can be seen from Bug 477730 Comment 11 this could actually just be completely incorrect in any future multi model/multi language scenario. > > > > > So yes, I could see a need where a user want to have an explicit package > > import of the AnsiCLibrary, even though the a default language has been > > assigned and the default language framework makes that library to get loaded > > and made available in the UI. > > I am interpreting that statement as that the language framework dynamically > loads that library on startup and that there is no modification to the model > file. Is that correct? That is my understanding. Strange though that it only loads the Ansi C Library and not the run-time model library. I would not really expect the default language framework to load either of them at this point in time (especially if you have a completely empty model). So I really do not think that we can expect that this is some intentional behavior. But what I was mainly referring to when it comes to "made available in the UI", was more the aspect of making it available on popup menus, e.g when creating protocol message parameters or ports (in which case the system protocols shall be included when we get those Bugzillas related to the creation of SAPs fixed). > > > > > > > > > What is interesting is that if I create a new model, set it language to C++, > > > close it and re-open it, the AnsiCLibrary appears. > > > > Yes, it appears as loaded into the resource set, but you do not have the > > explicit package import. This is the same for other situations where you > > have established some kind of relation to a (leaf) model element in another > > model, and the lazy loading ensures that the other model also appears in the > > model explorer. You do not need an explicit package (or element) import for > > this either. But I guess some users would like to make the dependency more > > clear by adding an explicit package (or possibly element) import. > > Do you guess or do you know? That is the difference between a potential > future requirement or one that needs to be addressed now. I'm guessing since this is a question of methodology and how you normally work with package import and how you work with multi-models in general. Personally I have not made up my mind when it comes to this, since Papyrus and Papyrus-RT have a rather different behavior when it comes to multi-model support than what the legacy tooling have. So I am guessing that there are users that would like to have them. In the legacy tooling you get these package imports (to the primitive types library and the run-time model library) explicitly when creating a new UML-RT model. But they are optional and the user can choose to remove the package imports if they are found to be cluttering the model. And as I stated in Comment 6, I could simply make the argument that this Bugzilla is simply about being consistent with the run-time model library. > > > > > > Disregarding for now the bug that one needs to close and open the model for > > > AnsiCLibrary to appear, would you see that as a better workflow? > > > > I am not sure that I see this as a workflow aspect. It is more an aspect > > that the user wants to make it more explicitly, and semantically, clear that > > the model is using the AnsiCLibrary by having an explicit package import. > > This of course is completely optional, and should not be required or > > something that you need to do for improving the workflow. > > However, our documentation, and especially tutorials, will have to describe > workflows, so we need to understand them. Your description has thus far > indicated two potential paths, which is useful in helping our users make the > right choices. From a tutorial/documentation perspective, I would simply only talk about the setting the default language of the model. These package imports should as I said be purely optional for the "advanced" user that wants to make the dependencies to the libraries more explicit. As I see it, there should not really be a need to mention this in any tutorial/documentation, at least not for the "normal" users. New Gerrit change created: https://git.eclipse.org/r/82302 Gerrit change https://git.eclipse.org/r/82302 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=8d98588b9370ce74f80498794a7f2b0da7055e5b (In reply to Eclipse Genie from comment #11) > Gerrit change https://git.eclipse.org/r/82302 was merged to [master]. I understood from the conversation in this bug that the problem is not that the ANSI C types library is not registered as a library for the package import wizard (it seems we don't want it to be so registered) but only that the library is not loaded immediately when the C++ language is set on the model. This patch fixes that problem. (In reply to Christian W. Damus from comment #12) > (In reply to Eclipse Genie from comment #11) > > Gerrit change https://git.eclipse.org/r/82302 was merged to [master]. > > I understood from the conversation in this bug that the problem is not that > the ANSI C types library is not registered as a library for the package > import wizard (it seems we don't want it to be so registered) but only that > the library is not loaded immediately when the C++ language is set on the > model. > > This patch fixes that problem. No, this Bugzilla is still about making the Ansi C Library availble for selection when you want to create an explicit package import to it. Yes, there are also the aspect of ensuring that it gets loaded when you set the language to C++. But this aspect about loading the related libraries actually is more about the run-time model library, since that library does not get loaded at all, which I feel is very inconsistent. This is however tracked by Bug 502547. As I see it, this fix that ensure that the library AnsiCLibrary gets loaded already when you set the language, is part of the scope of Bug 502547, to ensure consistency that all related libraries, i.e. both the AnsiCLibrary and the UMLRT-RTS library, gets loaded both directly when you set the C++ language as well as when you open the model. This Bugzilla is still only related to the fact that the AnsiCLibrary shall consistently be registered as the UMLRT-RTS (UML-RT Runtime Services) library is available for selection when using Import > Import Registered Packages. Sorry about all the confusion that has arised fromt the earlier discussions in this Bugzilla. Considering also the new Bug 502964, I would just like to make it clear that the registration of the AnsiCLibrary probably should be made in the C++ default language plugin. (In reply to Peter Cigehn from comment #13) > > No, this Bugzilla is still about making the Ansi C Library availble for > selection when you want to create an explicit package import to it. > > ... > > Considering also the new Bug 502964, I would just like to make it clear that > the registration of the AnsiCLibrary probably should be made in the C++ > default language plugin. Okay, but surely the registration of this model library is already provided by the Papyrus Designer component? Users of Designer for C++ code generation (not RT-oriented) will need to have this library. We wouldn't want to add a second registration in Papyrus-RT to confuse users with two apparently indistinguishable entries in the package import dialog. I'm adding Ansgar to cc for comment on the Designer registration of this library. Is there some bundle that we should just add to the default Papyrus-RT installation configuration that provides this library registration? (In reply to Christian W. Damus from comment #14) > Okay, but surely the registration of this model library is already provided > by the Papyrus Designer component? Users of Designer for C++ code > generation (not RT-oriented) will need to have this library. We wouldn't > want to add a second registration in Papyrus-RT to confuse users with two > apparently indistinguishable entries in the package import dialog. As I have understood it, the AnsiCLibrary is packaged in a plugin which does not perform any registration of the profile, to ensure that it is completely "stand-alone" and can be used in any way needed (without getting it registered if that is not wanted). And thus, if we don't register it specifically/explicitly in Papyrus-RT, then it will not show up (as the case is right now, and as shown by the attached screen shot in Comment 3). This aspect of getting double registrations I assume will only happen if you install both Designer and Papyrus-RT at the same time, which I doubt ever will happen since they conceptually are two completely different ways of generating C++ code. I guess we always can ensure that the label with which the library is being registered indicates its use in the context of Papyrus-RT to distinguish it from it being used in the context of Designer (for those that for some reason will install both at the same time). Designer registers the ANSI C library in a separate plugin (oepd.languages.cpp.library.ui), so no registration happens right now. Papyrus-RT needs to register the library itself or declare a dependency to the designer plug-in registering it. The former would indeed imply a double registration if both features are installed, the latter that the registration name is fixed to "AnsiCLibrary" (without any prefix/postfix indicating the usage within designer). I also think that the double registration is not really a problem. (In reply to Peter Cigehn from comment #15) > As I have understood it, the AnsiCLibrary is packaged in a plugin which does > not perform any registration of the profile, to ensure that it is completely > "stand-alone" and can be used in any way needed (without getting it > registered if that is not wanted). yes > And thus, if we don't register it specifically/explicitly in Papyrus-RT, > then it will not show up (as the case is right now, and as shown by the > attached screen shot in Comment 3). yes > This aspect of getting double registrations I assume will only happen if you > install both Designer and Papyrus-RT at the same time, which I doubt ever > will happen since they conceptually are two completely different ways of > generating C++ code. > > I guess we always can ensure that the label with which the library is being > registered indicates its use in the context of Papyrus-RT to distinguish it > from it being used in the context of Designer (for those that for some > reason will install both at the same time). New Gerrit change created: https://git.eclipse.org/r/82395 (In reply to Eclipse Genie from comment #17) > New Gerrit change created: https://git.eclipse.org/r/82395 This change adds registration of the C types library from Papyrus Designer. Gerrit change https://git.eclipse.org/r/82395 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=96c44f552451e5d01ff2c3aa41c7cdea1b0883ed (In reply to Eclipse Genie from comment #19) > Gerrit change https://git.eclipse.org/r/82395 was merged to [master]. > Commit: > http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/ > ?id=96c44f552451e5d01ff2c3aa41c7cdea1b0883ed I've checked the latest Papyrus-RT build and the ANSI C Library is now available for selection when using Import > Import Registered Package... I put this one into resolved/verified/closed fixed. Verified to be fixed in the latest Papyrus-RT build. The ANSI C Library is now available as a registered package. The related aspects regarding the loading of libraries by the default language framework related to the C++ default language is tracked separately by Bug 502547. Setting as verified fixed. Closing as verified fixed. |