Hi Céline. You are right, there is some confusion both in the folder structure and plugin naming. I agree that we should have better naming.
Here's a short explanation for why these things are where they are now:
When we talk about the "runtime" or "rts" (for runtime-system, of course), we include two things:
1) the C++ runtime, which is the "middleware" and consists of the controllers (which control the execution of capsules and manages their lifetimes), and the runtime services library, which implements an API for services like Timing, Frame and Log, that the user can access in applications.
2) the runtime model library, which is the UML(-RT) model that defines model elements that represent elements and services from the runtime services library.
So the user can, for example, define ports whose protocol is Timing from the runtime model library, and then use the Timing API from the C++ runtime services library in action code.
When we were defining the directory structure for plugins, Remi proposed the structure described in
https://wiki.eclipse.org/Papyrus-RT/Developer_Guide/Git_Repository where there is a specific folder for the runtime (
plugins/umlrt/runtime). In fact, as that page says, it is intended to hold possibly more than one runtime, looking ahead to supporting multiple target languages beyond C++.
Since at this point we still have only C++ support, it was decided to have only the C++ structure inside this folder. Barry, who wrote most of the runtime, had control over this folder, and he wanted its top-level structure to have two sub-folders: 'rts' and 'tests'. The 'rts' folder contains the actual C++ sources. The 'tests' contains tests written by Barry, and they are exclusive to this rts. The code there is written by hand and not generated. Barry wanted to have tests which he would control.
Then there was a question of packaging: where is the rts supposed to be packaged and deployed. It is packaged and deployed in a plugin called 'oeprt.rts' which was inside 'plugins/umlrt/codegen' and also packaged the model library. As a side-note, this plugin should not be confused with 'oeprt.codegen.cpp.rts' which is a Java plugin that provides a Java façade to the RTS, to be used by the code generator. 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. So before the 'core' plugins where created, I created the 'modellib' folder and we moved the 'oeprt.rts' folder there, but still packaging both the C++ rts and the model library. Then, I think it was Remi, although I'm not sure, who created the 'oeprt.umlrt.common.rts.library' plugin and the model library was moved there. So that left the rts alone in 'plugins/umlrt/modellib/oeprt.rts', and obviously this is now an incorrect name, and as you propose, it should be 'plugins/umlrt/runtime/'oeprt.rts'. BTW, this plugin is also in the "Core" working set, and it shouldn't be there. In fact, since this is a C++ runtime, perhaps the plugin should be renamed from 'oeprt.cpp.rts' and the runtime folder should be divided into subfolders for alternative target languages: plugins/umlrt/runtime/cpp, plugins/umlrt/runtime/java, etc.
So I propose a small amendment to your proposal:
- rename plugins/umlrt/runtime/rts to plugins/umlrt/runtime/cpp/rts
- rename plugins/umlrt/runtime/tests to plugins/umlrt/runtime/cpp/tests
- rename plugins/umlrt/modellib/org.eclipse.papyrusrt.rts to plugins/umlrt/modellib/org.eclipse.papyrusrt.cpp.rts
Any objections?
As for the xtext and xtumlrt projects, the situation is a bit more complicated and we might need more discussions. Currently the xtext feature contains both xtumlrt and xtext as you see. But it is possible that we will get rid of xtumlrt. This is because of the new Eureka project that we are starting with EclipseSource and MDH. Allow me to explain: the xtumlrt meta-models serve two purposes: 1) they are used as an intermediate representation for the code generator, and 2) they are used as the abstract syntax for the xtext projects. The goal of the Eureka project is to provide a mixed graphical/textual modelling environment, where you can switch back-and-forth between graphical and textual editors, which is what my demo was about. Currently we have bidirectional transformations between UML and xtumlrt for this purpose, but in our discussions, Philip Langer (from EclipseSource) and Federico Ciccozzi (from MDH) think that it would be better to have just one model (the UML) which would simplify many things for mixed modelling. This would entail getting rid of xtumlrt, at least for the xtext part. It has not been decided yet, and we are investigating how easy it would be to make such change. So for the time being we need to keep xtumrt. Furthermore, even if we don't use xtumlrt for mixed modelling, we may choose to keep it for code generation. So at this point, it would seem reasonable to separate xtumlrt and the xtext projects into separate features, folders and components doing something like this:
- create a folder plugins/xtext
- move plugins/xtumlrt/xtext to plugins/xtext
- rename all oeprt.xtumlrt.xtext.* plugins into oeprt.xtext.*
- remove all *xtext* plugins from the xtumlrt feature
- create a separate xtext feature with the plugins from plugins/xtext
- leave the xtumlrt feature for now (without the xtext) plugins, and possibly remove it in the future
This might need a bit more thinking because I think we may have some circular dependencies in some of the xtumlrt plugins (in the trans folder, dependencies to codegen). We need to take a closer look at that.
However, doing this may be premature. If we decide to do what Philip and Federico propose, then we would create new xtext projects (called oeprt.xtext.*) under plugins/xtext that do not depend on xtumlrt, like they currently do. That would make them different from the xtext projects under xtumlrt. In such eventuality, we would remove the xtext projects from xtumlrt altogether.
So, just to clarify, we currently have some xtext projects that are based on xtumlrt, and in the future we may replace them by xtext projects that do not depend on xtumlrt.
Now, I don't know if there is any interest in packaging 'xtumlrt' as a feature that happens to include both the xtumlrt meta-model and the xtext feature. Currently, as I mentiones, xtumlrt is used only for code generation and xtext, rather than as a feature on its own. So I would rather have a feature called 'oeprt.xtext.feature' than 'oeprt.xtumlrt.feature', or have both. But I think renaming oeprt.xtumlrt.xtext.feature into oeprt.xtext.feature might also introduce some confusion. First, the name was given by xtext itself, and I would rather stick to the defaults. Second, if we keep the full ugly name with xtumlrt, we know that we are talking about the xtext projects that do depend on xtumlrt, rather than the potentially new xtumlrt-independent projects. Hence, I would leave the name of that feature, the location and names of the plugins as they are, at least for the time-being, and when we have a final decision about which way are we going with xtext, then we can change them. Does that sound Ok?
As for the dashes in the codegen and rts features, they where there because it was Andrew who named them. But I do think we should change them to follow the same naming rules as the rest.
Hello everyone,
I'm a bit confused with the name of the following path.
RTS files are either in a modellib or in a runtime folder.
Why this differences ? Wouldn't it be clearer if we give a common name like "runtime" or "rts" ?
For xtext and xtumlrt it is the same confusion . Is xtext included into xtumlrt ?
In another hand, there are some feature name that does fit the naming convention.
Here is the proposed modifications:
· Feature/runtime/oeprt.rts-feature => Feature/runtime/oeprt.rts.feature
· Plugins/umlrt/modellib/oeprt.rts => Plugins/umlrt/runtime/oeprt.rts
· Plugins/umlrt/runtime/rts/ => OK
· Feature/codegen/oeprt.codegen-feature => Feature/codegen/oeprt.codegen.feature
· Features\xtext\oeprt.xtumlrt.xtext.feature => Features\xtext\oeprt.xtumlrt.feature
Do you see any restrictions ? Or possible side effects if I apply those modifications ?
Best regards
Céline
[cid:image001.jpg@01D21274.1B5B72D0]
_______________________________________________
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
