 Building the web-based editor in a project with existing Ecore model [message #1744848] |
Fri, 30 September 2016 17:49  |
|
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 
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 
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 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
Help?
|
|
|
| Re: Building the web-based editor in a project with existing Ecore model [message #1744875 is a reply to message #1744848] |
Sat, 01 October 2016 07:55  |
|
Can you share a hello world project showing the Code (eG on github)
I did not find the information where you turn the emf project to a Grade project and configure it to include the generated Java classes and plugin.xml and ecore and genmodel file and put that to the classpath of the Xtext project.
If you feel better with maven or manual work you can add this dependency as maven dependency if you get the emf project built with maven as well.
You did not show how the emf project and the Gradle parent ly relatively to each other.
As said initially . Having the projects with no need to mock up them manually would make answering this more easy
Need professional support for Xtext, Xpand, EMF?
Go to: https://www.itemis.com/en/it-services/methods-and-tools/xtext
Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
|
|
|
|
| Re: Building the web-based editor in a project with existing Ecore model [message #1744888 is a reply to message #1744875] |
Sat, 01 October 2016 15:43 |
|
Thank you Christian. I reproduced my setup here:
https://bitbucket.org/andrzej_wasowski/xtextgradlequestion
This is just a vanilla EMF project with default result of running the wizard from existing EMF project. As far as can see, there is no way to avoid Gradle. Apparently the web editor can only be built with Gradle (at least using the wizard).
Any gradle target seems to fail on ":org.xtext.example.mydsl:generateXtextLanguage". For instance go to the parent project and call "gradle assemble" (or the same in eclipse).
The Idea project seems to always be generated with an error. I have not investigated this further, as my current focus is the web based editor. But a compilation error in a default generated project is not great either
I will have a look at the project you posted.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Building the web-based editor in a project with existing Ecore model [message #1751648 is a reply to message #1751644] |
Thu, 12 January 2017 08:48 |
|
yes
i created this on plain greens
(1) create new xtext project with gradle in eclipse
(2) create new empty emf project in eclipse, create metamodel and genmodel, generate code, add xtext nature
(3) move the emf project into the parent of the xtext project
(4) adapt settings.gradle in the parent
include 'org.xtext.example.mydsl.metamodel'
include 'org.xtext.example.mydsl'
include 'org.xtext.example.mydsl.ide'
include 'org.xtext.example.mydsl.web'
include 'org.xtext.example.mydsl.tests'
(5) create build.gradle for metamodel project
dependencies {
compile "org.eclipse.xtext:org.eclipse.xtext.xbase.lib:${xtextVersion}"
compile "org.eclipse.xtext:org.eclipse.xtext:${xtextVersion}" // or emd deps direct, i was lazy
}
jar {
from ('.') {
include 'model/demo.ecore'
include 'model/demo.genmodel'
include 'plugin.xml'
}
}
(6) add dependency from dsl to metamodel, adapt grammar, adapt workflow
dependencies {
compile project(':org.xtext.example.mydsl.metamodel')
(7) adapt MydslStandalonesetup
override register(Injector injector) {
if (!EPackage.Registry.INSTANCE.containsKey(DemoPackage.eNS_URI)) {
EPackage.Registry.INSTANCE.put(DemoPackage.eNS_URI, DemoPackage.eINSTANCE);
}
super.register(injector)
}
( workaround for xtext 2.10 web bug
class MyDslWebModule extends AbstractMyDslWebModule {
def void configureIPreferenceValuesProvider(Binder binder) {
binder.bind(IPreferenceValuesProvider).annotatedWith(FormatterPreferences).to(FormatterPreferenceValuesProvider)
}
}
Need professional support for Xtext, Xpand, EMF?
Go to: https://www.itemis.com/en/it-services/methods-and-tools/xtext
Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
|
|
|
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.02387 seconds
] 
Search
Help
Register
Login
Home
