Scala compiler for kermeta 1

Context

For building Kermeta 2, we have done a bootstrap. It uses a preversion of the scala compiler that takes kermeta 1 model as input and generates bytecode.

As it is mainly intended for internal use and  since all should be fixed in the compiler for kermeta 2, only limited support will be provided on this preversion of the compiler.

Requirement

This compiler is deployed as a maven plugin. So you need to set up a maven environment (see maven documentation for for details on using maven). Here are the required settings:

In your $HOME/.m2, you must have a settings.xml that indicates where to find our compiler plugin. It must add repository information and plugin repository information to the following release and snapshot repository :

http://maven.irisa.fr/artifactory/public-release 

and

http://maven.irisa.fr/artifactory/public-snapshot/

(See the sample settings.xml in attachement of this article)

For maven, you may either install maven directly in your OS, or use a version embedded in eclipse (m2e for example).

Compiling your kermeta project

Step 1. provide a merge km. The plugin takes as input a merged km. (not a kmt) so you need to : right click on your main kmt file > kermeta > generate km > make sure that "Is executable" check box is checked.

Step 2. configure your maven project to use this km. In your pom.xml you need to provide an entry like:

<plugin>
  <groupId>org.kermeta.language</groupId>
  <artifactId>language.compiler.mavenplugin</artifactId>
  <version>${language.compiler.version}</version>
  <extensions>true</extensions>
  <executions>
    <execution>
      <goals>
        <goal>generate</goal>
      </goals>
      <configuration>
        <model>src/generated/km/your_executable.km</model>
        <targetGroupId>${project.groupId}</targetGroupId>
        <targetArtifactId>${project.artifactId}</targetArtifactId>
      </configuration>
    </execution>
  </executions>
</plugin>

This language.compiler.mavenplugin plugin also has some additional configuration parameters for dealing with special cases.

You'll also need some dependencies :

<dependency>
	<groupId>fr.irisa.triskell.kermeta</groupId>
	<artifactId>kermeta.model</artifactId>
	<version>${kermeta.model.version}</version>
	<exclusions>
				<exclusion>
					<groupId>org.kermeta.eclipse</groupId>
					<artifactId>org.eclipse.core.runtime</artifactId>
				</exclusion>
			</exclusions>
</dependency>
<dependency>
	<groupId>org.scala-lang</groupId>
	<artifactId>scala-library</artifactId>
	<version>${scala.version}</version>
</dependency>
<dependency>
	<groupId>org.kermeta.language</groupId>
	<artifactId>language.framework.scala</artifactId>
	<version>${framework.scala.version}</version>
</dependency>
<dependency>
	<groupId>org.kermeta.emf</groupId>
	<artifactId>emf.lib</artifactId>
	<version>${emf.version}</version>
</dependency>

Ifyour projects depends on a metamodel, you will probably need to add a dependency to the jar that contains the java code of the metamodel (ie. code generated with the genmodel)

current versions are :

<properties>
		<traceability.version>2.0.2-SNAPSHOT</traceability.version>
		<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
		<emf.version>2.7.0</emf.version>
		<scala.version>2.9.0-1</scala.version>
		<framework.scala.version>1.4.3-SNAPSHOT</framework.scala.version>
		<kermeta.model.version>1.4.0</kermeta.model.version>
		<language.compiler.version>1.4.3-SNAPSHOT</language.compiler.version>
		<osgi.version>4.2.0</osgi.version>
		<slf4j.version>1.6.1</slf4j.version>
	</properties>

Step 3. compile the generated scala code.

The following maven plugins can be used to compile the scala code generated by the previous step

<!-- Add generated source to build cycle -->
<plugin>
	<groupId>org.codehaus.mojo</groupId>
	<artifactId>build-helper-maven-plugin</artifactId>
	<version>1.7</version>
	<executions>
		<execution>
			<id>add-source</id>
			<phase>generate-sources</phase>
			<goals>
				<goal>add-source</goal>
			</goals>
			<configuration>
				<sources>
					<source>${project.build.directory}/generated-sources/kermeta</source>
				</sources>
			</configuration>
		</execution>
	</executions>
</plugin>
<!-- Scala plugin : allow to compile Scala file -->
			<plugin>
				<groupId>org.scala-tools</groupId>
				<artifactId>maven-scala-plugin</artifactId>
				<version>2.15.2</version>
				<executions>
					<execution>
						<id>scala-compile-first</id>
						<phase>process-resources</phase>
						<goals>
							<goal>add-source</goal>
							<goal>compile</goal>
						</goals>
					</execution>
					<execution>
						<id>scala-test-compile</id>
						<phase>process-test-resources</phase>
						<goals>
							<goal>testCompile</goal>
						</goals>
					</execution>
				</executions>
				<configuration>
					<jvmArgs>
						<jvmArg>-Xmx1024m</jvmArg>
					</jvmArgs>
				</configuration>
			</plugin>

Step 4. run the result

The compiler has generated some MainRunner.scala class as an entry point you can run standalone using the maven target scala:run.

More complex scenario are also possible, this is now just some bytecode that you can embed in other java application. simply have a look to the MainRunner for correct initialization.

Running samples

As said in the introduction we use this for kermeta 2 bootstrap. They can be anaylzed for understanding how to deal with the pom.xml. You have some sample of that in the svn :

https://scm.gforge.inria.fr/svn/kermeta/trunk/org/kermeta/language/org.kermeta.language.ecore2km

https://scm.gforge.inria.fr/svn/kermeta/trunk/org/kermeta/language/org.kermeta.language.resolver

https://scm.gforge.inria.fr/svn/kermeta/trunk/org/kermeta/language/org.kermeta.language.merger.binarymerger

Known limitations

Here is a list of main known limitation of the resulting code.

The compiled code isn't thread safe (mainly due to EMF limitations). The user needs to add protection against concurrent run.