.genmodel issue in MWE workflow using XtextGenerator and EcoreGenerator

[tfonda-fbk]

Hi,
In my Xtext project I have a rather vanilla MWE2 workflow using a single component (XtextGenerator) with little to no tweaking. Recently, I've had the necessity to customize the code generated for the grammar elements without switching to a manually maintained metamodel. I was very happy when I learnt I could accomplish this goal by writing ***ImplCustom classes and have EcoreGenerator pick them up. So I modified my MWE2 workflow as explained here (and also here). My MWE2 workflow now looks like this:

Workflow {
	
	component = XtextGenerator {
		configuration = {
			project = StandardProjectConfig {
				baseName = "eu.fbk.sysmlv2"
				rootPath = rootPath
				runtimeTest = {
					enabled = true
				}
				eclipsePlugin = {
					enabled = true
				}
				eclipsePluginTest = {
					enabled = true
				}
				createEclipseMetaData = true
			}
			code = {
				encoding = "UTF-8"
				lineDelimiter = "\n"
				fileHeader = "/*\n * generated by Xtext \${version}\n */"
				preferXtendStubs = false
			}
		}
		language = StandardLanguage {
			name = "eu.fbk.sysmlv2.SysMLv2"
			fileExtensions = "sysml"

			serializer = {
				generateStub = false
			}
			validator = {
				// composedCheck = "org.eclipse.xtext.validation.NamesAreUniqueValidator"
				// Generates checks for @Deprecated grammar annotations, an IssueProvider and a corresponding PropertyPage
				generateDeprecationValidation = true
			}
			generator = {
				generateXtendStub = true
			}
			junitSupport = {
				junitVersion = "5"
			}
			parserGenerator = {
				debugGrammar = true
			}
		}
	}

	component = org.eclipse.emf.mwe2.ecore.EcoreGenerator {
		genModel = "platform:/resource/eu.fbk.sysmlv2/model/generated/SysMLv2.genmodel"
		srcPath = "platform:/resource/eu.fbk.sysmlv2/src"
	}

}

This does its job transparently when I work inside my Eclipse environment (I just run the workflow as before, the Xtext artifacts are regenerated and my custom classes are taken into consideration), but building now fails in any environment that uses a fresh git checkout of the project (such as our CI pipeline, which is building the project using Maven/Tycho, or my own computer after I run mvn clean):

