Eclipse Community Forums: TMF (Xtext) » Abstract*RuntimeModule generation woes

Home » Modeling » TMF (Xtext) » Abstract*RuntimeModule generation woes

Abstract*RuntimeModule generation woes [message #1176292]

Fri, 08 November 2013 03:40

Eclipse User

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 04:20

Eclipse User

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

Re: Abstract*RuntimeModule generation woes [message #1176351 is a reply to message #1176345]

Fri, 08 November 2013 04:22

Eclipse User

PS: and why is the generated stuff under target/generated-sources/xtext

Re: Abstract*RuntimeModule generation woes [message #1176388 is a reply to message #1176351]

Fri, 08 November 2013 04:52

Eclipse User

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:

That different stuff gets generated depending on what is under "src"
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 04:57

Eclipse User

Hi,

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

Re: Abstract*RuntimeModule generation woes [message #1176446 is a reply to message #1176394]

Fri, 08 November 2013 05:38

Eclipse User

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 05:45

Eclipse User

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?

Re: Abstract*RuntimeModule generation woes [message #1176468 is a reply to message #1176455]

Fri, 08 November 2013 05:54

Eclipse User

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 06:34

Eclipse User

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.

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:

-=] Back to Top [=-

Current Time: Sun Jul 06 13:26:34 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter