Re: [papyrus-rt-dev] [Neon] in Progress

[Ernesto Posse <eposse@xxxxxxxxxxxxx>]

Hi. The setup is looking good! My replies on generated EMF, xtext, xtumlrt and the runtime are inlined below.

On Fri, Apr 8, 2016 at 7:24 AM Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:

But the other question of generating code and classpath folders is one that I don’t think should be addressed by the setup model.  As I discussed with Ernesto, this really needs to be implemented as a project builder so that it may be kept continually up-to-date.

​Yes, I agree. The issues with the generated code and missing folders is a completely separate issues and should be solved separately.​

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.

3) Related to the same I was also a bit confused that the run-time was not mentioned or included in any of the subprojects. I have no idea if it the run-time parts are supposed to be included or not, I was just suprised that I could not find any traces of it! But maybe the run-time is only considered to be external C++ code, so the development of that is outside the scope of the "normal" development. :)

Yes, that’s because the run-time is a kind of component that I’m quite unfamiliar with.  I don't know what bits in the repository actually need to be imported as what kinds of workspace projects.  I’d prefer to leave it to the run-time experts to add the run-time to the setup model.

​Agree.

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.

 

4) The current XtUMLRT maybe should be split into a separate part for the Textual stuff, and keep only the meta-model (the stuff that IncQuery relies on) in a separate subproject/workingset. Not sure about the name either. I would expect it to be named xtUML-RT, or something like that. But I have not been involved here to know. Maybe Erneste can give his view regarding the name and scope of this subproject and contents of the working set.

As I don’t understand (yet) the ways in which the XtUMLRT plug-ins fit into the architecture, I mostly just followed the directory structure in git and common bundle-name prefixes to group things.  I welcome contributions from those that are familiar with these bundles to improve their organization in the setup.

​Agree, let's here what Ernesto have to say about this.​

 

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?