Community
Participate
Working Groups
EMF M3 has partially responded to Bug 358570 by adding support for a "get" detail, but at lower priority that a setting delegate. As a workaround the OCL code generator therefore eliminates all OCL delegates and caches their identity during pregenerate so that the normal EMF generate proceeds as required, and so that the subsequent OCL generate can still distinguish delegated packages. Once/if the revised patch to Bug 358570, some klunky code in OCLGenModelGeneratorAdapter can be removed.
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.
