Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Abstract*RuntimeModule generation woes
Abstract*RuntimeModule generation woes [message #1176292] Fri, 08 November 2013 08:40 Go to next message
Andreas Sewe is currently offline Andreas SeweFriend
Messages: 111
Registered: June 2013
Senior Member
Hi,

I am currently struggling with the following behaviour of Xtext and/or the MWE2 workflow we use to generate its code:

When I initially run the workflow with the fornax-oaw-m2-plugin (so no Eclipse IDE involved yet), it generates (under "src") a "TemplateRuntimeModule.java" and (under "target/generated-sources/xtext", as we follow the Maven conventions) an "AbstractTemplateRuntimeModule.java" containing lots of stuff.

The trouble begins when I change anything in "TemplateRuntimeModule.java". This includes entirely insubstantial changes like changing whitespace to make it conform to our Checkstyle rules. The next "mvn clean install" then leaves the "TemplateRuntimeModule.java" as is (OK) and regenerates a "AbstractTemplateRuntimeModule.java" -- which misses most of the stuff that was previously there (not OK).

What am I doing wrong? Why is stuff I do unter "src" influencing what's generated for abstract base classes under "target/generated-sources/xtext"?
Re: Abstract*RuntimeModule generation woes [message #1176345 is a reply to message #1176292] Fri, 08 November 2013 09:20 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 13515
Registered: July 2009
Senior Member
Hi

everything under src-gen is regenerated! isnt that the purpose of a generation.
i am not sure what you mean with "misses"
are you sure your setup is ok?

~Christian


Need professional support for Xtext, Xpand, EMF?
Go to: https://www.itemis.com/en/xtext/
Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Re: Abstract*RuntimeModule generation woes [message #1176351 is a reply to message #1176345] Fri, 08 November 2013 09:22 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 13515
Registered: July 2009
Senior Member
PS: and why is the generated stuff under target/generated-sources/xtext

Need professional support for Xtext, Xpand, EMF?
Go to: https://www.itemis.com/en/xtext/
Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Re: Abstract*RuntimeModule generation woes [message #1176388 is a reply to message #1176351] Fri, 08 November 2013 09:52 Go to previous messageGo to next message
Andreas Sewe is currently offline Andreas SeweFriend
Messages: 111
Registered: June 2013
Senior Member
Hi Christian,

The generated stuff is under "target/generated-sources/xtext" just because we follow the convention of Maven/Tycho here (and the maven-clean-plugin picks it up by default). This is configured with "srcGenPath" for our Generator and it works insofar as the generated stuff does indeed end up under "target/generated-sources/xtext". What baffles me are two things:


  1. That different stuff gets generated depending on what is under "src"
  2. That stuff gets generated under "src" at all. (I assume this is Xtext being nice and generating a template for me to fill in.)


Anyway, what I mean by "misses" is that the "AbstractTemplateRuntimeModule.java" generated the first time contains code like the following

        // contributed by org.eclipse.xtext.generator.grammarAccess.GrammarAccessFragment
        public java.lang.ClassLoader bindClassLoaderToInstance() {
                return getClass().getClassLoader();
        }


but that the regenerated one (on subsequent "mvn clean install"s) doesn't, which causes Guice injection errors further down the road. FWIW, you can find the workflow file in Gerrit.
Re: Abstract*RuntimeModule generation woes [message #1176394 is a reply to message #1176388] Fri, 08 November 2013 09:57 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 13515
Registered: July 2009
Senior Member
Hi,

are you sure there are no changes to the workflow and no errors in the log?
or any timeouts on processing the grammar..


Need professional support for Xtext, Xpand, EMF?
Go to: https://www.itemis.com/en/xtext/
Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Re: Abstract*RuntimeModule generation woes [message #1176446 is a reply to message #1176394] Fri, 08 November 2013 10:38 Go to previous messageGo to next message
Andreas Sewe is currently offline Andreas SeweFriend
Messages: 111
Registered: June 2013
Senior Member
I certainly didn't change the workflow between "mvn clean install"s.

The command line log for the first invocation of "mvn clean install" contains just this:

[INFO] --- fornax-oaw-m2-plugin:3.4.0:run-workflow (default) @ org.eclipse.recommenders.templates ---
[INFO] Fornax Model Workflow Maven2 Plugin V3.4.0
[INFO] Executing workflow in forked mode.
[INFO] 1    INFO  StandaloneSetup    - Registering platform uri '/Users/sewe/Desktop/recommenders-head/workspace/org.eclipse.recommenders.snipmatch/plugins'
[INFO] 15   INFO  StandaloneSetup    - Registering project org.eclipse.recommenders.templates at 'file:/Users/sewe/Desktop/recommenders-head/workspace/org.eclipse.recommenders.snipmatch/plugins/org.eclipse.recommenders.templates/'
[INFO] 772  INFO  LanguageConfig     - generating infrastructure for org.eclipse.recommenders.templates.Template with fragments : ImplicitRuntimeFragment, ImplicitUiFragment, GrammarAccessFragment, EcoreGeneratorFragment, SerializerFragment, ResourceFactoryFragment, XtextAntlrGeneratorFragment
[INFO] 3353 INFO  GenModelHelper     - Registered GenModel 'http://www.eclipse.org/recommenders/templates/Template' from 'platform:/resource/snipmatch:org.eclipse.recommenders.templates/target/generated-sources/xtend/org/eclipse/recommenders/templates/Template.genmodel'
[INFO] 5904 INFO  Workflow           - Done.
[INFO] Workflow 'src/org/eclipse/recommenders/templates/Template.mwe2' finished.


Shortly thereafter the build fails (as intended) as "TemplateRuntimeModule.java" doesn't conform to our Checkstyle rules.

After the necessary changes (whitespace + a required license header) to the generated "TemplateRuntimeModule.java" in "src" in get the same output but the build proceeds further building the sibling Maven module of "org.eclipse.recommenders.templates", the UI-specific "org.eclipse.recommenders.templates.rcp".

And that sibling module has its own workflow which apparently overwrites the "AbstractTemplateRuntimeModule.java" generated by the first workflow.

So the question becomes this (sorry that I didn't spot this earlier): How can we split the single workflow that generated both the runtime and UI parts into two workflows, one generating just the runtime and another generating just the UI parts (without regenerating the runtime parts)?

Here are our two workflows: Runtime part and UI part. Is something like this (letting the runtime project generate only rountine sources and the UI project generating only UI sources) even supported?
Re: Abstract*RuntimeModule generation woes [message #1176455 is a reply to message #1176446] Fri, 08 November 2013 10:45 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 13515
Registered: July 2009
Senior Member
Hi,

i have no idea on that. i dont know why grammar access fragment does no longer write a contribution.

i dont know if it i a good idea to have two workflows. i have never seen this.
are you sure this happens too when you run only one workflow?


Need professional support for Xtext, Xpand, EMF?
Go to: https://www.itemis.com/en/xtext/
Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Re: Abstract*RuntimeModule generation woes [message #1176468 is a reply to message #1176455] Fri, 08 November 2013 10:54 Go to previous messageGo to next message
Andreas Sewe is currently offline Andreas SeweFriend
Messages: 111
Registered: June 2013
Senior Member
Using just a single workflow works.

Alas, in a Maven/Tycho context we find it rather confusing when one project generates code for a sibling project. Hence the attempt to split the workflow into three parts: one generating the runtime stuff, one generating the UI stuff, and one generating the test stuff. I hope this makes sense to you.

Anyways, thanks for you help. It's always amazing how just talking (writing) to somebody helps you understand a problem much better.
Re: Abstract*RuntimeModule generation woes [message #1176517 is a reply to message #1176468] Fri, 08 November 2013 11:34 Go to previous message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 13515
Registered: July 2009
Senior Member
Hi,

yes this is understandable. never the less a language generator can generate always stuff to runtime and ui,
this the second run may kill the results from the first one.


Need professional support for Xtext, Xpand, EMF?
Go to: https://www.itemis.com/en/xtext/
Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Previous Topic:[Solved] sorting AST through quickfix
Next Topic:How to I force a re-validation of all xtext resources in a given project/workspace
Goto Forum:
  


Current Time: Tue Aug 04 21:02:27 GMT 2020

Powered by FUDForum. Page generated in 0.02166 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top