Community
Participate
Working Groups
The beauty of Xtext's is that one can derive an ECore model from an Xtext Grammar and automatically generate the Java files without having to create the Ecore- and Genmodel-File manually. The beauty of MWE's EcoreGenerator is that the Java code generated from Ecore models can be customized via the generation gap pattern. It would be nice if these features could be used at the same time. Proposal: The EcoreGeneratorFragment should be able to pass an EPackage to the ECoreGenerator and get a GenPackage in return. The responsibilities would be: - The EcoreGeneratorFragment has to construct the EPackage - The ECoreGenerator has to construct the GenModel and run EMF's code generator. The GenPackage is needed in case any of Xtext's generator fragments needs to refer to Java Classes generated by EMF. Letting the EcoreGenerator construct the Genmodel allows for having multiple EPackages in the same Genmodel. The is necessary if there are two or more EPackages with cyclic references.
bug 329741 "[generator] make generated / referenced GenModels available to generator fragments" is related.
For a customer project we implemented an Xtext generator fragment which generates code in the same way the MWE EcoreGenerator does, but based on the models derived from (or imported by) the Xtext grammar. That worked like a charm, but we encountered two problems which I think should be considered in this context: 1. The MWE EcoreGenerator does only allow to specify a single source folder to look for custom classes (e.g. XyzImplCustom.java). When there are multiple Ecore models involved with inheritance spanning model boundaries this is typically not enough. We simply extended the generator fragment with the possibility to specify multiple source directories which will all be searched in order. 2. The generation gap pattern as implemented does not seem to be applicable to the Ecore package and factory classes. I have not looked into this, but I have a feeling this could be more difficult. It's unfortunate however, as overriding the conversions for EDataTypes in the factory class is not all that uncommon. We didn't investigate this issue any further.
(In reply to comment #2) > 1. The MWE EcoreGenerator does only allow to specify a single source folder to > look for custom classes (e.g. XyzImplCustom.java). When there are multiple > Ecore models involved with inheritance spanning model boundaries this is > typically not enough. We simply extended the generator fragment with the > possibility to specify multiple source directories which will all be searched > in order. I've opened a separate ticket fro this one https://bugs.eclipse.org/bugs/show_bug.cgi?id=334082
(In reply to comment #2) > > 2. The generation gap pattern as implemented does not seem to be applicable to > the Ecore package and factory classes. I have not looked into this, but I have > a feeling this could be more difficult. It's unfortunate however, as overriding > the conversions for EDataTypes in the factory class is not all that uncommon. > We didn't investigate this issue any further. Note: I reported this as bug 335089 against EMF. It has already been fixed in CVS HEAD (EMF 2.7). So in environments where EMF 2.7 is available the EcoreGenerator could now also be used for models like BuilderState.ecore.
We should work on Xcore support instead.
