VIATRA/UserDocumentation/Build

Maven integration

Since version 0.8.0, VIATRA Query supports building VIATRA Query projects in a Maven-based builds by generating the pattern matcher code from the vql files.

Requirements:

• The maven compiler requires Maven 3.1 to function correctly. In some cases Maven 3.0.5 is enough, but there are some dependency issues that are problematic for this version. Versions before Maven 3.0 will not work at all. See bug 478437 for details.

Known limitations:

• bug 434794 - Code generation for integration components (e.g. validation framework, derived features) is not supported.
• The VIATRA Query project is not available from Maven Central, only from repo.eclipse.org.
• There is no maven archetype support: it is not possible to generate an Eclipse-less project automatically, that works with VIATRA Query. However, manually created projects can be built with the existing compiler.

Repository

Maven components are available from the Eclipse maven repository with the following url: https://repo.eclipse.org/content/groups/viatra2/

The following three maven-projects should be used:

1. org.eclipse.viatra:viatra-query-runtime - dependency for the VIATRA Query runtime, without support for generic API
2. org.eclipse.viatra:viatra-maven-plugin - Maven code generator
3. org.eclipse.viatra:viatra-query-language - dependency for the VIATRA Query with support for generic API (requires many more dependencies - only use if required)

To use VIATRA Query features, add the repository and the required dependencies to your Maven project:

<!-- use this in your project's pom.xml file -->
<properties>
	<viatra.version>1.2.1</viatra.version>
</properties>
 
<dependencies>
	<dependency>
		<groupId>org.eclipse.viatra</groupId>
		<artifactId>viatra-query-runtime</artifactId>
		<version>${viatra.version}</version>
	</dependency>
 
	<dependency>
		<groupId>org.eclipse.viatra</groupId>
		<artifactId>viatra-maven-plugin</artifactId>
		<version>${viatra.version}</version>
	</dependency>
 
	<!-- requires many more dependencies - only use if required -->
	<dependency>
		<groupId>org.eclipse.viatra</groupId>
		<artifactId>viatra-query-language</artifactId>
		<version>${viatra.version}</version>
	</dependency>
</dependencies>
 
<repositories>
	<repository>
		<id>viatra</id>
		<url>https://repo.eclipse.org/content/groups/viatra2/</url>
	</repository>
</repositories>

viatra-maven-plugin

The maven plugin requires information from the used EMF packages and additionally the EMF packages should be able loaded as well. For this reason, it is important to add references to EPackages and Genmodels together with the corresponding dependencies.

Additional notes

• Package reference is added either by file path (usually relative) to the .genmodel file or fully qualified name of the Ecore Package class that is available on the classpath. Note that if the class is in the same plugin as the query file, the class based reference will not work as compilation will happen at a later build phase than the generation.
• Each package that is imported or is used by any imported package must be listed in the metamodels section.
• Dependencies are transitive, so you don't need to specify all dependencies in all POM.XML files. Note that in some cases you need to add extra dependencies with specific versions (e.g. emf.core) if your genmodel requires a higher version than what is provided by the viatra-maven-plugin. This way you can redefine the emf versions used by the generator.

Example POM.XML

Example generator (based on CPS example):

<pluginRepositories>
  <pluginRepository>
    <id>viatra</id>
    <url>https://repo.eclipse.org/content/groups/viatra2/</url>
  </pluginRepository>
</pluginRepositories>
<build>
<plugins>
<!-- Using maven-clean-plugin to remove previously generated code -->
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-clean-plugin</artifactId>
  <version>2.5</version>
  <executions>
    <execution>
      <phase>clean</phase>
      <goals>
        <goal>clean</goal>
      </goals>
      <configuration>
        <filesets>
          <fileset>
            <!-- Generated code folder -->
            <directory>src-gen</directory>
            <includes>
              <include>**/*</include>
            </includes>
          </fileset>
        </filesets>
      </configuration>
    </execution>
  </executions>
</plugin>
<!-- Setting up generator -->
<plugin>
  <groupId>org.eclipse.viatra</groupId>
  <artifactId>viatra-maven-plugin</artifactId>
  <version>${viatra.version}</version>
  <!-- Binding execution to the code generation lifecycle phase -->
  <executions>
    <execution>
      <goals>
        <goal>generate</goal>
      </goals>
    </execution>
  </executions>
  <configuration>
    <!-- Output directory - required -->
    <outputDirectory>src-gen</outputDirectory>
      <metamodels>
        <metamodel>
          <!-- Java class for the EMF EPackage - use this if generated EMF code is in the classpath -->
          <packageClass>school.SchoolPackage</packageClass>
          <!-- genmodel file used for generating the EMF model classes - use this if EMF model is in the same project -->
          <!-- <genmodelUri>../school/model/school.genmodel</genmodelUri> -->
        </metamodel>
      </metamodels>
  </configuration>
  <dependencies>
    <!-- Dependency required for the school project (that contains the generated EPackage) -->
    <dependency>
      <groupId>org.eclipse.viatra.query</groupId>
      <artifactId>school</artifactId>
      <version>1.2.0</version>
    </dependency>
  </dependencies>
</plugin>
</plugins>
</build>

Troubleshooting

Cyclic linking

In a project that contains multiple pattern definition files, there is a slight chance you get an error message like follows:

ERROR:Cyclic linking detected : PatternCall.patternRef->PatternCall.patternRef

This is a known issue we are working to fix; see bug 464120 and bug 480652 for details about the underlying issues.

As workaround, we suggest the following things:

• First, make sure that you have added types for all parameters (if possible, basically for EClasses see bug 399620), because that avoids this issue.
• If that is not enough, you have to ensure that the vql files are processed in calling order: all patterns are to be processed before they are used in a pattern call. This can be achieved either by moving patterns between vql files, or by renaming your .vql files so that the files that call patterns from other files should have names lexicographically greater than the referenced files.

Example:

// _0_util.vql

pattern utilityPattern(...) {
  ...
}

// _1_logic.vql

pattern myPattern(...) {
  find utilityPattern(...);
}

Validation errors

If you get type errors during validation such as

ERROR:foo cannot be resolved.

or

ERROR:Ambiguous variable type defintions: [Foo, Bar], type cannot be selected

although the query files are valid in Eclipse, check the references in your Ecore files (by opening them with a text editor and looking for relative URIs). In Eclipse, they are most probably resolved as platform: URIs; however, during the Maven build, they are resolved as file: URIs. So if your projects are not in a flat directory structure in the file system but reside in different subdirectories, references to types can't be resolved.

A possible workaround is to create symlinks in the root project directory to the projects residing in subdirectories:

<pluginRepositories>
	<pluginRepository>
		<id>pyx4me</id>
		<url>http://www.pyx4me.com/maven2/</url>
	</pluginRepository>
</pluginRepositories>
<build>
	<plugins>
		<plugin>
			<groupId>com.pyx4j</groupId>
			<artifactId>maven-junction-plugin</artifactId>
			<version>1.0.3</version>
			<executions>
				<execution>
					<id>link</id>
					<goals>
						<goal>link</goal>
					</goals>
					<phase>initialize</phase>
				</execution>
				<execution>
					<id>unlink</id>
					<goals>
						<goal>unlink</goal>
					</goals>
					<phase>clean</phase>
				</execution>
				<execution>
					<id>unlink2</id>
					<goals>
						<goal>unlink</goal>
					</goals>
					<phase>package</phase>
				</execution>
			</executions>
			<configuration>
				<links>
					<link>
						<src>${basedir}/../subdirectory/metamodelProject</src>
						<dst>${basedir}/../metamodelProject</dst>
					</link>
				</links>
			</configuration>
		</plugin>
	</plugins>
</build>