Eclipse Community Forums: TMF (Xtext) » Building the web-based editor in a project with existing Ecore model

Help

Home

Home » Modeling » TMF (Xtext) » Building the web-based editor in a project with existing Ecore model

Show: Today's Messages :: Show Polls :: Message Navigator

Building the web-based editor in a project with existing Ecore model [message #1744848]

Fri, 30 September 2016 17:49

Andrzej Wasowski

Messages: 15
Registered: June 2015

Junior Member

I keep this long, so that it can help some others trying achieve the same thing as I do. TLDR: jumpt to point 8.

I have been struggling to set up a simple tutorial on how to get Xtext's web-based editor generated in a project based on pre-existing ecore model (all report below based on Xtext 2.10).

After quite some debugging I established that:

1. The Ecore model should have one top-level package, no sub-packages

So I simplified mine and used the base package property in genmodel to place the generated EMF code into the right package. Otherwise errors multiple, some of them can be worked around, but not clear what further repercussions are.

2. The EMF model project must get Xtext nature configured

The error message is very cryptic about this ("The imported package is not on the classpath of this project"). Apparently this is an old news, here is a bug report from 2.2: https://bugs.eclipse.org/bugs/show_bug.cgi?id=367013, yet I am getting this warning in 2.10 too.

3. Generate code from the Ecore Model (not clear which EMF projects are needed).

One likely needs to generate more than just model code from the Ecore model. There is little explicit information on what is actually needed, but the number of errors reported seems to be dropping, if I generate all, instead of just the model project.

4. Create an Xtext project from an existing Ecore model, selecting the genmodel in the wizard.

If your Ecore model project is in a Git repository then it is useful to create the Xtext project in the same repo (not in the workspace). I tend to get much more errors if part of the workspace is in a remote location -- and moving the Xtext projects to the Git repo post-factum does not seem to remove all the error messages. Have not investigate this further though. Perhaps this is just my prejudice from the old days that it is better to avoid a physically distributed workspace. More bugs in tools show up then Smile

5. Build.properties in the generated Xtext project, apparently needlessly lists plugin.xml.

You get a, probably harmless, warning about a missing plugin.xml file. This seems fixed in the current development version, but I do get the warning with 2.10. I just remove plugin.xml from build.properties to reduce annoyance. Not sure if this has side effects.

6. In the wizard select that Web (and Idea if relevant) should be generated, with Gradle as the build system and a plain file layout.

7. At this point a good old Xtext process (MWE2 workflows) work as they used to for generating the Eclipse plugin. Excellent!

8. Make gradle build work.

This is where I get stuck. Unfortunately, no gradle project can be built. They all fail on generateXtextLanguage, so the thing that works perfectly well with the MWE2 workflow. The error message is that the genmodel file is unmapped. Apparently the gradle setup generator is not including the model project in the build.

There is an indication here that this is expected, and as such it is not likely to be fixed. The user is supposed to include the existing metamodel into your Gradle build and set up the generator workflow accordingly. This cannot be done automatically by the wizard. (quoting from the issue discussion).

It used to be possible to demo and experience Xtext functionality without major plumbing. The new build management setup makes this impossible, which is highly discouraging for new users. For a new user, importing an existing metamodel, generating a default grammar, and being able to experience all key aspects of Xtext is a boon. It helps adoption too ...

But perhaps this indeed cannot be done to easily (I have no idea of the limitations in the information that the gradle generator has). I try to fix this manually. Unfortunately, no tutorial explains how to "include the existing metamodel in the Gradle build", nothing short of becoming a gradle expert, understanding the architecture of the gradle build in the Xtext generated project and extending it manually. This is a pretty high barrier of entry Sad

I have found a blog entry that seems to answer this problem but in a more complicated setup - with Xcore not with Ecore.

I would like to move forward with this battle without learning about Xcore Smile

Could some Gradle pro help me with a few lines on which build files should modified/added and how, in order to include an EMF model project into the gradle build generated by Xtext?

We just need a way to include and compile the classes generated by EMF, or even pick up classes compiled by Eclipse. I think a full integration with gradle, controlling generation and compilation of the model project is likely going to be already too complex Smile

Help?

Breadcrumbs

Sign up to our Newsletter