Community
Participate
Working Groups
For generation of model/edit/editor/test code from an ecore model, we currently have to * open the .genmodel file * for each code-generation type: * right-click in the editor to open the context menu * select the corresponding "Generate XYZ code" option * Wait for the generator to complete its task I'd like to have it that way: * change and save the .genmodel, implicitly triggering code generators to be run in the background i.e. an incremental project builder reacting to changes on .genmodel resources. This way, whenever * You "Reload" a genmodel * You update the genmodel from a source depot * You make manual changes to the genmodel the Java code you want will automatically be generated. This would allow us to avoid submitting generated code to our SCM system, but still have the 'import and it compiles' experience.
Created attachment 79462 [details] Implementation of a project builder running EMF code generators This implementation procides an incremental project builder for .genmodel files. The types of code to be generated (model/edit/editor/test) can be configured per project on a separate properties page. The builder is added to a project by using the "Add/Remove EMF Nature" from a project's context menu (it's what the 'new builder wizard' generated for me). It could surely use some polishing, but it works for me :)
I also did something similar for GMF, see bug 114209
I'm a little concerned about such a thing in general and compare it to https://bugs.eclipse.org/bugs/show_bug.cgi?id=193147 where we simply provide an action that allows you to regenerate all or some subset of models in the workspace. It's often the case that changing a .xsd or .ecore would require some model to regenerate so I imagine folks might want that detected an automated as well. It's also possible to make changes to a .ecore without actually changing the .genmodel at all (e.g., adding an EAnnotation to suppress accessor validity to to add a constraint can affect code generation without ever updating the GenModel itself). GenModel dependencies can also affect code generation, i.e., if a base model changes. It's also the case that at least for new models, folks often need to make changes before they generate, and it would be kind of bad if you have the editor open but end up doing another generation just because you did a save at the end. For big models that could be really annoying. Of course it's all optional by virtue of adding the builder nature or not, so it also seems like a generally cool thing to give people a choice to have. It would certainly be nice if https://bugs.eclipse.org/bugs/show_bug.cgi?id=193147 would allow the generator to run as a background job...
This builder works well for us since our model bases on a UML meta model. That is, after having changed something in the model, we always have to do a .genmodel reload. So there is no change in the model without .genmodel update. I guess that is not the case for a lot of (if not most) other projects. The builder is not as useful to those explicitly making the model changes (as they are aware of having made them) as it is to those getting the changes implicitly, for example by getting a new version of the .genmodel from a source depot. They just update their files, code is generated and everything compiles (hopefully ;)). They don't have to care or even know about EMF working in the background. This is also true for the initial import of a project containing EMF models.
Lucas, Would you consider this type of builder idea to be in the scope of the Ecore Tools project? I know you guys have defined a nature and I think that's needed to define a builder... If you think it belongs there, it might be better to move this to the Ecore Tools bugzilla component...
I'll have a chat with David Sciamma and ecoretools guys, but I definitly think it could be the right place. Give some days to explore and work on an RFE in relation with Ecore tools lead/team. regards,
Created attachment 88440 [details] reworked : Ecoretools genmodel builder contribution
I reworked contribution to make it compliant while submited the initial one in IPZilla. Waiting for approval before integration to CVS. What you guys are you thinking of creating a new org.eclipse.emf.ecoretools.codegen plugin to host this contribution ? I plan to add our search generation as part of this builder later on. regards,
delivered in Ecore Tools for 3.4 M5
