Xtext: Calling the Generator from a Context Menu

Xtext offers the user to implement an Xtend Class that implements the org.eclipse.xtext.generator.IGenerator Interface. By Default this Generator is called by the Builder through a org.eclipse.xtext.builder.IXtextBuilderParticipant when saving the file. But what to do if I want to call the Generator explicitely through a context menu entry on the file as shown in the screenshot below? This will be shown in the Following example.

Grammar & IGenerator

We first start with writing the Grammar and after generating the language we implement the Generator Stub Xtext created for us.

Like this:

Related

Thank you very much for this post, it was exactly what I was looking for!!!

Is there also a possibility to enhance this approach, by automatically create a ‘src-gen’ folder, if there is none in the project? (if no ‘src-gen’ folder is available, no source files are generated, right?!)

Thank you Christian!
That’s how we use our Xtend generators now. Meanwhile, the EclipseResourceFileSystemAccess is deprecated (replaced by Ecl…Access2) and I would be interested in how your example would look like now. Beside the OutputPath, the new Ecl…Access2 needs a Monitor, a Project and a PostProcessor additionally…

this should be rather straight forward:
– the project we have already in our hand
– as a first step we can use a NullProgressMonitor (or we wrap the doing of our command into a job and take the jobs IProgressMonitor – nothing really Xtext Specific)
– for the IFileCallback provide a Implementation (that e.g. is doing nothing) yourself.

EclipseResourceFileSystemAccess is deprecation in Xtext SDK Version 2.3.0. If I use EclipseResourceFileSystemAccess2 I get a NullPointerException when staring the generation process:
——————————————————————————————————————–
java.lang.NullPointerException
at org.eclipse.xtext.builder.EclipseResourceFileSystemAccess2.generateFile(EclipseResourceFileSystemAccess2.java:116)
at org.eclipse.xtext.generator.AbstractFileSystemAccess.generateFile(AbstractFileSystemAccess.java:74)
at merses.ip.hdlGEN.morphGEN.generator.MIPGenerator.doGenerate(MIPGenerator.java:76)
at merses.ip.hdlGEN.morphGEN.ui.handler.GenerationHandler$2.run(GenerationHandler.java:159)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
——————————————————————————————————————–

I was just wondering how we would go about things if we wanted to invoke the generator from a java code context instead of a menu context. So if we could just create a file in the code, and then pass it to the code generator for our DSL? Furthermore could we use the JvmModelInferrer instead of the generator?

The nice example you provided seems to rely on the user having first opened the file in the editor. My use case is as follows: no matter which DSL file is selected, whether it has been opened in the editor or not, I need to generate code when the user right-clicks the file and selects “Generate Code”. Currently, if the file has not been opened, the ActiveEditor is null. Any suggestions or solutions? Thanks!

Hi Christian,
Great Blog! Great Xtext-Examples!
I know, this blogpost is quite old, but as a Xtext-Newbie I’m still trying to get your example running in my project. I hope you can give me a hint to solve the following problem:

I get a NullPointerException at this line (fileAccessProvider is null):
final EclipseResourceFileSystemAccess fsa = fileAccessProvider.get();

When I create a new blank Xtext project your example is working fine, but I need to use your example in my existing project. Why is the injected Provider null? Do I need to bind/configure/provide it in the MyDslUiModule?

Hi Christian,
Thanks for the blog.
I am able to activate the context on my custom(.xform) file.
The only problem i am facing is when i run eclipse as a product then the menu is somehow not activated
Any pointers will be helpful.

Ok i solved. I figured out that the error was in class attribute of the handler section of the plugin.xml file. I needed to add ‘org.xtext.example.mydsl.ui.MyDslExecutableExtensionFactory:[class handler name]’ to solve