0    [main] INFO  text.xtext.generator.XtextGenerator  - Initializing Xtext generator
feb 03, 2025 10:54:38 AM org.eclipse.emf.mwe.utils.StandaloneSetup addRegisterGeneratedEPackage
INFORMAZIONI: Adding generated EPackage 'org.eclipse.xtext.common.types.TypesPackage'
feb 03, 2025 10:54:38 AM org.eclipse.emf.mwe.utils.StandaloneSetup addProjectMapping
INFORMAZIONI: Registering project eu.fbk.sysmlv2 at 'file:/home/tfonda/devel/explodtwin/Code/SysMLv2/bundles/eu.fbk.sysmlv2/'
feb 03, 2025 10:54:38 AM org.eclipse.emf.mwe.utils.StandaloneSetup addProjectMapping
INFORMAZIONI: Registering project eu.fbk.sysmlv2.tests at 'file:/home/tfonda/devel/explodtwin/Code/SysMLv2/bundles/eu.fbk.sysmlv2.tests/'
feb 03, 2025 10:54:38 AM org.eclipse.emf.mwe.utils.StandaloneSetup addProjectMapping
INFORMAZIONI: Registering project eu.fbk.sysmlv2.ide at 'file:/home/tfonda/devel/explodtwin/Code/SysMLv2/bundles/eu.fbk.sysmlv2.ide/'
feb 03, 2025 10:54:38 AM org.eclipse.emf.mwe.utils.StandaloneSetup addProjectMapping
INFORMAZIONI: Registering project eu.fbk.sysmlv2.ui at 'file:/home/tfonda/devel/explodtwin/Code/SysMLv2/bundles/eu.fbk.sysmlv2.ui/'
feb 03, 2025 10:54:38 AM org.eclipse.emf.mwe.utils.StandaloneSetup addProjectMapping
INFORMAZIONI: Registering project eu.fbk.sysmlv2.ui.tests at 'file:/home/tfonda/devel/explodtwin/Code/SysMLv2/bundles/eu.fbk.sysmlv2.ui.tests/'
feb 03, 2025 10:54:38 AM org.eclipse.emf.mwe.utils.StandaloneSetup setResourceSet
INFORMAZIONI: Using resourceSet registry. The registered Packages will not be registered in the global EPackage.Registry.INSTANCE!
feb 03, 2025 10:54:38 AM org.eclipse.emf.mwe.utils.GenModelHelper registerGenModel
INFORMAZIONI: Registered GenModel 'http://www.eclipse.org/Xtext/Xbase/XAnnotations' from 'platform:/resource/org.eclipse.xtext.xbase/model/Xbase.genmodel'
feb 03, 2025 10:54:38 AM org.eclipse.emf.mwe.utils.GenModelHelper registerGenModel
INFORMAZIONI: Registered GenModel 'http://www.eclipse.org/xtext/xbase/Xtype' from 'platform:/resource/org.eclipse.xtext.xbase/model/Xbase.genmodel'
feb 03, 2025 10:54:38 AM org.eclipse.emf.mwe.utils.GenModelHelper registerGenModel
INFORMAZIONI: Registered GenModel 'http://www.eclipse.org/xtext/xbase/Xbase' from 'platform:/resource/org.eclipse.xtext.xbase/model/Xbase.genmodel'
feb 03, 2025 10:54:38 AM org.eclipse.emf.mwe.utils.GenModelHelper registerGenModel
INFORMAZIONI: Registered GenModel 'http://www.eclipse.org/xtext/common/JavaVMTypes' from 'platform:/resource/org.eclipse.xtext.common.types/model/JavaVMTypes.genmodel'
470  [main] ERROR mf.mwe2.launch.runtime.Mwe2Launcher  - Problems running workflow eu.fbk.sysmlv2.GenerateSysMLv2: java.io.FileNotFoundException: /home/tfonda/devel/explodtwin/Code/SysMLv2/bundles/eu.fbk.sysmlv2/model/generated/SysMLv2.genmodel (File o directory non esistente)
java.lang.RuntimeException: Problems running workflow eu.fbk.sysmlv2.GenerateSysMLv2: java.io.FileNotFoundException: /home/tfonda/devel/explodtwin/Code/SysMLv2/bundles/eu.fbk.sysmlv2/model/generated/SysMLv2.genmodel (File o directory non esistente)
	at org.eclipse.emf.mwe2.launch.runtime.Mwe2Runner.run(Mwe2Runner.java:105)
	at org.eclipse.emf.mwe2.launch.runtime.Mwe2Runner.run(Mwe2Runner.java:63)
	at org.eclipse.emf.mwe2.launch.runtime.Mwe2Runner.run(Mwe2Runner.java:53)
	at org.eclipse.emf.mwe2.launch.runtime.Mwe2Launcher.run(Mwe2Launcher.java:78)
	at org.eclipse.emf.mwe2.launch.runtime.Mwe2Launcher.main(Mwe2Launcher.java:36)
Caused by: org.eclipse.emf.ecore.resource.impl.ResourceSetImpl$1DiagnosticWrappedException: java.io.FileNotFoundException: /home/tfonda/devel/explodtwin/Code/SysMLv2/bundles/eu.fbk.sysmlv2/model/generated/SysMLv2.genmodel (File o directory non esistente)
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.handleDemandLoadException(ResourceSetImpl.java:319)
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoadHelper(ResourceSetImpl.java:278)
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResource(ResourceSetImpl.java:406)
	at org.eclipse.emf.mwe2.ecore.EcoreGenerator.preInvoke(EcoreGenerator.java:111)
	at org.eclipse.emf.mwe2.runtime.workflow.AbstractCompositeWorkflowComponent.preInvoke(AbstractCompositeWorkflowComponent.java:31)
	at org.eclipse.emf.mwe2.runtime.workflow.Workflow.run(Workflow.java:20)
	at org.eclipse.emf.mwe2.launch.runtime.Mwe2Runner.run(Mwe2Runner.java:103)
	... 4 more
