| Summary: | @extends treated as @implements for classes | ||
|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Ed Willink <ed> |
| Component: | Core | Assignee: | Ed Merks <Ed.Merks> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 2.7.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows Vista | ||
| Whiteboard: | |||
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. |
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.]