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.
Difference between revisions of "VIATRA/Integration/DeveloperDocumentation/Xcore"
(→Notes on IncQuery & Xcore integration) |
|||
| Line 4: | Line 4: | ||
Inferring the genmodel: | 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. | + | The special IncQuery derived feature should be handled separately from the standard xcore EStructuralFeatures. 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: | Code generation for the derived feature: | ||
| − | Two separate issues: (1) code generated into the model code and (2) code used | + | Two separate issues: (1) code generated into the model code and (2) code used for the dynamic EMF resource. |
| − | (1) This | + | (1) This issue is solved with the special annotation provided by the querybasedfeatures.runtime plugin along with the factory for the setting delegate. |
| − | (2) | + | (2) Setting delegates are used for this case too, but this is created manually (not with the factory) using a generic query specification (it should be investigated how to access the inferred query specification for the pattern instance). Important note: the base index should be initialized in Dynamic EMF mode in this case. |
| − | + | ||
| − | + | ||
| − | + | ||
Problematic points at the moment: | Problematic points at the moment: | ||
| − | * | + | * What should be the type of the IncQuery derived feature? EAttribute or EReference? This is important because the return type is restricted in both cases. |
| − | * | + | * IMetamodelProviderService of IncQuery should be extended to look for the EPackage in the ResourceSet too |
| + | * The import mechanism used by IncQuery should be extended to also consider EPackages from the xtext index | ||
| + | * For the first time during the initialization of the Pattern Matcher Engine in Dynamic Resource mode, all of the Java classes will be loaded as Resources into the ResourceSet which takes a long time. | ||
Revision as of 09:06, 11 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 from the standard xcore EStructuralFeatures. 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 for the dynamic EMF resource. (1) This issue is solved with the special annotation provided by the querybasedfeatures.runtime plugin along with the factory for the setting delegate. (2) Setting delegates are used for this case too, but this is created manually (not with the factory) using a generic query specification (it should be investigated how to access the inferred query specification for the pattern instance). Important note: the base index should be initialized in Dynamic EMF mode in this case.
Problematic points at the moment:
- What should be the type of the IncQuery derived feature? EAttribute or EReference? This is important because the return type is restricted in both cases.
- IMetamodelProviderService of IncQuery should be extended to look for the EPackage in the ResourceSet too
- The import mechanism used by IncQuery should be extended to also consider EPackages from the xtext index
- For the first time during the initialization of the Pattern Matcher Engine in Dynamic Resource mode, all of the Java classes will be loaded as Resources into the ResourceSet which takes a long time.