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"

(→‎Notes on IncQuery & Xcore integration)
Line 1: Line 1:
−
= Notes on IncQuery & Xcore integration =
+
= Aim of the project =
  
−
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.  
+
The Xcore project aims to provide a textual syntax for the definition of EMF metamodels. You can use it not only to specify the structure of your model, but also the behavior of your operations and derived features as well as the conversion logic of your data types. It eliminates the dividing line between modeling and programming, combining the advantages of each.
  
−
Inferring the genmodel:
+
Integration with IncQuery means that we would like to make it possible to use the powerful pattern language of IncQuery in Xcore to define derived features. The integration aims to be as seamless as possible, that is, the original xcore editing functionalities are all available, only a new feature definition will be possible with editor support (validation, proposal provider, etc.)
−
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:
+
= Overview =
−
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
+
= Example =
−
* 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.
+
= Further TODOs =
−
* Edit and editor plugins are not generated at the moment, however if the projects are created the code is generated properly.
+
 +
- There are certain changes in the IncQuery codebase which should be investigated and if appropriate, applied to master.
 +
(1) EPackage importing
 +
(2) MetaModelProviderService should consider the EPackage which is a child of the XcoreResource (in the ResourceSet)
 +
(3) Custom JavaProjectProvider is needed: when the dynamic instance model is loaded the ResourceSet's type will be AdapterFactoryEditingDomainResourceSet, which will not be handled correctly by the default XtextResourceSetBasedProjectProvider class.  
 +
 
 +
- Xcore & EMF related changes
 +
(1) EcoreEditor: the Xcore ResourceSet should be read only. The read only file extensions are hard coded at the moment into this class.

Revision as of 09:16, 26 July 2013

Aim of the project

The Xcore project aims to provide a textual syntax for the definition of EMF metamodels. You can use it not only to specify the structure of your model, but also the behavior of your operations and derived features as well as the conversion logic of your data types. It eliminates the dividing line between modeling and programming, combining the advantages of each.

Integration with IncQuery means that we would like to make it possible to use the powerful pattern language of IncQuery in Xcore to define derived features. The integration aims to be as seamless as possible, that is, the original xcore editing functionalities are all available, only a new feature definition will be possible with editor support (validation, proposal provider, etc.)

Overview

Example

Further TODOs

- There are certain changes in the IncQuery codebase which should be investigated and if appropriate, applied to master. 

(1) EPackage importing 
(2) MetaModelProviderService should consider the EPackage which is a child of the XcoreResource (in the ResourceSet)
(3) Custom JavaProjectProvider is needed: when the dynamic instance model is loaded the ResourceSet's type will be AdapterFactoryEditingDomainResourceSet, which will not be handled correctly by the default XtextResourceSetBasedProjectProvider class.

- Xcore & EMF related changes 

(1) EcoreEditor: the Xcore ResourceSet should be read only. The read only file extensions are hard coded at the moment into this class.
Retrieved from "https://wiki.eclipse.org/index.php?title=VIATRA/Integration/DeveloperDocumentation/Xcore&oldid=344488"

Back to the top