Expose the execution state of a model in a generic fashion

[dvojtise]

Exposing the execution state of a model in a generic fashion similarly to the trace has several benefits:

• avoids the need to have a merged static+dynamic ecore metamodel, and this avoids the need to manage an "extends" relationship between two ecore files (https://github.com/eclipse/gemoc-studio/issues/58)
• this also allows writing sirius java services that would display the RDT
• applied to K3 with runtime data, this would simplify the debug of the k3 code since we do not have the aspect copy (currently, the aspect copy of Melange prevents eclipse from correctly linking to the real K3/xtend source when launching the second eclipse workbench in debug mode)

[dvojtise]

note, @jdeantoni has started some work about exposing RTD written in K3 (in https://github.com/gemoc/concurrency/tree/master/ccsljava_execution/ccsljava_engine/plugins)

This work can probably be generalized. What do you think of the https://github.com/gemoc/concurrency/tree/master/ccsljava_execution/ccsljava_engine/plugins/org.eclipse.gemoc.execution.concurrent.ccsljavaengine.extensions.k3.rtd.modelstate ) can it be generalized to xmof or to straight ecore models with our previous "aspect" EAnnotation ?

@barais has also recently added the retention of annotation on K3 attribute (https://github.com/diverse-project/k3/commit/4cba0f80f57315c88edbfb40eec21cbeff1f228d) this would help to correctly inspect k3 code with a correctly named annotation on K3 file (for example @RTD) (Julien has some needs to not expose all attributes )

[ebousse]

Indeed, what @jdeantoni has started is indeed exactly the direction I had in mind :). We might want to sit down all together in the near future and make sure this RTD metamodel is complete and generic enough, and then we can generalize it to all metalanguages. Then we be able to force each metalanguage to provide a way to access the runtime state as an instance of this metamodel.

[ebousse]

I did not understand what the code of @barais is doing though?

[dvojtise]

@barais's code only makes sure that an annotation on an attribute in k3 is preserved in the generated java code. Ie. one can define a java annotation to be added on attribute, then this annotation is copied to the corresponding attribute in the companion class. This is required due to the compiling scheme of K3 that exposes everything as public. For example, if we define a java annotaiton "RTD", this allows using this annotation in a reflective code in order to show only relevant attributes and keep transient/private attributes hidden