Community
Participate
Working Groups
When creating a new Xtext project (using the new experimental generator configuration) and running the workflow the generated AbstractMyDslSemanticSequencer contains errors. It has references to a non existant sequencer of the terminals grammar: @Inject protected Provider<TerminalsSemanticSequencer> superSequencerProvider; protected TerminalsSemanticSequencer superSequencer; Somehow this doesn't seem to happen for Xtype. (I also think we may want to remove or comment out the ParseTreeConstructorFragment from the experimental generator configuration, as we can only ever have one ISerializer.)
(In reply to comment #0) > (I also think we may want to remove or comment out the > ParseTreeConstructorFragment from the experimental generator configuration, as > we can only ever have one ISerializer.) Yes, of course. Please go ahead.
(In reply to comment #0) > (I also think we may want to remove or comment out the > ParseTreeConstructorFragment from the experimental generator configuration, as > we can only ever have one ISerializer.) Thanks for the hint. Pushed to master.
(In reply to comment #2) > > Thanks for the hint. Pushed to master. That was quick :-) I was just about to do it myself. I also thought about adding two comments to the StandaloneSetup: bean = StandaloneSetup { scanClassPath = true platformUri = "${runtimeProject}/.." // registerGenModelFile = "platform:/resource/org.eclipse.xtext.xbase/model/Xbase.genmodel" // registerGenModelFile = "platform:/resource/org.eclipse.xtext.common.types/model/JavaVMTypes.genmodel" } But wouldn't it actually make more sense if the EcoreGeneratorFragment also registered its referencedGenModels (provided that they haven't already been registered)? That would save the developer some duplication (and trouble!). If I currently don't add corresponding registerGenModelFile elements to StandaloneSetup I may get errors like the following error when running the workflow: 5135 ERROR CompositeGeneratorFragment - No GenModel for EPackage 'http://www.eclipse.org/xtext/xbase/Xbase' is registered. java.lang.RuntimeException: No GenModel for EPackage 'http://www.eclipse.org/xtext/xbase/Xbase' is registered. at org.eclipse.xtext.generator.GenModelAccess.getGenPackage(GenModelAccess.java:81) at org.eclipse.xtext.generator.serializer.AbstractSemanticSequencer.genMethodCreateSequence(AbstractSemanticSequencer.java:463) at org.eclipse.xtext.generator.serializer.AbstractSemanticSequencer.getFileContents(AbstractSemanticSequencer.java:409) at org.eclipse.xtext.generator.serializer.SerializerFragment.generate(SerializerFragment.java:92)
Knut, I was probably too fast. Please update / fix the experimental configuration to make it as easy as possible to create a language that reuses Xbase. Thanks!
(In reply to comment #4) > I was probably too fast. > Please update / fix the experimental configuration to make it as easy as > possible to create a language that reuses Xbase. > Currently it would help to add the proposed comments to StandaloneSetup. But then you end up with the same list of referenced GenModels (in comments) for both the StandaloneSetup and the EcoreGeneratorFragment! So I'm wondering if it wouldn't make more sense to change the EcoreGeneratorFragment to additionally also register all referenced GenModels in EcorePlugin.getEPackageNsURIToGenModelLocationMap(). Then the developer would not have to add them to the StandaloneSetup (and we wouldn't have to change the configuration again :-)). Any other thoughts?
(In reply to comment #5) > So I'm wondering if it wouldn't make more sense to change the > EcoreGeneratorFragment to additionally also register all referenced GenModels > in EcorePlugin.getEPackageNsURIToGenModelLocationMap(). Then the developer > would not have to add them to the StandaloneSetup (and we wouldn't have to > change the configuration again :-)). Yes, I think we should do that. Would make it more consistent. All the components needing genmodels should retrieve them from the EMF singleton. The EcoreGeneratorFragment should register dynamically created and explicitly configured genmodels in the singelton. The configuration of genmodels in any generator component should be marked Deprecated and the use of the StandaloneSetup should be encouraged. Does that work? Moritz?
I moved the actually reported issue to a new ticket since this one was highjacked by the genmodel-situation
(In reply to comment #6) > (In reply to comment #5) > > So I'm wondering if it wouldn't make more sense to change the > > EcoreGeneratorFragment to additionally also register all referenced GenModels > > in EcorePlugin.getEPackageNsURIToGenModelLocationMap(). Then the developer > > would not have to add them to the StandaloneSetup (and we wouldn't have to > > change the configuration again :-)). > > Yes, I think we should do that. Would make it more consistent. > > All the components needing genmodels should retrieve them from the EMF > singleton. > > The EcoreGeneratorFragment should register dynamically created and explicitly > configured genmodels in the singelton. The configuration of genmodels in any > generator component should be marked Deprecated and the use of the > StandaloneSetup should be encouraged. > > Does that work? Moritz? yes. I'll provide an implementation.
fixed; pushed to master; The EcoreGeneratorFragment now collects all referenced EPackages from the to-be-generated EPackage. Then, the corresponding GenModel from the registry are obtained and added to the list of "usedGenModels". If no GenModel is found, a warning is logged but generation continues. EcoreGeneratorFragment.setReferencedGenModels(String) is now deprecated. For backward compatibility, its GenModels are now added to the registry on EcoreGeneratorFragment.generate() and before the GenModel is created.
throw an error if no GenModel is found for an EPackage instead of logging a warning.
fixed; pushed to master;
Closing all bugs that were set to RESOLVED before Neon.0
