Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "VIATRA/Integration/DeveloperDocumentation/Xcore"

(New page: = Notes on IncQuery & Xcore integration = The language file has been created and the project consists of two plugins. Most of the xtext-related classes are extended from the appropriate x...)
 
Line 1: Line 1:
 
= Notes on IncQuery & Xcore integration =
 
= Notes on IncQuery & Xcore integration =
  
The language file has been created and the project consists of two plugins. Most of the xtext-related classes are extended from the appropriate xcore classes, but some of them has been entirely copied due to the lack of extensibility. This will be investigated later with Ed and the required changes will be performed in the xcore codebase.  
+
The language file has been created and the project consists of two plugins. Most of the xtext-related classes are extended from the appropriate xcore classes, but some of them has been entirely copied due to the lack of extensibility. This will be investigated later with Ed and the required changes will be performed in the xcore codebase. Try to extend and only inject new fields without copying code wherever possible.
 +
 
 +
Inferring the genmodel:
 +
The special IncQuery derived feature should be handled separately. Important note: referring any model element should be done post-linking. This is really important, for example, for the pattern reference of the derived feature during code generation phase.
 +
 
 +
Code generation for the derived feature:
 +
Two separate issues: (1) code generated into the model code and (2) code used during dynamic EMF manipulation.
 +
(1) This will be solved by the special Ecore annotations and in the similar way as Xcore does it. No XbaseCompiler will be used, only the IncQuery derived feature evaluator artifacts will be invoked with the pattern fully qualified name.
 +
(2) EStructuralFeature.SettingDelegate will be used for evaluation.
 +
 
 +
Initialization of the patterns in the pattern registry:
 +
...
  
 
Problematic points at the moment:
 
Problematic points at the moment:
 
* Question regarding the resource descriptions: should the Xcore resource expose also the IncQuery artifacts?
 
* Question regarding the resource descriptions: should the Xcore resource expose also the IncQuery artifacts?
 
* How should we handle the Serializer / Parser component? This causes the Exception during dynamic EMF model manipulation.
 
* How should we handle the Serializer / Parser component? This causes the Exception during dynamic EMF model manipulation.
* The JVM Inferrer of Xcore should be extended: pattern matcher component is accessible
 
* The scope provider used for the proposal provider can see more things than the one used by the linker -> this causes the problems during editing
 

Revision as of 08:37, 9 July 2013

Notes on IncQuery & Xcore integration

The language file has been created and the project consists of two plugins. Most of the xtext-related classes are extended from the appropriate xcore classes, but some of them has been entirely copied due to the lack of extensibility. This will be investigated later with Ed and the required changes will be performed in the xcore codebase. Try to extend and only inject new fields without copying code wherever possible.

Inferring the genmodel: The special IncQuery derived feature should be handled separately. Important note: referring any model element should be done post-linking. This is really important, for example, for the pattern reference of the derived feature during code generation phase.

Code generation for the derived feature: Two separate issues: (1) code generated into the model code and (2) code used during dynamic EMF manipulation. (1) This will be solved by the special Ecore annotations and in the similar way as Xcore does it. No XbaseCompiler will be used, only the IncQuery derived feature evaluator artifacts will be invoked with the pattern fully qualified name. (2) EStructuralFeature.SettingDelegate will be used for evaluation.

Initialization of the patterns in the pattern registry: ...

Problematic points at the moment:

  • Question regarding the resource descriptions: should the Xcore resource expose also the IncQuery artifacts?
  • How should we handle the Serializer / Parser component? This causes the Exception during dynamic EMF model manipulation.

Back to the top