Caused by: java.io.FileNotFoundException: /home/tfonda/devel/explodtwin/Code/SysMLv2/bundles/eu.fbk.sysmlv2/model/generated/SysMLv2.genmodel (File o directory non esistente)
	at java.base/java.io.FileInputStream.open0(Native Method)
	at java.base/java.io.FileInputStream.open(FileInputStream.java:213)
	at java.base/java.io.FileInputStream.<init>(FileInputStream.java:152)
	at org.eclipse.emf.ecore.resource.impl.FileURIHandlerImpl.createInputStream(FileURIHandlerImpl.java:99)
	at org.eclipse.emf.ecore.resource.impl.ExtensibleURIConverterImpl.createInputStream(ExtensibleURIConverterImpl.java:358)
	at org.eclipse.emf.ecore.resource.impl.PlatformResourceURIHandlerImpl.createInputStream(PlatformResourceURIHandlerImpl.java:581)
	at org.eclipse.emf.ecore.resource.impl.ExtensibleURIConverterImpl.createInputStream(ExtensibleURIConverterImpl.java:358)
	at org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1314)
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoad(ResourceSetImpl.java:259)
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoadHelper(ResourceSetImpl.java:274)
	... 9 more

Indeed, the .genmodel file does not exist in these scenarios, since we don't track any generated file in our git repository and/or it was deleted by mvn clean. What I cannot understand is why this new workflow requires the genmodel file to be present in advance, given that XtextGenerator re-generates it anyway and the EcoreGenerator component uses the newly generated one (or at least this is what I noticed running a few tests placing an older genmodel file where the workflow expects it, changing the grammar and verifying that the generated classes match the changes applied to the grammar, as I obviously desire).

For now, I've worked around this issue by checking in my genmodel file with git and making the necessary changes in my pom.xml to instruct Maven not to clean it, but I was wondering whether there is a way to keep the genmodel file untracked and have the workflow run normally without it, as it has always been. Any advice?

Thanks!

[LorenzoBettini]

If I remember correctly, but let's also hear from @szarnekow , the presence of the genmodel is still required because of your line "genModel = "platform:/resource/eu.fbk.sysmlv2/model/generated/SysMLv2.genmodel" and because the EcoreGenerator has to use information provided by the Genmodel.

[cdietrich]

i assume you need to switch to a manually maintained metamodel then

[LorenzoBettini]

In the original post he says:

I've had the necessity to customize the code generated for the grammar elements without switching to a manually maintained metamodel

[cdietrich]

maybe splitting into two workflows might work.
also thought we somewhere have an issue to support the customimpl stuff in emfgeneratorfragment2

[tfonda-fbk]

@cdietrich I am definitely going to look for such issue.
Splitting the workflow in two files (one with XtextGenerator, the other with EcoreGenerator) worked fine! I now have the original workflow file that runs XtextGenerator, and a second one running EcoreGenerator, to which I also had to add a StandaloneSetup component as described in the article from Christian's blog I linked above:

Workflow {
	bean = StandaloneSetup {
		platformUri = ".."
	}
	component = org.eclipse.emf.mwe2.ecore.EcoreGenerator {
		genModel = "platform:/resource/eu.fbk.sysmlv2/model/generated/SysMLv2.genmodel"
		srcPath = "platform:/resource/eu.fbk.sysmlv2/src"
	}
}

As an alternative approach, I have verified that writing my own extension of the EcoreGenerator class that only overrides the preInvoke() method with an empty implementation also works.
Many thanks Lorenzo and Christian!