devboost / emftools Goto Github PK

Now, a new source folder is created and within it the original package.name.impl is replaced by package.name.custom. This way a constructor of the custom class must be public which might not be intended in most cases. Enhancement: name the new source folder src-custom and keep the original package name.

The new _Metaclass_Custom java class is generated but the operation is not propagated to the ecore file and the factory is not recognized and thus not modified.

It would be nice if EMF Customize had support for derived features. Derived features must be implemented as well und thus are good candidates for customizing generated code. But currently, if one overrides a getMyDerivedFeature() method in a custom class the getMyDerivedFeature will be propagated as operation to the metaclass.

The principle of the generation gap pattern of EMFCustomize has more potential than only propagating implemented methods in the custom class into the corresponding EClass. Quite often one wants to override other methods of the generated Impl class. E.g., when setting an EReference to be derived a possibility to maintain the internal list for the derived reference is to override eNotify(Notification notification). For the known reasons it's not reasonable to do this in the generated Impl class. It might be better to do this in the custom class. But it makes no sense that eNotify(Notification notification) is propagated as EOperation into in the ecore model. So my recommendation is to introduce a new annotation, let's say @model, and EMFCustomize then will only propagate the annotated methods to the ecore model.
@jjohannes: what do you think?

scenario:

• abstract superclass has method with parameter of type EObject.
• concrete subclass is customised
• add method of signature of the superclass method
• method is propagated to the ecore model but the parameter has no type