Add possibility to use multidimensional trace addon with RTDs specified in a separate file

[ValentinBesnard]

It seems that it is not currently possible to use the multidimensional trace addon with RTDs specified in a separate file of the static model.

To use this addon with my execution engine, I specify my RTDs in a separate file of the static model (no weaving is used). The view of the multidimensional trace addon is built when the first step is executed but then the view is not updated on the following step executions. The addon does not see that the RTDs have been updated.

In the file org.eclipse.gemoc.trace.gemoc/src/org/eclipse/gemoc/trace/gemoc/traceaddon/AbstractTraceAddon.xtend, the BatchModelChangeListener is built with the resource model to execute (the static model) and all resources related to it (i.e., resources that are linked to the resource model with cross references). To be a bit more generic, it may be interesting to built the BatchModelChangeListener with the resource that contains the RTDs, which may be the resource model (in case of weaving) or another file (if RTDs are specified in a separate file).

[dvojtise]

👍

Additionally, I think this could also be used with engines not using aspect weaving.
For example, using Java/K3 engine and Moccml Engine without the help of Melange also have the same issue.

Culprit line:
https://github.com/eclipse/gemoc-studio-modeldebugging/blob/177def7ae9d91fac809f6a114c85cc2d044f3aa0/trace/generator/plugins/org.eclipse.gemoc.trace.gemoc/src/org/eclipse/gemoc/trace/gemoc/traceaddon/AbstractTraceAddon.xtend#L158

This line supposes that the EMF resource containing the RTD is accessed via a cross-reference starting from the static model.
This is fine when using aspect weaving (thanks to Melange or ALE) or if the ecore file also defines the RTD (for example like in https://github.com/eclipse/gemoc-studio/blob/master/official_samples/K3FSM/language_workbench/org.eclipse.gemoc.example.k3fsm/model/k3fsm.ecore), but it doesn't work when keeping the static part and dynamic in two separate ecore file (with cross-references going only from the dynamic part to the static part)

[dvojtise]

I suggest to extend IExecutionContext and add a method like

List<Resource> getAdditionalResourceRTDModels();

so it would be possible to do a

context.getAdditionalResourceRTDModels().add(myadditionalRTDResource);

https://github.com/eclipse/gemoc-studio-modeldebugging/blob/master/framework/framework_commons/plugins/org.eclipse.gemoc.xdsmlframework.api/src/org/eclipse/gemoc/xdsmlframework/api/core/IExecutionContext.java

[ValentinBesnard]

Yes, I think this would be a good solution.

To extend your idea, it may also be possible to define a default implementation returning the static resource model. Then the default method can be overridden in each execution context implementation if needed.