VIATRA/Integration/DeveloperDocumentation/Xcore

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, however, a new feature definition will be possible with editor support (validation, proposal provider, etc.)

Overview and example

Two kinds of derived feature can be defined:

- attributes (EAttribute) with the 'incquery-derived' keyword. Naturally, the type of these features can be only primitive types.

- references (EReference) with the 'incquery-derived refers' keyword. The type of these features can be any reference type (user-defined classes for example)

The generated metamodel artifacts can be used in two different use cases:

(1) Dynamic Instance Mode: debugging of metamodels and queries are made easy with this functionality. One can develop the metamodel and queries at the same time, in the same workspace. You just need to create a dynamic instance model and you can modify your model on the fly. All the values of the features can be observed through the Properties View of Eclipse. 
(2) Using the Generated Code: the standard EMF model/edit/editor/tests code can be also generated and used in an other instance of Eclipse. 

Advanced issues

SettingDelegates for the evalutation of derived features.

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.