Using the JDT compiler in normal Maven builds

The Maven Compiler Plugin can be customized to use a different compiler than Javac. One of the options listed for the compilerId setting is “eclipse“. To use it you will have to add a dependency to the plexus-compiler-eclipse (current version: 1.8.1).

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-compiler-plugin</artifactId>
	<configuration>
		<compilerId>eclipse</compilerId>
		<source>1.5</source>
		<target>1.5</target>
		<optimize>true</optimize>
	</configuration>
	<dependencies>
		<dependency>
			<groupId>org.codehaus.plexus</groupId>
			<artifactId>plexus-compiler-eclipse</artifactId>
			<version>1.8.1</version>
			<scope>runtime</scope>
		</dependency>
	</dependencies>
</plugin>

A pitfall here is that the compiler compliance level is not automatically set through the target setting. You have to set also optimize=true. Otherwise Java 1.5 sources won’t compile.

The plexus-compiler-eclipse (version 1.8.1) takes a rather old version of JDT, 3.3.0-v_771. To use another version you will have to deploy a newer version of JDT yourself into your repository and list this dependency before plexus-compiler-eclipse.

Tycho build works also for oAW 4.3 projects

Yesterday I showed how Xtext 1.0 projects can be build with Maven Tycho. So why shouldn’t the same setup don’t work for ‘old’ openArchitectureWare Xpand projects? This works like a charm. I took the simple project that the Xpand project wizard creates and added the POM, and it worked! You can download the sample project here. See the POM below, a setup for other oAW Xpand projects should be rather similar.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>p2.osgi.bundle</groupId>
	<artifactId>org.openarchitectureware.example.xpand.tycho</artifactId>
	<version>1.0.0</version>
	<packaging>eclipse-plugin</packaging>
	<name>org.openarchitectureware.example.xpand.tycho</name>

	<properties>
		<version.tycho>0.9.0</version.tycho>
	</properties>

	<build>
		<resources>
			<resource>
				<directory>src</directory>
			</resource>
		</resources>
		<plugins>
			<plugin>
				<groupId>org.sonatype.tycho</groupId>
				<artifactId>tycho-maven-plugin</artifactId>
				<version>${version.tycho}</version>
				<extensions>true</extensions>
			</plugin>
			<plugin>
				<groupId>org.sonatype.tycho</groupId>
				<artifactId>target-platform-configuration</artifactId>
				<version>${version.tycho}</version>
				<configuration>
					<resolver>p2</resolver>
				</configuration>
			</plugin>
			<plugin>
				<groupId>org.fornax.toolsupport</groupId>
				<artifactId>fornax-oaw-m2-plugin</artifactId>
				<version>3.1.0-SNAPSHOT</version>
				<configuration>
					<workflowEngine>oaw</workflowEngine>
					<workflowDescriptor>workflow/generator.oaw</workflowDescriptor>
				</configuration>
				<executions>
					<execution>
						<phase>generate-sources</phase>
						<goals>
							<goal>run-workflow</goal>
						</goals>
					</execution>
				</executions>
			</plugin>
			<plugin>
				<artifactId>maven-clean-plugin</artifactId>
				<version>2.4.1</version>
				<configuration>
					<filesets>
						<fileset>
							<directory>src-gen</directory>
							<includes>
								<include>**/**</include>
							</includes>
						</fileset>
					</filesets>
				</configuration>
			</plugin>
		</plugins>
	</build>
	<repositories>

		<repository>
			<id>p2.openarchitectureware</id>
			<url>http://www.openarchitectureware.org/updatesite/milestone/</url>
			<layout>p2</layout>
		</repository>
		<repository>
			<id>p2.eclipse.helios</id>
			<url>http://download.eclipse.org/releases/helios</url>
			<layout>p2</layout>
		</repository>
		<!-- At the moment the Fornax plugin is only available as snapshot -->
		<repository>
			<id>fornax-snapshots</id>
			<url>http://www.fornax-platform.org/archiva/repository/snapshots/</url>
			<releases>
				<enabled>false</enabled>
			</releases>
			<snapshots>
				<enabled>true</enabled>
			</snapshots>
		</repository>
	</repositories>
	<pluginRepositories>
		<pluginRepository>
			<id>fornax-snapshots</id>
			<url>http://www.fornax-platform.org/archiva/repository/snapshots/</url>
			<releases>
				<enabled>false</enabled>
			</releases>
			<snapshots>
				<enabled>true</enabled>
			</snapshots>
		</pluginRepository>
	</pluginRepositories>
</project>

Building Xtext projects with Maven Tycho

Last year I showed how Xtext 0.7.2 projects can be build with Maven. It requires the installation of all related plugins as Maven artifacts in a Maven2 repository, which is a rather hard and error prone task. I was asked many times since then whether I would install Xtext 1.0 artifacts or even milestone versions into the openArchitectureWare Maven2 repository. Although I can really understand this requirement my hope was that I could avoid this and show a way to enable the build with Maven Tycho. Now the time has come that Tycho is mature enough and finally I had the time to do the necessary extension for the Fornax Maven Workflow Plugin to support the recently added MWE2 workflow engine, which is used from Xtext now as default. Maven Tycho and the Fornax plugin will allow to build Xtext projects in the most natural way possible.

A basic requirement for software builds is that everything can be build just from the sources. Also it is a good practice that no generated sources are checked in into a source repository. Unfortunately this often does not hold for Xtext projects, since it is a quite hard task to execute the Xtext generator in a build process. Yes, it is possible, but until now users often have to solve it again and again. Search the net, most projects seen there will just check in all the sources. The Fornax plugin and Maven will standardize this behavior.

What do you need to enable Xtext DSL builds with Tycho? Not much. Basically a Maven 3 installation (the beta is enough) and access to the internet to access the public repositories. A better idea is to use a repository manager in the intranet (like Nexus) to act as proxy for the public repositories. You will have to add some POMs to your projects. That’s it.

I’ll show now how to enable the basic project that you get from the Xtext project wizard get build with Maven Tycho.

1. Install Maven 3

Download Maven 3 from Apache, unpack it and put the bin folder on your path. Check the installation by typing ‘mvn –version‘ in a shell. You should something like this:

mvn --version
Apache Maven 3.0-beta-1 (r935667; 2010-04-19 19:00:39+0200)
Java version: 1.6.0_20
Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
Default locale: de_DE, platform encoding: MacRoman
OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac"

2. Create the Xtext project

Select in Eclipse File / New / Project / Xtext Project and leave all the defaults. The project name should be org.xtext.example.mydsl for this tutorial. The projects will be created and almost empty for now. The aim is to get everything build by just adding the POMs.

3. Adjust plugin manifests

With the default Manifests the build does not execute successfully. The build fails because it has problems to resolve the logging infrastructure. It is sufficient to add Import-Package entries to resolve SLF4J and Logback. Open the plugin Manifest of the org.xtext.example.mydsl project, go to the Dependencies page and add the following Imported Packages:

  • ch.qos.logback.classic
  • ch.qos.logback.core.joran.spi
  • org.slf4j

For each of them open the Properties dialog and set the “optional” flag. Otherwise you could get problems when deploying these plugins. (Thanks to Christian Amman for this tip!)

Open the Manifest of org.xtext.example.mydsl.generator, add the same packages and additionally

  • org.apache.commons.logging

Again, set the imported packages to optional.

4. Add POM files

Each project will get a POM file. A Parent POM will contain the common settings and will act as a reactor POM also. Normally the Parent POM is placed in the directory above the modules, or here the plugin projects. This would be the workspace root. In this example we will place the Parent POM in the DSL grammar project. To make builds easier this POM will have the default name pom.xml. On the other side we have to add also a POM for the grammar project itself. Since it will be in the same directory we have to find another name, and we will call it pom-grammar.xml. For the other projects (.generator and .ui) we will stay with pom.xml.

4.1 org.xtext.example.mydsl/pom.xml

The Parent POM configures the Tycho plugins and aggregates the grammar project, UI project and the generator. Also the required repositories are configured here. Note that the folder “src” is added as resource path, this will add this folder to the classpath. The workflow execution would fail if the workflow module cannot be found on the classpath.

<!--?xml version="1.0" encoding="UTF-8"?-->
	4.0.0
	p2.osgi.bundle
	org.xtext.example.mydsl.parent
	1.0.0
	pom
	org.xtext.example.mydsl.MyDsl - Parent

		0.9.0

		./pom-grammar.xml
		../org.xtext.example.mydsl.ui
		../org.xtext.example.mydsl.generator

		<!-- The src directory must be named as resource dir to put it on the build classpath. This is required to resolve the 			workflow module named in the .mwe2 file -->

			src

				org.sonatype.tycho
				tycho-maven-plugin
				${version.tycho}
				true

				org.sonatype.tycho
				target-platform-configuration
				${version.tycho}

					p2

					org.fornax.toolsupport
					fornax-oaw-m2-plugin
					3.1.0-SNAPSHOT

						mwe2

							generate-sources
								run-workflow

			p2.eclipse.helios
			http://download.eclipse.org/releases/helios
			p2

		<!-- At the moment the Fornax plugin is only available as snapshot -->

			fornax-snapshots
			http://www.fornax-platform.org/archiva/repository/snapshots/

				false

				true

org.xtext.example.mydsl/pom-grammar.xml

The build of the grammar project needs to execute the workflow src/org/xtext/example/mydsl/GenerateMyDsl.mwe2. All other settings are already managed by the parent.

<!--?xml version="1.0" encoding="UTF-8"?-->
	4.0.0

		p2.osgi.bundle
		org.xtext.example.mydsl.parent
		1.0.0
		../org.xtext.example.mydsl/pom.xml

	org.xtext.example.mydsl
	eclipse-plugin
	org.xtext.example.mydsl.MyDsl - Grammar

				org.fornax.toolsupport
				fornax-oaw-m2-plugin

					src/org/xtext/example/mydsl/GenerateMyDsl.mwe2

org.xtext.example.mydsl.ui/pom.xml

The build configuration of the UI plugin is even easier. Only the reference to the parent and the minimum project coordinates need to be configured.

<!--?xml version="1.0" encoding="UTF-8"?-->
	4.0.0

		p2.osgi.bundle
		org.xtext.example.mydsl.parent
		1.0.0
		../org.xtext.example.mydsl/pom.xml

	org.xtext.example.mydsl.ui
	eclipse-plugin
	org.xtext.example.mydsl.MyDsl - UI

org.xtext.example.mydsl.generator/pom.xml

The generator plugin must execute its workflow. Note that the src directory and the compile directory of the grammar project are set as resource directory.

<!--?xml version="1.0" encoding="UTF-8"?-->
	4.0.0

		p2.osgi.bundle
		org.xtext.example.mydsl.parent
		1.0.0
		../org.xtext.example.mydsl/pom.xml

	org.xtext.example.mydsl.generator
	eclipse-plugin
	org.xtext.example.mydsl.MyDsl - Generator

			src
			<!-- Add the grammar classes to the classpath -->
			../org.xtext.example.mydsl/target/classes

				org.fornax.toolsupport
				fornax-oaw-m2-plugin

					mwe2
					src/workflow/MyDslGenerator.mwe2

5. Execute the build

Now the build should be executable. Run ‘mvn clean install‘ in the root of the org.xtext.example.mydsl project. Here is an excerpt of the console log you should get. The complete log can be viewed here.

mvn install
[INFO] Scanning for projects...
[WARNING] No explicit target runtime environment configuration. Build is platform dependent.
[INFO] Resolving target platform for project MavenProject: p2.osgi.bundle:org.xtext.example.mydsl:1.0.0 @ /Users/thoms/temp/tycho/trunk/trunk/org.xtext.example.mydsl/pom-grammar.xml
log4j:WARN No appenders could be found for logger (org.apache.commons.httpclient.HttpClient).
log4j:WARN Please initialize the log4j system properly.
[INFO] Adding repository http://download.eclipse.org/releases/helios
[INFO] Adding repository http://download.eclipse.org/releases/helios
[WARNING] No explicit target runtime environment configuration. Build is platform dependent.
[INFO] Resolving target platform for project MavenProject: p2.osgi.bundle:org.xtext.example.mydsl.ui:1.0.0 @ /Users/thoms/temp/tycho/trunk/trunk/org.xtext.example.mydsl.ui/pom.xml
[INFO] Adding repository (cached) http://download.eclipse.org/releases/helios
[WARNING] No explicit target runtime environment configuration. Build is platform dependent.
[INFO] Resolving target platform for project MavenProject: p2.osgi.bundle:org.xtext.example.mydsl.generator:1.0.0 @ /Users/thoms/temp/tycho/trunk/trunk/org.xtext.example.mydsl.generator/pom.xml
[INFO] Adding repository (cached) http://download.eclipse.org/releases/helios
[WARNING] No explicit target runtime environment configuration. Build is platform dependent.
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO]
[INFO] org.xtext.example.mydsl.MyDsl - Parent
[INFO] org.xtext.example.mydsl.MyDsl - Grammar
[INFO] org.xtext.example.mydsl.MyDsl - UI
[INFO] org.xtext.example.mydsl.MyDsl - Generator
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building org.xtext.example.mydsl.MyDsl - Parent 1.0.0
[INFO] ------------------------------------------------------------------------
....
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] org.xtext.example.mydsl.MyDsl - Parent ............ SUCCESS [0.681s]
[INFO] org.xtext.example.mydsl.MyDsl - Grammar ........... SUCCESS [26.418s]
[INFO] org.xtext.example.mydsl.MyDsl - UI ................ SUCCESS [3.103s]
[INFO] org.xtext.example.mydsl.MyDsl - Generator ......... SUCCESS [10.844s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS

5. Miscalleneous

5.1 ANTLR 3 download

Xtext relies on ANTLR 3, which cannot be hosted at Eclipse.org due to incompatible licenses. Therefore Xtext has introduced an automatic download (FYI: This behavior is implemented in AntlrToolFacade) that you have to confirm once:

*ATTENTION*
It is recommended to use the ANTLR 3 parser generator (BSD licence - http://www.antlr.org/license.html).
Do you agree to download it (size 1MB) from 'http://download.itemis.com/antlr-generator-3.0.1.jar'? (type 'y' or 'n' and hit enter)

Now an automatic build is not so responsive to questions like these. The plugin will confirm this download automatically.

5.2 Workflow execution problems

If the Maven plugin does not execute the MWE2 workflow properly it is not so responsive at the moment to name the root cause. But when running the Maven command with “-X” it will output the full Java command including classpath to the console. Copy the full command and try to execute it from the same directory. This might help to detect the problem you have.

/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bin/java -classpath /Users/thoms/.m2/repository/p2/osgi/bundle/org.eclipse.xpand/1.0.0.v201006150611/org.eclipse.xpand-1.0.0.v201006150611.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.eclipse.xtend/1.0.0.v201006150611/org.eclipse.xtend-1.0.0.v201006150611.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.eclipse.emf.mwe.core/1.0.0.v201006150535/org.eclipse.emf.mwe.core-1.0.0.v201006150535.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.eclipse.emf.ecore/2.6.0.v20100614-1136/org.eclipse.emf.ecore-2.6.0.v20100614-1136.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.eclipse.emf.common/2.6.0.v20100614-1136/org.eclipse.emf.common-2.6.0.v20100614-1136.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.apache.commons.cli/1.0.0.v20080604-1500/org.apache.commons.cli-1.0.0.v20080604-1500.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.eclipse.emf.mwe2.runtime/1.0.0.v201006150446/org.eclipse.emf.mwe2.runtime-1.0.0.v201006150446.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/com.ibm.icu/4.2.1.v20100412/com.ibm.icu-4.2.1.v20100412.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.eclipse.xtext/1.0.0.v201006170321/org.eclipse.xtext-1.0.0.v201006170321.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.eclipse.emf.ecore.xmi/2.5.0.v20100521-1846/org.eclipse.emf.ecore.xmi-2.5.0.v20100521-1846.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.eclipse.xtext.util/1.0.0.v201006170321/org.eclipse.xtext.util-1.0.0.v201006170321.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/com.google.collect/0.8.0.v201006170321/com.google.collect-0.8.0.v201006170321.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/com.google.inject/2.0.0.v201003051000/com.google.inject-2.0.0.v201003051000.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.antlr.runtime/3.0.0.v200803061811/org.antlr.runtime-3.0.0.v200803061811.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.eclipse.emf.mwe.utils/1.0.0.v201006150535/org.eclipse.emf.mwe.utils-1.0.0.v201006150535.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.eclipse.emf.mwe2.launch/1.0.0.v201006150907/org.eclipse.emf.mwe2.launch-1.0.0.v201006150907.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.eclipse.emf.mwe2.language/1.0.0.v201006150907/org.eclipse.emf.mwe2.language-1.0.0.v201006150907.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.eclipse.xtext.common.types/1.0.0.v201006170321/org.eclipse.xtext.common.types-1.0.0.v201006170321.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.eclipse.xtend.typesystem.emf/1.0.0.v201006150611/org.eclipse.xtend.typesystem.emf-1.0.0.v201006150611.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/ch.qos.logback.classic/0.9.19.v20100519-1505/ch.qos.logback.classic-0.9.19.v20100519-1505.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/ch.qos.logback.core/0.9.19.v20100419-1216/ch.qos.logback.core-0.9.19.v20100419-1216.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.apache.commons.logging/1.1.1.v201005080502/org.apache.commons.logging-1.1.1.v201005080502.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.slf4j.api/1.5.11.v20100519-1910/org.slf4j.api-1.5.11.v20100519-1910.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/ch.qos.logback.slf4j/0.9.19.v20100519-1910/ch.qos.logback.slf4j-0.9.19.v20100519-1910.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.slf4j.log4j/1.5.11.v20100419-1106/org.slf4j.log4j-1.5.11.v20100419-1106.jar org.eclipse.emf.mwe2.launch.runtime.Mwe2Launcher /Users/thoms/Development/workspaces/oaw-v5-test/org.xtext.example.mydsl.generator/src/workflow/MyDslGenerator.mwe2

5.3 Fornax Plugin Snapshot version

The Maven plugin org.fornax.toolsupport:fornax-oaw-m2-plugin is not released yet. Yesterday I have added the necessary support for MWE2 and deployed a snapshot version 3.1.0-SNAPSHOT. Some minor issues have to be solved before it will be released.

5.4 Missing log output

The plugin forks a JVM with help of the Java ant task type. At the moment the output from the forked JVM does not get redirected to the Plugin’s log. This is one issue to solve for the Plugin before release. It makes debugging problems a bit harder, but when copying the executed Java command that you get from the debug output and execute yourself you get a better impression of the error.

5.5 Download sources

For your convenience you can download the example project here.

Tycho slides uploaded

Yesterday I gave a presentation about Maven 3 and Tycho for the Dortmunder Vortragsreihe, a public event series from itemis. A similar talk I gave at the JAX 2010 conference last week, but with less presentation time and thus a less content. I worked on learning about Tycho now quite a while and some bugs and the current lack of documentation led to some restless evenings in the hotel. At the end I wanted to have a continuous build for a non trivial RCP application build. As the example project I wanted to build I took Kai Tödter’s MP3Manager RCP sample project. Finally I got the project building with Tycho. There are still some issues, especially with the product export. I will use this project now to create situations that show bugs and report them to the Tycho team. They are working really hard at the moment to improve Tycho, and I’m sure that many issues will be resolved soon.

Anyway, the slides that I used yesterday were just uploaded, and I hope they will be useful to get started with Tycho.

Maven 3 / Tycho

In the future I will report more about Tycho, so stay tuned!

Mavenizing the project structure of Xtext projects

The structure of typical Xtext projects does not match the standard layout of Maven projects. Xtext projects more adhere to standard Eclipse project layout, which means

  • manual implemented Java sources are in folder /src
  • the plugin Manifest is /META-INF/MANIFEST.MF
  • generated sources go to /src-gen

In my customer’s project Xtext sources are built with Maven, and also the sources produced by Xtext are produced within the Maven build, using the Fornax Workflow Maven plugin. Until now we have adjusted the Maven build to match the standard Xtext project structure, which requires some configuration in the build section of the POM like follows:

   <build>
        <sourceDirectory>src</sourceDirectory>
        <resources>
            <resource>
                <directory>src</directory>
            </resource>
            <resource>
                <directory>src-gen</directory>
            </resource>
        </resources>
        <plugins>
            <plugin>
                <groupId>org.fornax.toolsupport</groupId>
                <artifactId>fornax-oaw-m2-plugin</artifactId>
                <version>3.0.3</version>
                <configuration>
                    <checkFilesets>
                        <checkFileset>
                            <directory>${basedir}</directory>
                            <includes>
                                <include>src/**</include>
                            </includes>
                            <excludes>
                                <exclude>**/.svn/**</exclude>
                            </excludes>
                        </checkFileset>
                    </checkFilesets>
                    <outletSrcDir>src-gen</outletSrcDir>
                    <outletSrcOnceDir>src</outletSrcOnceDir>
                    <outletResOnceDir>resources</outletResOnceDir>
                    <properties></properties>
                    <workflowDescriptor>xtext/example/GenerateMyDsl.mwe</workflowDescriptor>
                    <workflowEngine>mwe</workflowEngine>
                </configuration>
                <executions>
                    <execution>
                        <phase>generate-sources</phase>
                        <goals>
                            <goal>run-workflow</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>build-helper-maven-plugin</artifactId>
                <executions>
                    <execution>
                        <id>add-source</id>
                        <phase>generate-sources</phase>
                        <goals>
                            <goal>add-source</goal>
                        </goals>
                        <configuration>
                            <sources>
                                <source>src</source>
                            </sources>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>

Now requirements changed and the project structure should conform to the Maven structure, which means:

  • src/main/java: Contains hand-written Java code
  • src/main/resources: All non-Java hand-written code (including Workflow and Xtext grammar)
  • target/generated/java: Contains generated code

Another requirement  from the build team is that the actual output directory ‘target’ should be configurable. This means mainly that we have to use properties that Maven uses to refer to the source and target directories (project.build.sourceDirectory and project.build.directory), so that the build could override just these settings by passing a system property and all output gets produced to and compiled from an alternative directory structure.

Of course this is possible with small changes, but you have to know where.

Xtext Generator Worklow

In order to produce the output of the Xtext generator to different directories than default (src, src-gen => src/main/java, target/generated/java) the MWE workflow file has to be changed. For the generator component we have to override the properties srcPath and srcGenPath. Further, these output directories should be parametrized by the same properties that Maven uses, namely project.build.directory and project.build.directory. These properties need to be configured in the Generate<MyDSL>.properties with defaults.

Generate<MyDSL>.mwe

<workflow>
  ..
  <component class="org.eclipse.xtext.generator.Generator">
    <pathRtProject value="${runtimeProject}"/>
    <pathUiProject value="${runtimeProject}.ui"/>
    <projectNameRt value="${projectName}"/>
    <projectNameUi value="${projectName}.ui"/>
    <srcPath value="/${project.build.sourceDirectory}"/>
    <srcGenPath value="/${project.build.directory}/generated/java"/>
    ..
  </component>
  ..
</workflow>
<pre>

Generate<MyDSL>.properties

basedir=.
project.build.directory=target
project.build.sourceDirectory=src/main/java
grammarURI=classpath:/.../MyDSL.xtext
file.extensions=...
projectName=...

pom.xml: build section

The Java source directories also contain non-Java resources, like the workflow, grammar file etc. Normally this would go to the resources directory for Maven projects, but Xtext (0.7.2) cannot be configured to produce resource files to another directory than Java sources. On the other side those resources need to be found on the classpath during the build. This requires that we add the Java directories as resource directories in the build section of the POM. This settings already existed before, it just has been adopted.

Before:

    <build>
        <sourceDirectory>src</sourceDirectory>
        <resources>
            <resource>
                <directory>src</directory>
            </resource>
            <resource>
                <directory>src-gen</directory>
            </resource>
        </resources>
        ...
   </build>

After:

    <build>
        <resources>
            <resource>
                <directory>${project.build.sourceDirectory}</directory>
            </resource>
            <resource>
                <directory>${project.build.directory}/generated/java</directory>
            </resource>
        </resources>
         ...
     </build>

The <sourceDirectory> entry is not necessary anymore, since the main Java source directory is now src/main/java, which follows the Maven standard directory layout and gets automatically compiled.

maven-clean-plugin

Xtext produces output into two projects – the grammar project and the UI project. Now if the generated UI sources are produced below /target calling ‘mvn clean install’ would have an undesired side effect. Maven builds both modules after each other, so when the UI module is built with the goals ‘clean install’ the target directory is removed and the previous generated sources get lost.

The solution is that the maven-clean-plugin must be deactivated for the UI module and the grammar module must clean the target directory for the UI module.

pom.xml – Grammar project

<plugin>
    <artifactId>maven-clean-plugin</artifactId>
    <configuration>
        <filesets>
            <fileset>
                <directory>../my.dsl.ui</directory>
                <includes>
                    <include>${project.build.directory}</include>
                </includes>
            </fileset>
        </filesets>
    </configuration>
</plugin>

pom.xml – UI project

<plugin>
    <artifactId>maven-clean-plugin</artifactId>
    <configuration>
        <skip>true</skip>
    </configuration>
</plugin>

Eclipse settings

The new project structure affects, of course, the project settings for Eclipse. The settings apply for the grammar and UI plugin.

build.properties

Change the source folders in the build.properties file:

source.. = src/main/java/,target/generated/java/
bin.includes = META-INF/,\
 .,\
 plugin.xml

Java build path

Open the project properties and change the  Java Build Path settings:

  • Source Folder src -> src/main/java
  • Source Folder src-gen -> target/generated/java
  • Default outputr folder: bin -> target/classes

How to register a custom Maven repository layout

Maven repositories have a defined directory layout. In the standard installation Maven comes with 2 implementations, the default layout for Maven 2 and legacy layout for Maven 1.x. The layout is configured in the repository setting either in POMs or settings.xml file.

   <settings>
        ...
      <pluginRepositories>
        <pluginRepository>
          <id>codehausSnapshots</id>
          <name>Codehaus Snapshots</name>
          <releases>
            <enabled>false</enabled>
            <updatePolicy>always</updatePolicy>
            <checksumPolicy>warn</checksumPolicy>
          </releases>
          <snapshots>
            <enabled>true</enabled>
            <updatePolicy>never</updatePolicy>
            <checksumPolicy>fail</checksumPolicy>
          </snapshots>
          <url>http://snapshots.maven.codehaus.org/maven2</url>
          <layout>default</layout>
        </pluginRepository>
      </pluginRepositories>
      ...
</settings>

Normally the default structure is sufficient, but if what to do if forever which reason the layout should be changed? Basically what needs to be done is to provide an implementation of the ArtifactRepositoryLayout interface, register the implementation to Maven and configure repositories with a custom layout identifier, e.g.
<layout>custom</layout>

The Maven core is extensible, based on the Plexus IoC container. Plexus components are configured in META-INF/plexus/components.xml. Component implementations are looked up from the Plexus container with a key identified by role and optionally role-hint. A components.xml with a custom ArtifactRepositoryLayout looks like this:

<component-set>
    <components>
        <component>
            <role>org.apache.maven.artifact.repository.layout.ArtifactRepositoryLayout</role>
            <role-hint>custom</role-hint>
            <implementation>com.itemis.example.maven.repolayout.CustomRepositoryLayout</implementation>
        </component>
    </components>
</component-set>

The role-hint value is the identifier that is matched with the repository’s <layout> configuration.

Let’s assume a project artifact should be deployed to a Maven repository with custom layout. The corresponding section in the pom.xml file is for example:

  <distributionManagement>
    <snapshotRepository>
      <id>testrepo.snapshot</id>
      <url>/tmp/repository</url>
      <layout>custom</layout>
    </snapshotRepository>
  </distributionManagement>

Without proper setup a “mvn deploy” would fail with exception:
mvn deploy
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).

Project ID: com.itemis.example.maven:custom-repository-test
POM Location: /Users/thoms/Development/workspaces/sandbox-jsf/custom-repository-test/pom.xml
Reason: Cannot find layout implementation corresponding to: 'custom' for remote repository with id: 'testrepo.snapshot'. for project com.itemis.example.maven:custom-repository-test at /Users/thoms/Development/workspaces/sandbox-jsf/custom-repository-test/pom.xml

The jar with the custom layout implementation has to be deployed to $MAVEN_HOME/lib (on my machine /usr/share/maven/lib for example). All libraries from that directory are automatically included. It might be necessary to adjust $MAVEN_HOME/bin/m2.conf and add the following section and put the jar containing the custom repository layout implementation into a custom folder:
[plexus.core.maven]
load ${maven.home}/custom/*.jar

After doing so a deployment should be successful and use the customized layout:

> mvn deploy
...
[INFO] [deploy:deploy {execution: default-deploy}]
[INFO] Retrieving previous build number from testrepo.snapshot
Uploading: /tmp/repository/com/itemis/example/maven/1.0.0-SNAPSHOT/custom-repository-test/custom-repository-test-1.0.0-20091013.164125-2.jar

The custom implementation here changes the order of the base version and artifact id in the repository layout structure. The normal Maven2 repository structure is groupId/artifactId/version, this here uses groupId/version/artifactId. The sourcecode for this example can be downloaded here.

Xtext 0.7.2 artefacts installed to Maven repository

Finally I came to deploy the Xtext 0.7.2 artefacts to the Maven repository at openarchitectureware.org. I almost forgot that I did not that so far, but Michael Clay dropped me a mail today.

Maintaining the repository is a hard an error prone task. With each updated plugin the POM files need to be adjusted manually. Therefore each plugin manifest must be opened and the dependencies compared. Fortunately this stayed stable through the Xtext 0.7.x releases and also the underlying Eclipse libraries did not need to be updated after the Galileo release. I hope in future Eclipse plugins will be automatically deployed to a central Maven repository. There is currently some discussion on this in Eclipse Bug#283745.

I have optimized the manual deployment process a bit for myself. In my workspace I set up a project reflecting the repository structure. The jars are placed like they are stored in the repository with pattern {artifactId}-{version}.jar. Slightly different for the POMs. In the repository they are stored with pattern {artifactId}-{version}.pom, but in my workspace slightly different with {artifactId}-{version}.jar.pom.

The reason for is that I configured an External Tool configuration in Eclipse for deployment, which invokes the Maven deployment using “mvn deploy:deploy-file”. The property “pomFile” is computed from the selected resource through the {selected_resource_loc} variable (which ends with .jar), appended with “.pom”.

This way the jar file just needs to be selected and the deployment is executed with the external tool launcher.

[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'deploy'.
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Default Project
[INFO] task-segment: [deploy:deploy-file] (aggregator-style)
[INFO] ------------------------------------------------------------------------
[INFO] [deploy:deploy-file]
Uploading: scp://openarchitectureware.org/home/oaw/m2/repository/org/eclipse/xtext/xtext-core/0.7.2/xtext-core-0.7.2.jar
1495K uploaded
[INFO] Retrieving previous metadata from releases.openarchitectureware.org
[INFO] Uploading repository metadata for: 'artifact org.eclipse.xtext:xtext-core'
[INFO] Uploading project information for xtext-core 0.7.2
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 37 seconds
[INFO] Finished at: Thu Sep 24 21:06:43 CEST 2009
[INFO] Final Memory: 3M/6M
[INFO] ------------------------------------------------------------------------

Of course the repository must be configured in the ~/.m2/settings.xml file. The repository is accessed with SCP, authentication is done with public/private key.

<servers>
    <server>
      <id>releases.openarchitectureware.org</id>
      <username>oaw</username>
	  <passphrase>XXXXXXXXXXXX</passphrase>
      <filePermissions>775</filePermissions>
      <directoryPermissions>775</directoryPermissions>
      <privateKey>/Users/thoms/.ssh/id_rsa</privateKey>
    </server>
</servers>

Posted via email from Karsten’s Blog

Building TMF Xtext projects with Maven

Normally Xtext projects are built within the Eclipse IDE. But what do you do if the requirement is to have server side builds for for Xtext based projects, including the Grammar project itself, and of course without checking in generated sources? Setting up a working build process for Eclipse plugin projects is often a hell. I often face this requirement, and this is where Maven is a suitable alternative. This article explains how you can build Xtext based projects with Maven.

At first this requires that you have Maven installed on your machine and that the mvn command is on your path. Type on your shell

mvn -version

and it will answer something like

Maven version: 2.0.10
Java version: 1.6.0_07
OS name: "mac os x" version: "10.5.7" arch: "x86_64" Family: "mac"

This is all you basically need.

Xtext projects consist of

  1. A grammar project
  2. An UI project
  3. A generator project

The aim is to run the generator, which of course requires that at least the grammar project is built. We will also build the UI project, but it won’t result into a deployable plugin yet. I plan to investigate on this later. For the moment the projects are just compiled, packaged, and sources generated.

For this article I created projects using the Xtext project wizard, which creates by default the projects

  1. org.xtext.example.mydsl
  2. org.xtext.example.mydsl.ui
  3. org.xtext.example.mydsl.generator

Additionaly a further project was added:

  • org.xtext.example.mydsl.parent.

All projects can be downloaded here as Zip. Your project structure will look like this:

Bild 17

Maven Repositories

The most important thing for Maven based builds is that every artifact and plugin required must be available in a Maven Repository.

This is where the story begins, because Eclipse itself has no Maven repository, and thus every artifact (i.e. plugin jar) required within the build must be made available in a Maven Repository. This is at the moment maintained manually. I just deployed all required artifacts to the Maven Repository at openArchitectureWare.org. It contains now the latest 0.7.1 build of TMF Xtext, M2T Xpand and EMFT MWE.

Next repository we need is the one where to get Maven plugins from. Maven itself has just a small kernel and all features are added by plugins. Most of them are quite common and central available (e.g. Compiler Plugin), others are available in project specific repositories. For running Xpand based code generators the Fornax oAW Maven plugin is used, which is available through the Fornax Maven Repository.

In this example we make us of a small plugin (Replacer Plugin) which is available at the JBoss Maven Repository.

Last but not least the central Maven repository will be used to fetch some common artifacts that are not available in both of them. So we need the following repositories:

POM Files

Maven builds are described by Project Object Models (POM). The POMs are stored in pom.xml files for each subproject. These files are basically the build scripts for the projects and this is where all the magic goes in. Mainly it is “just” adding the right POMs to the projects that enable your projects to be built by Maven. This is totally non invasive. For more information about POMs read the Maven POM Reference.

In this article I show just excerpts from the POMs, so make sure to get the sources. Gaps in the POM are marked with “…”.

Parent Project

The org.xtext.example.parent project is the so called “parent project”. The parent’s POM is parent to all POMs from the submodules. The parent pom.xml

  • aggregates all subprojects as modules (Multi-module project)
  • declares common used Maven plugins
  • declares Maven Repositories to use

Module aggregation

We want to build all submodules when running the build on the parent project. This is done by declaring modules by relative paths. Since the projects are organized within an Eclipse workspace all projects including the parent are on the same level.

<modules>
  <module>../org.xtext.example.mydsl</module>
  <module>../org.xtext.example.mydsl.generator</module>
  <module>../org.xtext.example.mydsl.ui</module>
</modules>

Repository configuration

The required repositories are declared within a profile named “RepositoryManagement”, which is activated by default.

<profiles>
 <profile>
  <activation>
   <activeByDefault>true</activeByDefault>
  </activation>
  <id>RepositoryManagement</id>
  <repositories>
   <repository>
    <id>releases.openarchitectureware.org</id>
    <name>openArchitectureWare Release Repository</name>
    <url>http://www.openarchitectureware.org/m2</url>
    <releases>
     <enabled>true</enabled>
    </releases>
    <snapshots>
     <enabled>false</enabled>
    </snapshots>
   </repository>
  </repositories>
  <pluginRepositories>
   <pluginRepository>
    <id>releases.archiva.fornax-platform.org</id>
    <name>Archiva Managed Release Repository</name>
    <url>http://www.fornax-platform.org/archiva/repository/releases</url>
    <releases>
     <enabled>true</enabled>
    </releases>
    <snapshots>
     <enabled>false</enabled>
    </snapshots>
   </pluginRepository>
   ...
  </pluginRepositories>
 </profile>
</profiles>

Plugin configuration

Maven plugins are configured in the build section of a POM. Xtext projects require at least Java 1.5, so the Maven compiler plugin is configured so.

<build>
 ...
 <plugins>
  <plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-compiler-plugin</artifactId>
   <configuration>
    <source>1.5</source>
    <target>1.5</target>
   </configuration>
  </plugin>
...
 </plugins>
</build>

Grammar Project

The Grammar project org.xtext.example.mydsl contains a workflow that runs the Xtext generator to create the Xtext implementation artifacts. By default the file is GenerateMyDsl.mwe in package org.xtext.example.

Bild 18

When running a build this generator workflow should be executed, generating the Xtext sources. Afterwards the sources should be compiled.

Project parent and basic descriptor tags

The project’s parent is declared by groupId, artifactId and version in the <parent> section. Since groupId and version should always be the same as the parent they are just inherited. This way the must only declared once.

<parent>
  <groupId>org.xtext.example.mydsl</groupId>
  <artifactId>mydsl-parent</artifactId>
  <version>1.0.0-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>mydsl-grammar</artifactId>
<name>TMF Xtext Example - Grammar</name>

Dependencies

For generating the sources and compilation the Grammar project needs just 2 dependencies:

<dependencies>
  <dependency>
    <groupId>org.eclipse.xtext</groupId>
    <artifactId>xtext-generator</artifactId>
    <version>0.7.1</version>
  </dependency>
  <dependency>
    <groupId>de.itemis.xtext</groupId>
    <artifactId>antlr</artifactId>
    <version>0.7.1</version>
  </dependency>
</dependencies>

All other required dependencies are included by Maven’s transitive dependency management.

Alternative Source/Resource paths

Xtext projects don’t follow Maven’s default paths for Java sources and resources. By default Maven will compile Java sources only from the src/main/java folder and will add src/main/resources. For Xtext projects there are two source folders, /src and /src-gen. To compile both an additional plugin from Codehaus, the Build Helper Maven Plugin, is needed.

<build>
  ...
  <sourceDirectory>src</sourceDirectory>
  <resources>
    <resource>
      <directory>src</directory>
    </resource>
    <resource>
      <directory>src-gen</directory>
    </resource>
  </resources>
  <plugins>
    <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>build-helper-maven-plugin</artifactId>
      <version>1.3</version>
      <executions>
        <execution>
          <id>add-source</id>
          <phase>generate-sources</phase>
          <goals>
            <goal>add-source</goal>
          </goals>
          <configuration>
            <sources>
              <source>src-gen</source>
            </sources>
          </configuration>
        </execution>
      </executions>
    </plugin>
    ...
  </plugins>
</build>

Workflow execution

To execute the MWE workflow we need the Fornax oAW Maven Plugin. Maven builds have a lifecycle, where predefined lifecycles exists. The oAW Maven plugin must be executed in the generate-sources phase. Since version 3.0.0 the Fornax plugin supports both workflow engines, oAW 4 Workflow Engine and oAW 5 MWE. Current version is 3.0.1.

To enable execution of MWE workflows the configuration section must be configured with <workflowEngine>mwe</workflowEngine>. The <workflowDescriptor> parameter specifies the path to the workflow file.

<build>
  ...
  <plugins>
    <plugin>
       <groupId>org.fornax.toolsupport</groupId>
       <artifactId>fornax-oaw-m2-plugin</artifactId>
       <version>3.0.1</version>
       <configuration>
         <outletSrcDir>src-gen</outletSrcDir>
         <outletSrcOnceDir>src</outletSrcOnceDir>
       </configuration>
       <executions>
         <execution>
           <phase>generate-sources</phase>
           <goals>
             <goal>run-workflow</goal>
           </goals>
           <configuration>
             <workflowDescriptor>org/xtext/example/GenerateMyDsl.mwe</workflowDescriptor>
             <workflowEngine>mwe</workflowEngine>
           </configuration>
         </execution>
       </executions>
     </plugin>
   </plugins>
   ...
</build>

UI Project

Configuring the POM for the UI project org.xtext.example.mydsl.ui is pretty similar to the Grammar project. In this project even no workflow execution is required, just source paths must be adjusted to /src and /src-gen (see above, Grammar project).

Dependencies

The UI plugin has 2 dependencies:

  1. The Grammar project
  2. org.eclipse.xtext:xtext-ui-common
<dependencies>
 <dependency>
  <groupId>${project.groupId}</groupId>
  <artifactId>mydsl-grammar</artifactId>
  <version>${project.version}</version>
 </dependency>

 <dependency>
  <groupId>org.eclipse.xtext</groupId>
  <artifactId>xtext-ui-common</artifactId>
  <version>0.7.1</version>
 </dependency>
</dependencies>

Generator Project

The POM for the Generator project again is similar to the Grammar project. This plugin of course executes a workflow during the build, so the Fornax oAW Maven plugin needs to be configured again. Again the source paths must be configured in the build section, and the Build Helper plugin used. See the Grammar project for this configuration.

Dependencies

The Generator project needs also just 2 dependencies:

  1. The Grammar project
  2. org.eclipse.xtext:xtext-util

All other dependencies come in transitive.

<dependencies>
  <dependency>
   <groupId>${pom.parent.groupId}</groupId>
   <artifactId>mydsl-grammar</artifactId>
   <version>${pom.parent.version}</version>
  </dependency>
  <dependency>
   <groupId>org.eclipse.xtext</groupId>
   <artifactId>xtext-util</artifactId>
   <version>0.7.1</version>
  </dependency>
</dependencies>

Workflow execution

The configuration of the oAW Maven plugin is similar to the Grammar project. Of course the path of the workflow file differs. To avoid unneccessary generator execution the plugin can be configured to just run the workflow when specified resources change. This is done through the checkResources section. In this case the generator will only run when the model file src/model/MyModel.dsl changes.

<build>
 ...
 <plugins>
  <plugin>
   <groupId>org.fornax.toolsupport</groupId>
   <artifactId>fornax-oaw-m2-plugin</artifactId>
   <version>3.0.1</version>
   <configuration>
    <checkResources>
     <checkResource>
      src/model/MyModel.mydsl
    </checkResource>
   </checkResources>
   <outletSrcDir>src-gen</outletSrcDir>
  </configuration>
  <executions>
   <execution>
    <phase>generate-sources</phase>
    <goals>
     <goal>run-workflow</goal>
    </goals>
    <configuration>
     <workflowDescriptor>workflow/MyDslGenerator.mwe</workflowDescriptor>
     <workflowEngine>mwe</workflowEngine>
    </configuration>
   </execution>
  </executions>
 </plugin>
 ...
 </plugins>
</build>

Running the build

Now it is time to build the projects with Maven. Note that we only added the described pom.xml files to the projects that the Xtext Wizard created.

Open a shell, go to the org.xtext.example.parent folder and type

mvn clean install

The Maven build starts…

[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO]   TMF Xtext Example - Parent
[INFO]   TMF Xtext Example - Grammar
[INFO]   TMF Xtext Example - Generator
[INFO]   TMF Xtext Example - UI
[INFO] ------------------------------------------------------------------------
[INFO] Building TMF Xtext Example - Parent
[INFO]    task-segment: [clean, install]
[INFO] ------------------------------------------------------------------------

These are the first log statements that the build prints out. You can see from here in which order Maven will build the projects. First the parent project will be built, followed by Grammar project, Generator project and UI project.

Downloading artifacts

When you start with a clean Maven installation Maven will download all plugins and artifacts required for the build.

...
Downloading: http://www.openarchitectureware.org/m2/org/eclipse/emf/ecore/xmi/2.5.0/xmi-2.5.0.pom
583b downloaded
Downloading: http://www.openarchitectureware.org/m2/org/eclipse/m2t/xpand/m2t-xpand-xpand/0.7.1/m2t-xpand-xpand-0.7.1.pom
1K downloaded
Downloading: http://www.openarchitectureware.org/m2/org/eclipse/m2t/xpand/m2t-xpand/0.7.1/m2t-xpand-0.7.1.pom
3K downloaded
Downloading: http://www.openarchitectureware.org/m2/org/eclipse/m2t/xpand/m2t-xpand-xtend/0.7.0/m2t-xpand-xtend-0.7.0.pom
1K downloaded
Downloading: http://www.openarchitectureware.org/m2/org/eclipse/m2t/xpand/m2t-xpand/0.7.0/m2t-xpand-0.7.0.pom
3K downloaded
Downloading: http://www.openarchitectureware.org/m2/org/eclipse/emf/mwe/emf-mwe/0.7.0/emf-mwe-0.7.0.pom
24K downloaded
Downloading: http://www.openarchitectureware.org/m2/org/eclipse/emf/mwe/emf-mwe-core/0.7.0/emf-mwe-core-0.7.0.pom
2K downloaded
...

This is already a lot! All of the downloaded artifacts will be stored in your local repository, which is usually located at ~/.m2/repository. Once the artifacts are downloaded you don’t need to access the internet again. You can than go to offline mode by adding the -o option:

mvn -o clean install

You may need to configure a proxy to access the public Maven repositories. Read “Configuring a proxy” to get more information.

Generating the Xtext artifacts

When running the build on the Grammar project the artifacts from the Xtext grammar file are generated. You will see that the Fornax oAW Maven plugin starts execution and the Xtext generator is run.

[INFO] [fornax-oaw-m2:run-workflow {execution: default}]
[INFO] Fornax oAW/MWE Maven2 Plugin V3.0.1
0    [main] INFO  eclipse.emf.mwe.core.WorkflowRunner  - --------------------------------------------------------------------------------------
174  [main] INFO  eclipse.emf.mwe.core.WorkflowRunner  - EMF Modeling Workflow Engine 0.7.1, Build v200907170432
174  [main] INFO  eclipse.emf.mwe.core.WorkflowRunner  - (c) 2005-2009 openarchitectureware.org and contributors
174  [main] INFO  eclipse.emf.mwe.core.WorkflowRunner  - --------------------------------------------------------------------------------------
175  [main] INFO  eclipse.emf.mwe.core.WorkflowRunner  - running workflow: org/xtext/example/GenerateMyDsl.mwe
175  [main] INFO  eclipse.emf.mwe.core.WorkflowRunner  -
882  [main] INFO  lipse.emf.mwe.utils.StandaloneSetup  - Registering platform uri '/Users/thoms/Development/workspaces/oaw-v5-test'
2794 [main] INFO  e.core.container.CompositeComponent  - DirectoryCleaner: cleaning directory '../org.xtext.example.mydsl/src-gen'
2795 [main] INFO  ipse.emf.mwe.utils.DirectoryCleaner  - Cleaning /Users/thoms/Development/workspaces/oaw-v5-test/org.xtext.example.mydsl/../org.xtext.example.mydsl/src-gen
2820 [main] INFO  e.core.container.CompositeComponent  - DirectoryCleaner: cleaning directory '../org.xtext.example.mydsl.ui/src-gen'
2820 [main] INFO  ipse.emf.mwe.utils.DirectoryCleaner  - Cleaning /Users/thoms/Development/workspaces/oaw-v5-test/org.xtext.example.mydsl/../org.xtext.example.mydsl.ui/src-gen
2824 [main] INFO  e.core.container.CompositeComponent  - Generator
2929 [main] INFO  ipse.xtext.generator.LanguageConfig  - generating infrastructure for org.xtext.example.MyDsl with fragments : ImplicitRuntimeFragment, ImplicitUiFragment, GrammarAccessFragment, EcoreGeneratorFragment, ParseTreeConstructorFragment, ResourceFactoryFragment, AntlrDelegatingFragment, JavaValidatorFragment, JavaScopingFragment, FormatterFragment, LabelProviderFragment, TransformerFragment, OutlineNodeAdapterFactoryFragment, JavaBasedContentAssistFragment, DelegatingGeneratorFragment

Done!

When the build is through you will get the build summary. All generators are run, sources are compiled, jar files are created and installed into your local repository.

...
...
[INFO] Installing /Users/thoms/Development/workspaces/oaw-v5-test/org.xtext.example.mydsl.ui/target/org.xtext.example.mydsl.mydsl-ui_1.0.0-SNAPSHOT.jar to /tmp/maven-rep/org/xtext/example/mydsl/mydsl-ui/1.0.0-SNAPSHOT/mydsl-ui-1.0.0-SNAPSHOT.jar
[INFO]
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] ------------------------------------------------------------------------
[INFO] TMF Xtext Example - Parent ............................ SUCCESS [4.743s]
[INFO] TMF Xtext Example - Grammar ........................... SUCCESS [24.037s]
[INFO] TMF Xtext Example - Generator ......................... SUCCESS [2.600s]
[INFO] TMF Xtext Example - UI ................................ SUCCESS [2.766s]
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 34 seconds
[INFO] Finished at: Mon Jul 20 15:07:14 CEST 2009
[INFO] Final Memory: 67M/160M
[INFO] ------------------------------------------------------------------------

Of course on first execution this will take much longer, since every needed dependency is downloaded. On second execution no download is needed anymore.

Fornax oAW plugin version 3.0.0 released

I have just released version 3.0.0 of the Maven plugin for oAW. The biggest news is that it now supports the WorkflowRunner from Eclipse MWE. I have tested it both with oAW 4 based projects and an TMF Xtext example, which requires MWE as execution environment.

Two weeks ago I started together with Heiko Behrens the work on the new release in an evening session in the Hotel, since his project at Deutsche Boerse wants to integrate in the Maven based build process. They already use the latest Eclipse Galileo, TMF Xtext, M2T Xpand and MWE versions.

Since the current oAW plugin from Fornax was bound to openArchitectureWare 4 we had to open it up to support MWE. First we did the obvious, by adding MWE as additional dependency to the plugin project. Later I phoned with Dieter Moroff, who suggested to reduce dependencies by using reflection to load and execute the appropriate WorkflowRunner implementation. This works fine now, the plugin supports now both engines while dependencies have been minimized.

Originally I planned to release it as version 2.2.0, but the opening for MWE is such a great step that I decided on the finishing line to give it the version 3.0.0.

For TMF Xtext we have created an example which demonstrates the Maven integration for TMF Xtext/M2T Xpand/MWE based projects (what openArchitectureWare 5 in the core will be). I will write articles on some details later.