Hi. The setup is looking good! My replies on generated EMF, xtext, xtumlrt and the runtime are inlined below.
Indeed. I just got a reply from IncQuery. They originally objected to having the sources in the git repo since they are redundant and prone to become outdated if the meta-model is modified, but given that the xtumlrt meta-model is now relatively stable, they are not opposed to committing the sources as is done in other Eclipse projects. They also have done some work on project builders for this.
So now the question is what would be preferable: a) commit the sources, or b) create our custom project builders. Any preferences? Arguments for ar against either?
For Xtext, as Christian has pointed out, there is a project builder. I think this would also take care of the missing folders in the xtext projects. I'll look into it.
Well, the runtime is C++, but I would argue that development of the runtime and the code-generator go hand-in-hand. The runtime is independent from the code generator, but (conceptually) the code generator depends on the runtime. From the point of view of building, the code generator and runtime are independent.
The runtime is in a single C++ project called "rts" and found in plugins/umlrt/runtime which also includes its own "tests" folder with a couple of projects.
I think it is pretty much self-contained, except for the toolchain (gcc) and standard libraries.
Perhaps we could have the setup model just import this 'rts' project and leave it to the user to install whichever external C++ libraries are needed on their own.
The xtumlrt meta-model is used in two ways: 1) as the first intermediate representation of the code generator, and 2) the abstract syntax for the xtext grammar.
During code generation the translation goes like this: UML+Profile -> xtumlrt -> C++ subset MM -> C++ sources. The xtumlrt metamodel simplifies a lot of the complexities inherent in UML, making it more like a "pure" UML-RT.
For textual syntax, that representation is used as the abstract syntax, which we can now translate back to UML+Profile as well.
I put (almost) all the xtumlrt related plugins in the plugins/xtumlrt folder:
- plugins/xtumlrt/metamodel: contains the EMF models:
. common: the common core (common with xtuml)
. umlrt: the umlrt-specific extensions
. statemach: the state machines
. statemach.ext: extensions to state machines used in code generation (when flattening the SM)
- plugins/xtumrlt/trans: contains the base(s) for transformations involving xtumrlt
- plugins/xtumlrt/xtext: contains the xtext plugins and the textual-to-UML transformation (maybe this could be moved to trans?)
There are a few xtumrlt related plugins and classes under plugins/umlrt/codegen, Namely oepr.codegen.xtumlrt.trans which is the UML-to-xtumlrt translator, and a couple of utility classes under oepr.codegen.utils (which prehaps should be moved to plugins/xtumlrt/utils).
I can do the reorganization, but should I now or wait until the other issues with the setup model have been settled?