Community
Participate
Working Groups
The following fragment of an auto-generated validator is manually edited to include an @extends and a manual change to the extended class. ---------- import org.eclipse.emf.ecore.util.EObjectValidator; import org.eclipse.ocl.examples.xtext.oclinecore.validation.OCLinEcoreEObjectValidator; /** * <!-- begin-user-doc --> * The <b>Validator</b> for the model. * @extends OCLinEcoreEObjectValidator * <!-- end-user-doc --> * @see company.CompanyPackage * @generated */ public class CompanyValidator extends OCLinEcoreEObjectValidator { ----------- after regeneration the final line is not preserved. It becomes: ----------- public class CompanyValidator extends EObjectValidator implements OCLinEcoreEObjectValidator { ----------- suggesting that @extends is only supported properly for interfaces. [Perhaps this is an enhancement since at the end of ch 10 of the EMF book, @implements is described as an additional facility for classes without indicating that @extends changes behaviour for classes.]
It's working as designed. You can imagine that changing that design can break existing usage. Use @generate not to have control over both the extends and the implements of a class.
I tried @generate NOT on the class, but that disables regeneration of internal class fields too.
That's why I said use "@generated not" rather than "@generated NOT" because for class/interfaces, the later disables all merging, including for nested content while anything other than "NOT" disables merging only for the "header" itself.
Thanks; should have read more thoroughly.
