| [papyrus-rt-dev] Integration of the rts model library in the core |
|
Hi all, I restart the work on these bugs [1] this week. I wanted to integrated quite fast, as it impacts the architecture of the tool, especially having some impact on code generator and tooling. The contribution on gerrit [2] is ongoing, we are only facing now some small issues on the integration/testing part. Thanks to Ernesto, the contribution for the testing of the code generator was updated. I can easily now integration the
contribution if it is OK with everyone, I just have to remove the reviewer Hudson-ci from the list of reviewers, and its -1 will be removed from the votes. Some historic discussion already happened on that mailing list [3]
However, before integrating this contribution, I wanted to be sure everyone was OK on it: -
I created a new plugin for the rts model library. This model is supposed to be independent from any implementation language, so I added it to the core part of Papyrus, with no link to C++ as it was before. In fact, RTS model library
and the runtime were distributed in the same plugin historically for convenience. -
I moved the library in this new plugin, cleaned bit the dependencies, and I would like also to remove the extension as a Papyrus library. This declaration is used only for a tooling point of view, to be listed in the list of available
registered libraries, it has no impact on the element resolution when model is loaded. Removing it would remove the dependency of the library to Papyrus, thus making it usable on standalone model transformation / code generation / etc. -
I changed the pathmap location. It now points to the new plugin, so there are no impacts on the existing models referencing the model library by the pathmap (which should be always the case). -
The o.e.prt.rts only contains the generated C++ code. As it is C++ dependent, I would advise to make it obvious in the namespace. -
Does everyone agree on that changes? Once the contribution is merged, I can finish the work on the system protocol identification (and system classes by the way) relying on default language framework & specific profile Regards, Rémi [1] 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 [2] https://git.eclipse.org/r/#/c/67560/ [3]
https://dev.eclipse.org/mhonarc/lists/papyrus-rt-dev/msg00215.html ------------------------------------------------------- Rémi SCHNEKENBURGER +33 (0)1 69 08 48 48 CEA Saclay Nano-INNOV Institut CARNOT CEA LIST |
