Re: [papyrus-rt-dev] [Naming Convension] Xtumlrt and RTS

[Ernesto Posse <eposse@xxxxxxxxxxxxx>]

Thanks Peter and Charles for your answers.

From the explanations, I conclude that the model library should remain where it is in the 'common' component (plugins/umlrt/common/oeprt.umlrt.common.rts.library) and if language-specific specializations are required, we could add them to their respective runtime  components.

I think there is one other related relevant issue for the build: in the new build (and in the old one) we have one job that builds both the code generator and the runtime. I'm assuming that we want to keep doing this since there is a strong link between a code generator and the corresponding runtime, is that correct?

Also, for now we only have one such codegen+rts pair, but in the future we would have others for other target languages. I assume we should have then separate jobs for those, i,.e. a C++-codegen-rts job, a Java-codegen-rts job, etc. correct?

PS: Céline: do you want to do the renaming of plugins, features and folders or do you want me to do them?

On Tue, Sep 20, 2016 at 8:41 AM charles+zeligsoft.com <charles@xxxxxxxxxxxxx> wrote:

I would add to this that the intention of the RTS model library was to provide the minimum protocol-based “API” contract for the runtime service library to implement UML-RT service provision points (frame, timing, log), with the notable exception of messaging services (send, invoke, etc.), which is handled separately through the port implementation.

These are the services that every UML-RT runtime service library implementation must provide (again, in addition to port-based messaging).

Because these are defined as protocols, they should be language-agnostic and applicable for all languages, although the syntax of the way they are called will, of course, depend on the implementation language.

And yes, there is more than just protocols in that library because some of these protocols’ messages would require additional information, but these elements are defined as UML classes and should therefore be translatable to any OO language.

Note that this does not preclude the addition of other runtime service in libraries that specialize (inheritance) or complement (composition) this one. The creation of more specific (e.g., language, platform, etc.) or augmented (additional services, possibly from a UML-RT-based DSML) should be possible, but the base UML-RT language must still be present.

Unfortunately, Zeligsoft currently has issues accessing the Eclipse infrastructure, so I can’t comment on Peter’s picture yet - I’ll do that later today from home, after my morning meetings.

Sincerely,

Charles Rivet
Senior Product Manager, Papyrus-RT product lead

charles@xxxxxxxxxxxxx

On 2016.09.20, at 03:34 , Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:

Hi,

On 19 September 2016 at 17:49, Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:

As part of the discussions regarding the language framework and the support for multiple target languages, it was decided that the model library should be packaged and deployed separately, as part of the "common" plugins. I'm not sure why that was the case, and probably Charles and Peter could give a better explanation, but I think the idea is that the model library itself is supposed to be independent of the target language, and therefore it should not be part of either the C++ code generator or the C++ runtime.

​Way back I drew a picture, 

on a rather high

​​

level

​, ​

​of how I thought that the features/components should be structured. See https://dev.eclipse.org/mhonarc/lists/papyrus-rt-dev/msg00215.html and the related mail thread regarding this.

​Since I like symmetry, I added the two boxes "Common Code Generator" and "Common Runtime", without considering the ​

​

​size of these boxes and exactly what they would contain. During the discussion it was concluded the the "Common Code Generator"-box probably could be rather "thick" whenever we would add multiple target languages, whereas the "Common​ Runtime" would be rather thin (or maybe even no commonalities would be identified).

However, the current run-time model library, is as Ernesto say, assumed to be target language agnostic and thus it was concluded that it could be placed in the "Common Runtime"-box. I myself am not fully convinced though that this intention of having a target language agnostic run-time model library will hold whenever we actually will start adding support for multiple target languages. Comparing with the legacy modeling tool, there are in fact different run-time model libraries for different target languages. I am not arguing for this solution, just stating that the assumption that the run-time model library is target language agnostic maybe not will hold the day we actually start adding additional target languages.

And thus, the (different) run-time model libraries could very well have to "move up" into its respective language runtime boxes, leaving the "Common Runtime"-box basically empty (or very thin).

This picture however is rather conceptual and it probably have not been considered much when structuring/naming things in the Git repo.

/Peter Cigéhn

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev