Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 333957

Summary:	Provide integration for MWE's EcoreGenerator and Xtext's EcoreGeneratorFragment
Product:	[Modeling] TMF	Reporter:	Moritz Eysholdt <moritz.eysholdt>
Component:	Xtext	Assignee:	Project Inbox <tmf.xtext-inbox>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	knut.wannheden, sven.efftinge
Version:	unspecified	Flags:	moritz.eysholdt: indigo+
Target Milestone:	---
Hardware:	PC
OS:	Mac OS X - Carbon (unsup.)
Whiteboard:

Description Moritz Eysholdt

2011-01-11 05:09:17 EST

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.

Comment 1 Moritz Eysholdt

2011-01-11 05:37:23 EST

bug 329741 "[generator] make generated / referenced GenModels available to generator fragments" is related.

Comment 2 Knut Wannheden

2011-01-11 14:40:28 EST

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.

Comment 3 Sven Efftinge

2011-01-12 08:02:59 EST

(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

Comment 4 Knut Wannheden

2011-01-25 16:29:07 EST

(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.

Comment 5 Sven Efftinge

2012-11-19 08:49:57 EST

We should work on Xcore support instead.