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.

About these ads

26 thoughts on “Building TMF Xtext projects with Maven

    • Hi Karsten,

      I have a problem with classloading. When I specify the “generation dependencies” (dsl and generation artifacts in a concrete project) I get classloading conflicts when the compiling takes place (The code generation works):

      Exception in thread “main” java.lang.NoSuchMethodError: org.eclipse.jdt.internal.compiler.lookup.ProblemReferenceBinding.closestMatch()Lorg/eclipse/jdt/internal/compiler/lookup/Ref
      erenceBinding;

      When I place the dependencies only to the fornax plugin the generation artifacts are not found.

      Do you know a solution for this problem?

      TIA
      Martin

      • Could it be that you have an old version of jdt.core on your path? Check with
        mvn dependency:tree

      • Oh, I found the problem. When I specify the dependencies with scope “provided” for the fornax plugin it doesn’t work…

  1. Hi Karsten,

    thanks for providing this example of a maven build with xtext.

    I would like to change the source directory to maven standard but this is not easy possible (at least for me). I tried to change all src / src-gen to src/main/java / src-gen/main/java. But this is obviously not enough.

    Can you help me?
    TIA
    Martin

  2. Not tried this yet, but sure possible. The class org.eclipse.xtext.generator.Generator has properties srcPath=”src” and srcGenPath=”src-gen”.

    So, theoretically, the workflow must be changed like follows:

    <component class="org.eclipse.xtext.generator.Generator">
      <srcPath value="src/main/java"/>
      <srcGenPath value="src-gen/main/java"/>
       ...
    </component>
    

    This would cause the generator to use other outputs. The POM must be changed accordingly, and of course you would still need to configure the additional src path with the Build Helper plugin.

    You won’t win that much. After all these are just Maven defaults, and Xtext projects don’t follow the default.

    ~Karsten

  3. Great job!

    Do you plan to deploy all required artifacts of the latest version of Xtext 0.7.2 to the Maven Repository?

    Thank again for you contribution.

    Denis

  4. Hi!
    First of all: thanks for this blog entry, it sure helped a lot.

    Now:
    I am currently trying to move an oaw 4.3.1 Project (built like described in the oaw emf tutorial: http://www.openarchitectureware.org/pub/documentation/4.3.1/html/contents/emf_tutorial.html#ftn.d0e651), but when I try to use the Fornax oAW/MWE Maven2 Plugin I always get this error message:

    ERROR] FATAL ERROR
    [INFO] ————————————————————————
    [INFO] Cannot load or instantiate class org.eclipse.emf.mwe.core.monitor.NullProgressMonitor
    [INFO] ————————————————————————
    [INFO] Trace
    java.lang.IllegalArgumentException: Cannot load or instantiate class org.eclipse.emf.mwe.core.monitor.NullProgressMonitor
    at org.fornax.toolsupport.maven2.MojoWorkflowRunner.setProgressMonitorClass(MojoWorkflowRunner.java:82)
    .
    .
    .

    Seems like I am missing some dependencies, but I can’t seem to figure out what I did wrong. Any ideas anyone?

    • Yes, seems that the org.eclipse.emf.mwe:emf-mwe-core dependency is missing. Did you compare your dependency setup to the sample project attached to this blog post?

      • I have the same problem. It is the ProposalProvider and usage of createCompletionProposal that cause the dependency to AbstractContentProposalProvider, which imports org.eclipse.swt.graphics.Image.

      • The .classpath file generated by “eclipse:eclipse” is missing the eclipse container “org.eclipse.pde.core.requiredPlugins”.

        Adding a custom configuration to the maven eclipse plugin fixes the problem for me.

  5. Hi Karsten,

    thanks for the information in this article, it works fine for a setup with all projects on the same level.

    However, in our Maven build environment we want to aggregate all modules from a parent project which is one level higher than each sub-project. The generation then fails with the following messages:

    error(7): cannot find or open file: ../our.dsl/src/main/generated-java/our/dsl/parser/antlr/internal/InternalSML.g
    10579 INFO JavaValidatorFragment – executing generate for org.eclipse.xtext.generator.validation.JavaValidatorFragment
    error(7): cannot find or open file: ../our.dsl.ui/src/main/generated-java/our/dsl/contentassist/antlr/internal/InternalSML.g
    11235 ERROR Generator – java.io.FileNotFoundException: ..\our.dsl\META-INF\MANIFEST.MF

    If we run Maven from the “our.dsl” module itself, then it works fine. We’ve tried using absolute paths instead of relative ones, but that doesn’t work either.

    Are you aware of this issue and do you know a setup/solution that works both on the same level and a parent folder?

    Regards,
    Michel de Blok

    • I’m aware of it. My projects are usually organized like in Eclipse workspace, so on the same level. The Maven POMs have been set up to fit this scenario. I could not exactly tell you what settings you’d have to change, but mainly you’ll have to check which properties for paths the Xtext projects assume and override them.

      • We’ve tried that, but finally couldn’t get it to work. The ecore generator complains about unmapped entries or the Antlr parser cannot find its *.g files.

        Unfortunately, your setup doesn’t work with our standard Maven release process that runs in Continuum, so the work-around for us is to check-in the XText generated code.

        If anyone does get it to work with a Maven parent/child folder setup, please let us know ;-)

    • Okay, so I finally got this working. It is a Big Hack. First, the root of the problem is that the different Fragments do not treat the paths the Same Way. So relative paths fail for some fragments; absolute for other. In particular, absolute paths work for all Fragments EXCEPT the EcoreGeneratorFragment. So, here’s what I ended up doing: First I created my own copy of the Xtext Generator class (code copy). Then, in the createExecutionContext method, I make sure that all paths are turned into canonical paths, for which I get the URI path. Finally, I extended Outlet and created a MyOutlet class. My outlet overrides the getPath method and actually creates a stack trace. It looks in the stack trace for the EcoreGeneratorFragment, and if it exists, it returns a relative path; otherwise, it returns the canonical path previously computed. The relative path must always go to the project root and then back up. For example, if I’m in myModule, the relative path would be ../myModule, not .. The reason is that ecore determines whether the path is valid based on the first fragment of the path. That .. path is what needs to be registered with the StandaloneSetup as the platform URI, incidentally. StandaloneSetup looks at the path provided, gets its sub directories, and registers each of them. Therefore, the relative path must take you to that level so that it sees the next path-fragment as being one of the sub-directories it recognizes. Let me know if you have any problems or questions with this.

  6. Hi

    Thanks a lot for this article. It really helped me kick start the maven integration for my xtext project. I also was able to adapt this to use the m2 layout and that works fine.

    I was trying to add validations using check language and when I try to integrate that to the m2 xtext project(created above), it cribs on missing dependency for the ‘org.eclipse.xtext.validation’ package.Looking at the OAW maven repo form above post(http://www.openarchitectureware.org/m2/org/eclipse/xtext/), doesnt look like its been deployed.

    Had anyone got a chance to use this?

    • I do not plan to release milestone builds, it’s just a lot of work. And more likely Xtext Helios+ projects will be build with Maven3 and Tycho. I will blog on this soon.

  7. Hi Karsten:

    First of all, thank you for this great tutorial, it’s very useful.

    However, I tried to follow it step by step and, when the generator needs to use a Java Helper Class, it shows me this error:

    2676 [main] ERROR org.eclipse.xpand2.Generator – Error in Component of type org.eclipse.xpand2.Generator:
    EvaluationException : com.package.FileProjectConfig.getBasePackageName() not found, problems were:
    [AnalysationIssueType not found] – Couldn’t find Java type com. package.config.FileProjectConfig : com. package.config.FileProjectConfig
    extensions::FileProjectConfig.ext[115,100] on line 7 ‘String getBasePackageName()’
    templates::Example.xpt[176,20] on line 8 ‘getBasePackageName()’
    [23,37] on line 1 ‘EXPAND templates:: Example::main FOR model’

    I think it’s necessary to compile the Java helper classes before the generator’s call. Isn’t it? How do I declare this fact in pom.xml? Thank you.

    Greetings from Canarias, Miguel Bravo.

    • Yes, the generator and the project using the generator must be separated. This is not the case when using the default project layout produced by Xtext. In the example generator project the model file is contained in that project. It should be moved into a separate module, also the workflow execution. Then the generator project build just compiles the helper classes and packages the templates. When using the generator the helper classes are already compiled. In the example provided I just mavenized the projects that the Xtext wizard would produce. In real world I would split the generator module.

  8. I wish to express appreciation to you just for bailing me out
    of this particular circumstance. Because of exploring through the world-wide-web and coming across ideas which were
    not helpful, I believed my life was well over.
    Being alive without the approaches to the issues you’ve solved all through your main short post is a crucial case, and those which might have in a wrong way damaged my career if I hadn’t discovered the blog.

    Your actual training and kindness in handling all things was precious.

    I’m not sure what I would’ve done if I had
    not discovered such a step like this. It’s possible to at this point look forward to my future. Thanks so much for this reliable and results-oriented guide. I won’t hesitate to endorse your site to anybody who needs tips about this matter.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s