Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [papyrus-rt-dev] Architecture issue on uml library of the runtime
The deployment of the model library with the runtime was mostly a matter of convenience at the time

Charles Rivet

On Mar 17, 2016, at 10:38, Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:

The o.e.prt.rts plugin contains the model library and it is where we are deploying the C++ runtime.

As Charles says, the model library is language agnostic. I don't know who decided to bundle the two in the same plug-in, though.

I do agree with the idea of having a separation between the language-agnostic parts and the C++ codegen/rts.

Since the library is language agnostic, shouldn't it go in the main feature?

I'm not sure I understand why o.e.prt.core.cpp should depend on the model library, specially since the library is language agnostic. 

Nevertheless, I'm OK with the modifications proposed.

Perhaps we could create a separate plugin for the C++ rts (say called o.e.prt.rts.cpp) and leave o.e.prt.rts with only the model library, or rename it to something like o.e.prt.modellib, and possibly include that in the main feature?

To do this split we need to make some adjustments to our POM files, and since we use the model library in the generator, any refactoring would have an impact and we need to make the necessary adjustments.

PS: I'm leaving on vacations tomorrow until April 4th, so I have limited time today to do any necessary adjustments on our end.



On Thu, Mar 17, 2016 at 8:13 AM, Charles Rivet <charles@xxxxxxxxxxxxx> wrote:
Some clarification about the model library: it is intended to represent  UML-RT concepts an is, therefore, intended to be target language agnostic (or should be if it is not). As such, it should be able to stand alone.

Consequently, It should  not be linked to any specific runtime, but each language runtime must provide implementations for the elements it defines. In that way, it represents a contract that runtimes must provide (albeit a rather weak contract in its current form). In the future, it could serve as an "abstract" contract for runtime models.

In a similar same way, it needs to be used by the code generators to get hints on generation (e.g., system protocols) and by the UI to get hints on display (e.g., system events).

I believe what is being proposed is in line with the purpose of the model library, but it can be difficult to follow the discussion on a mobile phone's small screen...

Charles Rivet

On Mar 17, 2016, at 06:18, SCHNEKENBURGER Remi 211865 <Remi.SCHNEKENBURGER@xxxxxx> wrote:

Hi Peter,

 

Good, we are in sync then! This is exactly where I would like to go with the architecture. I would like to have the current runtime service library not included directly in the core, but in the CPP part of the tool.

 

o.e.prt.core.cpp is the core support for the C++ language in Papyrus-RT (default language, specification of the C++ primitive types, etc.)  and that one should be dependent from the rts plugin.

 

A new Papyrus-RT cpp feature should be setup, not included in Papyrus-RT main feature. It should be easy to reach or install such a feature, either with oomph setup of a kind of discovery site as in Papyrus.

This Papyrus-RT cpp feature should deploy the o.e.prt.core.cpp plugin,  the rts library if C++ dependent and all required tooling/runtime/codegen for C++ additions.

 

There is currently an issue, where the Papyrus-RT feature deploys by default the Papyrus-RT cpp plugins. And I have build issues when I try to integrate also the runtime services.

 

Regards,

Rémi

-------------------------------------------------------

 

Rémi SCHNEKENBURGER

+33 (0)1 69 08 48 48

CEA Saclay Nano-INNOV

Institut CARNOT CEA LIST

 

<image001.png>www.eclipse.org/papyrus

 

De : papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx] De la part de Peter Cigéhn
Envoyé : jeudi 17 mars 2016 10:40
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : Re: [papyrus-rt-dev] Architecture issue on uml library of the runtime

 

Hi,

 

I am not sure I understand the build aspect. You say that "the build of core or the core.cpp somehow include the build of the o.e.p.rts plugin". Well, I am not sure about this about core. I expect that it should be possible to install Papyrus-RT without the C++, run-time and code-gen features, and only have core, e.g. if you only are using Papyrus-RT for structure modeling (and are not interested in the behavior modeling with state machines, and any of the code-generation stuff).

 

Actually, I would like to remove the dependency from the top level Papyrus-RT Feature to the Papyrus RT Core C++ Feature which we currently have (and possibly renamed it into Papyrus RT Language C++ or something)

 

The top level Papyrus-RT Feature should only depend on the Papyrus RT Core, Papyrus RT Profile and Papyrus RT Tooling. 

 

The run-time and the code-generator are separate from the top level Papyrus-RT feature, and I guess the C++ language specific feature should be the same. The generic language framework should of course be included in core, but the extension on top of it (including the dependency to the run-time model library, which potentially could be language dependent).

 

Whenever we add additional languages in the future (Java, Alf, C) then you should be able to select only the language(s) you actually want to use. You shall not be "forced" to get C++ (as you do now if you select to install the top level Papyrus-RT feature).

 

Or do you foresee that we shall handle this differently regarding how to install the "optional" features of Papyrus-RT, for the use cases where only structure modeling is being used?

 

/Peter Cigéhn

 

On 17 March 2016 at 10:24, SCHNEKENBURGER Remi 211865 <Remi.SCHNEKENBURGER@xxxxxx> wrote:

Hi all,

 

I currently have a small issue [1] on the UML library for the current runtime (plugin o.e.prt.rts).

It would be required by the core.cpp feature, which declares initially the support for the C++ runtime. The library is required for example by the cpp core plugin, which indicates that this library should be loaded when the C++ language is used.

 

More on this feature is described here:

Bug 488104: Identify UML-RT system classes in UMLRT-RTS model library

https://bugs.eclipse.org/bugs/show_bug.cgi?id=488104

Bug 477721: Decide on common principle to identify system protocols,

including base protocol in UML-RT model library

https://bugs.eclipse.org/bugs/show_bug.cgi?id=477721

 

That indicates that the build of the core or the core.cpp should somehow include the build of the o.e.p.rts plugin. Do you have any objection towards this ?

 

Moreover this library is declared as a java plugin, where I do not see any code. Are there any plans to add code there?

Finally, I would recommend to split as done for the profile some changes in the dependencies and extension points:

-        I do not see the need for a gmf.runtime dependency there

-        I would not add the papyrus extension there, but rather in a tooling plugin. With that extension point removed, there are no dependency towards Papyrus UI, and so no need to have Papyrus installed to use the library (useful for example for basic command line model transformation)

Do you see any objection on that modifications?

 

Regards

Rémi

 

[1] https://git.eclipse.org/r/#/c/67560/

-------------------------------------------------------

 

Rémi SCHNEKENBURGER

+33 (0)1 69 08 48 48

CEA Saclay Nano-INNOV

Institut CARNOT CEA LIST

 

<image001.png>www.eclipse.org/papyrus

 


_______________________________________________
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

_______________________________________________
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




--
Ernesto Posse

_______________________________________________
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

Back to the top