Community
Participate
Working Groups
If/when a Java body is expression is specified for an operation and code is generated for the model using EMF (via the UML importer), the code for the method is generated twice - once in the method itself and once in the operations class. If/when operations classes are enabled, the code should only be generated in one place - in the operations class.
On second thought, the code should be generated into the method implementation (only) and NOT into the operations class. This is more backwards compatible, since existing code suffering from this (if any) will already have method implementations written from the perspective of an instance method and redundant implementations in the operations classes which are benign. Also, the intent behind operations classes is to avoid having to implement methods more than once in a hierarchy with multiple inheritance (such as that of UML), and this is already address in the case of Java body expressions by virtue of including the code as annotations (in one place) on the Ecore model. There are currently three cases where methods do not delegate to an operations class, namely where any of the following have been specified for a given operation: 1. a method body 2. an invariant expression (as of EMF 2.6) 3. an invocation delegate (as of EMF 2.6) The code that generates (redundant) method body code should be removed from the template for operations classes and the criteria for generating a method into an operations class should be modified to exclude operations that meet any of the above three criteria.
The fix has been committed to CVS.
The fix is available in the RC1 build.
Closing for Indigo release.
