Community
Participate
Working Groups
Papyrus-RT 0.8 (almost) The default-language contribution for the C++ language is defined in the org.eclipse.papyrusrt.umlrt.cpp bundle in the CPP component. It provides two critical resources to a UML-RT/C++ model: * the ANSI C primitive types library * the C++ Properties profile The types library former is hosted in a Designer bundle that is a dependency of the org.eclipse.papyrusrt.umlrt.cpp bundle. That is okay. The profile is hosted in a Codegen bundle (org.eclipse.papyrusrt.codegen.cpp.profile) that is not a dependency of the org.eclipse.papyrusrt.umlrt.cpp bundle. In fact, it cannot be a dependency because the dependency goes rather the other way around: the Codegen component depends on the CPP component. This suggests that it is not valid for the CPP bundle to associate this profile to the C++ default-language as it stands currently, because that is an implicit dependency that contradicts the explicit Codegen -> CPP component dependency. Either (a) the profile should be moved into the CPP bundle (or component), or (b) the default-language extension should be moved into the Codegen bundle (or component)
I am bit confused about the assumption that codegen component is depending on the C++ component? Why is it like that? I have several times referenced my old picture that I posted on the developer mailing list, regarding my view about which dependencies I would expect: https://dev.eclipse.org/mhonarc/lists/papyrus-rt-dev/msg00215.html Looking at this picture, I see it perfectly okay that some top level C++ component/feature have a dependency to code-gen (and run-time). So just for my understanding, what is it that makes code-gen depend on C++? Maybe my picture it a bit too naive, but then I would like to understand what it is in practice that contradicts my view about allowed dependencies. I am not sure that neither (a) nor (b) is a solution to whatever this problem really is. The profile really belongs to the code-generator since it is so fundamentally close to the code-generator itself (the purpose is to control how the generated C++ code look like). Maybe the problem is that there is some part in the current C++ component that really should be moved down "below", e.g into the the two "common" boxes in that drawing. PS. Only the ANSI C Primitive types library and the C++ Properties profile are mentioned. I would also expect the run-time model library is a third (equally) critical resource provided by the C++ default language contributions. But maybe it was not relevant in this context and hence not mentioned. Or have I misunderstood, which libraries and profiles the C++ default language contributes and are associated with? DS.
(In reply to Peter Cigehn from comment #1) > I am bit confused about the assumption that codegen component is depending > on the C++ component? Why is it like that? My assumption stems from the inclusion of the CPP component (currently comprising only the one org.eclipse.papyrusrt.umlrt.cpp bundle) in the Core build on Hudson, which is an upstream build of the Codegen build because Codegen requires the Common component that is also in the Core build (and maybe also the Core component, I don't know). Analysis shows that, in fact, there is no bundle in Papyrus-RT that requires this CPP bundle. So, that agrees with your dependency diagram. So, this assumption was wrong, but we do have a problem nonetheless. The problem, then, is that this umlrt.cpp bundle does not express in its manifest its requirement of the codegen.cpp bundle that provides the profile required by the umlrt.cpp bundle's default-language extension. But fixing that will then require moving the umlrt.cpp bundle into the Codegen build job on Hudson. Which, again, agrees with your dependency diagram. The concrete problem that prompted this bugzilla is errors that are logged by the default-language tests for the CPP language which, when they run in an Eclipse configuration containing only the CPP component's dependencies, fail to resolve the profile because that profile is in a codegen bundle that isn't installed because OSGi/Tycho doesn't know that it is required by the CPP bundle. I have added Rémi to cc for comment about this default-language dependency and Céline for comment on the build impact.
(In reply to Christian W. Damus from comment #2) Thanks for the explanation, Christian! As I see it, it is plain wrong to consider the C++ component as being part of Core. That turns everything upside down if you compare with my picture and my view of this. Whenever we add some Java/C/Alf component, with their own default language descriptor and own sets of primitive types (and possibly run-time model) libraries, we cannot have these language specific components are being part of Core. This about moving the C++ component into to the (C++) code-generator build maybe is okay, as long as we don't have a corresponding top level C++ language build. I guess that one asymmetric aspect is that we don't have a specific build for the run-time (not fully sure how that really is built, if at all). Maybe the current codegen build really should encapsulate both the C++ language top level "box", and the C++ code-generator and the C++ run-time "boxes". If we consider the current Codegen build to be that, then I am fine with moving it into the Codegen build.
(In reply to Christian W. Damus from comment #0) > Papyrus-RT 0.8 (almost) > > The default-language contribution for the C++ language is defined in the > org.eclipse.papyrusrt.umlrt.cpp bundle in the CPP component. It provides > two critical resources to a UML-RT/C++ model: > > * the ANSI C primitive types library Is this who provides the AnsiC library? I see the dependency, but I do not see it as exported by this bundle. > * the C++ Properties profile In its MANIFEST I see the RTS model library, but not the C++ Properties, which is currently provided by oeprt.codegen.cpp.profile. > The types library former is hosted in a Designer bundle that is a dependency > of the org.eclipse.papyrusrt.umlrt.cpp bundle. That is okay. > > The profile is hosted in a Codegen bundle > (org.eclipse.papyrusrt.codegen.cpp.profile) that is not a dependency of the > org.eclipse.papyrusrt.umlrt.cpp bundle. In fact, it cannot be a dependency > because the dependency goes rather the other way around: the Codegen > component depends on the CPP component. > > This suggests that it is not valid for the CPP bundle to associate this > profile to the C++ default-language as it stands currently, because that is > an implicit dependency that contradicts the explicit Codegen -> CPP > component dependency. Either > > (a) the profile should be moved into the CPP bundle (or component), or > (b) the default-language extension should be moved into the Codegen bundle > (or component) I think (a) makes more sense. I think there would be some effects on codegen but nothing too bad.
(In reply to Ernesto Posse from comment #4) > I think (a) makes more sense. I think there would be some effects on codegen > but nothing too bad. But that would make the codegen depend on the "top level C++" feature, which turns my view of things "up side down" (compared to the picture I have drawn, linked in Comment 1). But on the other hand, that "top level C++" feature/component that I have depicted there could be a completely new top level feature. Personally I think that it makes more sense to keep the current C++ component, with the default language descriptor sitting on the top, since it in practice only references/"collects" the needed libraries/profiles from elsewhere. It does not per se, provides/exports these libraries/profiles itself. As already discussed/proposed in Comment 2 and Comment 3, it makes more sense to move the C++ feature into the Codegen *build* instead.
(In reply to Peter Cigehn from comment #1) > I am bit confused about the assumption that codegen component is depending > on the C++ component? Why is it like that? This is because we have not yet refactored the code generator into separate "generic codegen" and "C++ codegen", so currently we have 'codegen=C++ codegen', and if I recall correctly, when Remi created the C++ component he added that dependency. Of course, once we restructure codegen into a separate generic component and a C++ codegen component, then there should not be a dependency from the generic component to the C++ component. > > I have several times referenced my old picture that I posted on the > developer mailing list, regarding my view about which dependencies I would > expect: > > https://dev.eclipse.org/mhonarc/lists/papyrus-rt-dev/msg00215.html > > Looking at this picture, I see it perfectly okay that some top level C++ > component/feature have a dependency to code-gen (and run-time). See my comment above. > So just for my understanding, what is it that makes code-gen depend on C++? I think that this dependency was added, temporarily, since currently codegen is C++ codegen. > Maybe my picture it a bit too naive, but then I would like to understand > what it is in practice that contradicts my view about allowed dependencies. It's not naive, it's just that I just haven't had the time to restructure codegen into that architecture since it has not been a priority. BTW, maybe we need an explicit but to track the restructuring of codegen. > I am not sure that neither (a) nor (b) is a solution to whatever this > problem really is. The profile really belongs to the code-generator since it > is so fundamentally close to the code-generator itself (the purpose is to > control how the generated C++ code look like). I think that at least for now, (a) may be the preferable solution, if the profile needs to be moved, since the C++ Properties profile is tied to well, C++. I think that if you are not interested in codegen, then you probably don't care about the default language, and therefore, if you do set the language, you are interested in codegen, and so the profile belongs there. Once we separate "generic codegen' from 'C++ codegen' we could put the C++ Properties profile in the C++ codegen component. > Maybe the problem is that there is some part in the current C++ component > that really should be moved down "below", e.g into the the two "common" > boxes in that drawing. As I mentioned, there is still much restructuring needed for codegen. But that has never been part of 0.8. > PS. Only the ANSI C Primitive types library and the C++ Properties profile > are mentioned. I would also expect the run-time model library is a third > (equally) critical resource provided by the C++ default language > contributions. But maybe it was not relevant in this context and hence not > mentioned. Or have I misunderstood, which libraries and profiles the C++ > default language contributes and are associated with? DS. Just to clarify, I assume you are not talking about the (UML) runtime model library, but the (C++) runtime services libraries in the default language bundle? Currently the model library is deployed in oeprt.umlrt.common.library.rts, i.e. part of 'common', since it is language independent. But the C++ rts is bundled in oeprt.rts (which for historical reasons is, confisingly, in the plugins/umlrt/modelib folder in git). I've proposed to rename this to oeprt.cpp.rts, and make it part of the C++ component, though not in the same bundle as the default language.
(In reply to Christian W. Damus from comment #2) > (In reply to Peter Cigehn from comment #1) > > I am bit confused about the assumption that codegen component is depending > > on the C++ component? Why is it like that? > > My assumption stems from the inclusion of the CPP component (currently > comprising only the one org.eclipse.papyrusrt.umlrt.cpp bundle) in the Core > build on Hudson, which is an upstream build of the Codegen build because > Codegen requires the Common component that is also in the Core build (and > maybe also the Core component, I don't know). > > Analysis shows that, in fact, there is no bundle in Papyrus-RT that requires > this CPP bundle. So, that agrees with your dependency diagram. So, this > assumption was wrong, but we do have a problem nonetheless. If my recollection is correct, Remi created this to start to align with the diagram, but we just haven't had the time to do a full restructuring, as I mentioned in my previous response. > The problem, then, is that this umlrt.cpp bundle does not express in its > manifest its requirement of the codegen.cpp bundle that provides the profile > required by the umlrt.cpp bundle's default-language extension. But fixing > that will then require moving the umlrt.cpp bundle into the Codegen build > job on Hudson. Which, again, agrees with your dependency diagram. If (b) makes life easier for now, I'm ok with it. As I say, until we have a proper refactoring of codegen, the alignment with the picture is not really acucrate. > > The concrete problem that prompted this bugzilla is errors that are logged > by the default-language tests for the CPP language which, when they run in > an Eclipse configuration containing only the CPP component's dependencies, > fail to resolve the profile because that profile is in a codegen bundle that > isn't installed because OSGi/Tycho doesn't know that it is required by the > CPP bundle. > > I have added Rémi to cc for comment about this default-language dependency > and Céline for comment on the build impact.
(In reply to Peter Cigehn from comment #3) > (In reply to Christian W. Damus from comment #2) > > Thanks for the explanation, Christian! As I see it, it is plain wrong to > consider the C++ component as being part of Core. That turns everything That is correct. Again, the current dependencies should be considered temporary until the new architecture is done. > upside down if you compare with my picture and my view of this. Whenever we > add some Java/C/Alf component, with their own default language descriptor > and own sets of primitive types (and possibly run-time model) libraries, we > cannot have these language specific components are being part of Core. > This about moving the C++ component into to the (C++) code-generator build > maybe is okay, as long as we don't have a corresponding top level C++ > language build. I guess that one asymmetric aspect is that we don't have a > specific build for the run-time (not fully sure how that really is built, if > at all). Maybe the current codegen build really should encapsulate both the > C++ language top level "box", and the C++ code-generator and the C++ > run-time "boxes". If we consider the current Codegen build to be that, then > I am fine with moving it into the Codegen build. For me, whichever solution works for the current build.
Sorry Peter, I think we crossed messages. I'm at MODELS so I didn't have time to reply sooner. (In reply to Peter Cigehn from comment #5) > (In reply to Ernesto Posse from comment #4) > > I think (a) makes more sense. I think there would be some effects on codegen > > but nothing too bad. > > But that would make the codegen depend on the "top level C++" feature, which > turns my view of things "up side down" (compared to the picture I have > drawn, linked in Comment 1). But on the other hand, that "top level C++" > feature/component that I have depicted there could be a completely new top > level feature. Currently nothing. But I think Remi added that dependency because, as I mentioned in the other messages, currently codegen = C++ codegen. > > Personally I think that it makes more sense to keep the current C++ > component, with the default language descriptor sitting on the top, since it > in practice only references/"collects" the needed libraries/profiles from > elsewhere. It does not per se, provides/exports these libraries/profiles > itself. I'm not sure what you mean by "sitting on the top", but C++ codegen obviously needs the Ansi C library and the C++ Properties profile, so wherever they are packaged, we need a dependency to that. > > As already discussed/proposed in Comment 2 and Comment 3, it makes more > sense to move the C++ feature into the Codegen *build* instead. From my point of view, whatever works is fine, until we do a proper restructuring of codegen.
(In reply to Ernesto Posse from comment #9) > (In reply to Peter Cigehn from comment #5) > > Personally I think that it makes more sense to keep the current C++ > > component, with the default language descriptor sitting on the top, since it > > in practice only references/"collects" the needed libraries/profiles from > > elsewhere. It does not per se, provides/exports these libraries/profiles > > itself. > > I'm not sure what you mean by "sitting on the top", but C++ codegen > obviously needs the Ansi C library and the C++ Properties profile, so > wherever they are packaged, we need a dependency to that. > What I mean it "sitting on the top" is when I look at the picture I draw, i.e. a dependency tree with the dependencies going downwards. Yes, the C++ codegen needs the C++ Properties profile, and hence I prefer to keep the C++ Properties profile strongly coupled and packaged together with the C++ codegen. When it comes to the Ansi C Library it is in practice packaged in Designer and the C++ codegen can have a dependency to that. The C++ codegen do not have to have an explicit dependency "upwards" to the implementation of the C++ default language descriptor. When it comes to the default language framework itself, we are utilizing dependency inversion, i.e. we have an interface defined in Core, which the specific C++ default language descriptor the provides a specific implementation of. But the C++ codegen only needs to depend on Core (during buildtime) and then during runtime the C++ specific implementation of the language descriptor can be executed. As I see it, the C++ default language descriptor only references the different libraries/profiles that it associates with that default language. The actual libraries/profiles can be packaged elsewhere (further down in the dependency chain). I probably need to draw a new picture to show what I mean (or at least what I think that I mean)... :) We probably should live as we learn and make some good model of these dependencies to get a good overview of the architecture of Papyrus-RT.
As general Comment, let's think about the furture evolutions. Imagine we add new languages like Java, or whatever. The structure should remain logical, even if we add new languages. Furthermore, The user would be able to install Papyrus RT without Codegen Component, so if we move the cpp bundle into the Codegen Component , does it make a difference for the User installing only the basic Papyrus RT ? Concerning the different dependencies, I don't have a wide enough overview about the CPP and the codegen projects to take a decision on this.
(In reply to Ernesto Posse from comment #6) <...snip...> >I think that if you are not interested in codegen, then you probably > don't care about the default language, and therefore, if you do set the > language, you are interested in codegen, and so the profile belongs there. > Once we separate "generic codegen' from 'C++ codegen' we could put the C++ > Properties profile in the C++ codegen component. I can't agree with that. You may set the language to "Natural Language" or some form of "UML-RT" providing access to the model library in order to do some exploratory or high-level modeling and not be interested in code generation (which I know has been done with legacy tooling). Or use a DSML for system engineering with its own language that doesn't do codegen. <...snip...> > > > PS. Only the ANSI C Primitive types library and the C++ Properties profile > > are mentioned. I would also expect the run-time model library is a third > > (equally) critical resource provided by the C++ default language > > contributions. But maybe it was not relevant in this context and hence not > > mentioned. Or have I misunderstood, which libraries and profiles the C++ > > default language contributes and are associated with? DS. There has been some discussion about this in another bug's thread. Yes, the (or rather a) runtime library should also be provided. However, there is also the possibility that language-specific runtime libraries be required, for for languages and for augmented runtimes offering new services (which would be a new UML-RT DSL-based DSL). > > Just to clarify, I assume you are not talking about the (UML) runtime model > library, but the (C++) runtime services libraries in the default language > bundle? Currently the model library is deployed in > oeprt.umlrt.common.library.rts, i.e. part of 'common', since it is language > independent. But the C++ rts is bundled in oeprt.rts (which for historical > reasons is, confisingly, in the plugins/umlrt/modelib folder in git). I've > proposed to rename this to oeprt.cpp.rts, and make it part of the C++ > component, though not in the same bundle as the default language. I believe both need to be part of this discussion, and I think that your renaming suggestion is a good one as we will have more language-specific runtimes (implementing the UML-RT service contracts from the existing model library, or a derived, one.
So what's the decision on this one? (a) or (b). If it's (a) I can do it, but if (b) is the preferred choice, I'm not sure, as I'm not familiar with the dafault language framework and what needs to be moved. I'm not sure about the impact on the build either. @Christian: how and where do you see this problem? In the build? If so, which job?
(In reply to Ernesto Posse from comment #13) > > @Christian: how and where do you see this problem? In the build? If so, > which job? I observed it in automated tests in the build. A test case for the default-language framework was failing because, even though the test bundle expressed a dependency on the org.eclipse.papyrusrt.umlrt.cpp bundle that defines the C++ default-language, that CPP bundle was trying to tell the default-language service to apply a profile from the C++ Codegen bundle. But the CPP bundle didn't have a dependency on that codegen bundle, so Tycho didn't install it. The result was a test failure because of an exception in the default-language service.
Before going ahead and deciding anything related to this, I would really like to hear Rémi's opinion about this. After all, he is the one that has designed the default language framework, and have made the implementation of the C++ default language contribution.
Moved to future until more information is received, enabling proper assignment.
