| Summary: | [pivot] Eliminate delegate prune workaround | ||
|---|---|---|---|
| Product: | [Modeling] OCL | Reporter: | Ed Willink <ed> |
| Component: | Core | Assignee: | OCL Inbox <mdt-ocl-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | Kenn.Hussey |
| Version: | 3.2.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows Vista | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 358570 | ||
|
Description
Ed Willink
Eliminating the OCL delegates is probably a good idea anyway. Once their functionality has been realised by OCL 2 Java translation, why should they remain? If someone really wants the Concrete Syntax OCL from the EAnnotations then we could add some static fields and an API. More significantly it is necessary to rewrite the UML genmodel annotations to ensure that the UML templates do not generate redundant artefacts for the old OCL interpreter now that the UML OpaqueExpressions turn into direct Java. Similarly, when performing a Complete OCL merge prior to genmodel, it is appropriate to do the in-memory rewrite so that conventional Ecore genmodel proceeds unaffected, apart from the now standard "body" and "get" annotations. [All OCL functionality in the UML genmodel templates is now redundant. I'm not aware of anyone using it. I only found it when re-use of Infrastructure.cmof gave me errors from the bad OCL therein.] CLOSED after a year in the RESOLVED state. |