This page is now maintained in the Eclipse wiki: http://wiki.eclipse.org/EMFIncQuery/DeveloperDocumentation/DevEnvironment
The rest of the page is preserved here only for archive purposes.
The project is available at http://eclipse.org/incquery. To download it, you shoud point your Git client to http://git.eclipse.org/c/incquery/org.eclipse.incquery.git/ and after obtaining a local git repository on your hard disk, import the Eclipse plug-in projects under the plugins/ subfolder into your Eclipse workspace.
For details, see the Eclipse EGit help and the Git tutorial from Lars Vogel.
Important: Do not forget to set up your name and email address in your local Git repository - Git identifies your commits using your email address.
The projects contain both manually written and generated code. They are placed in different source folders: all src folders contain only manually written code, all src-gen and xtend-gen folders contain generated code.
In order to generate editor and parser code, execute the mwe2 code generation workflows by right clicking to the files below, and selecting Run as | MWW2 Workflow in the following order:
After issuing code generation, Eclipse should warn you about compile errors in the projects. To resolve them (by generating the missing code), click "Proceed". All workflow files require about 30-60 seconds to run - be patient.
Xtend files are used for code generation and some other reasons in language projects and tests. After the Xtext code generation workflows are executed, it might be required to clean the projects with xtend files, otherwise they do not find the freshly generated java code. (It is the easiest to issue a clean all and then build the entire workspace.)
Zest and Graphiti are marked as dependencies of optional supplementary components. You can either install these external plug-ins from the Juno update site, or just close the projects depending on them (as they are non-essential).
Important to know:
In this example https://github.com/ujhelyiz/EMF-IncQuery-Examples/tree/master/school/school.instancemodel you can find two school instance models with a school, years, classes, students, teachers, and courses.
If you create a new plug-in project, you don’t need Activator (on the second wizard page, uncheck the „Generate an activator, a Java class that controls the plug-in’s life cycle”).
This project contains:
The basic and model manipulation test cases in .xtend file
An example model manipulation test, where change the School "Budapest University of Technology and Economics" name to "BME":
Snapshot files
You can create an .eiqsnapshot file in Query Explorer: right click on a pattern result or the root of the patterns - Save EMF-IncQuery snapshot. Important: this file contains relative path to the instance model, so if you move this file to another folder, you need to check the path.
JUnit run configurations. You can run the tests: right click - run as - SchoolTests
As parsing eiq files requires custom components registered during the pattern load process, the built-in Reflective Ecore Editor cannot open eiq files. To overcome this, an Xtext-specific reflective editor is needed. A short description of the reflective editor component is available in the blog post Reflective Tree Editor for Xtext-based Languages. Downloads are available from:
Additionally, the registration of the reflective editor is created in an external project, as it is not planned to distribute this editor together with EMF-IncQuery (and manage its external dependency). For the same reason, the plug-in is only available in source form at Github,
EMF-IncQuery uses Maven/Tycho for continous integration builds.
There are two important things to configure for adding a new project to the build:
An example commit for executing all these steps (with the creation of a new project) is: https://github.com/ujhelyiz/EMF-IncQuery/commit/4b523260c94ddb2605ce1088... (Note that the addition of a source plugin is not included).
A project needs to have a pom.xml file in the project root for the build configuration. In most cases, this build configuration is very simple, as all required configurations are inherited either from the project type (Eclipse plug-in project) or the root project. Basically, there are two configuration types used in the project:
To create such a configuration file for a new project, the recommended solution is to copy an existing corresponding project configuration, and replace the plug-in identifier.
Warning! If a project for any reason uses a different version number then the base IncQuery project (currently 0.7.0.qualifier), it is important to add the version information to the project, replacing '.qualifier' with '-SNAPSHOT' (currently 0.7.0-SNAPSHOT).
Additionally, the new project needs to be added to the parent project (org.eclipse.viatra2.patternlanguage.update):
The pom.xml file contains a module section where a list of submodules are presented - it needs to be extended with a new submodule describing the project location.
The existing feature.xml file has to be extended with the new plug-in as a contained plug-in id.
Additionally, a source plug-in might need to be added to (a possibly different feature). The id of the source plug-in is: «plugin.id».source. The feature.xml editor reports warnings as such projects are non-existent in the project; however they are created during the build and included.
Currently most source plug-ins are added only to the SDK bundle, with the notable exceptions of runtime bundles that are added to the runtime features.
Creating a new feature project works similarly to creating a new plug-in project, but the feature builder pom.xml files are more simple. The recommended way of creating a new feature is to copy and existing one, and modifying the identifier, descriptions and contained plug-ins (and possibly features). The feature also needs to be registered into the root projects module section.
Additionally, this feature needs to be added to the update site. For this reason, the feature needs to be registered in the category.xml file stored in the update site project - the category.xml file has a form-based editor.