[oclinecore] Explicit use of http://www.eclipse.org/emf/2002/GenModel annotation malfunctions

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 516301 | | Status | RESOLVED FIXED | | Importance | P3 minor | | Reported | May 08, 2017 06:09 EDT | | Modified | May 17, 2017 08:00 EDT | | Version | 6.1.2 | | Reporter | Bernhard Berger |

Description

Currently, I'm creating my model using the OCLinEcore editor and found an unexpected behavior when generating Java source code from the resulting model. I'm not quite sure if it is a OCLinEcore "bug" or a "bug" in the code generator.

Given the following model part:

class DocTest {\ operation test() : ecore::EInt {\ annotation _'http://www.eclipse.org/emf/2002/GenModel'\ (body = 'return 1;');\ }\ }

The generated code is for test looks like expected:\ public int test() {\ return 1;\ }

I then added some documentation to the method using a Java-style comment:\ class DocTest {\ / Documentation /\ operation test() : ecore::EInt {\ annotation _'http://www.eclipse.org/emf/2002/GenModel'\ (body = 'return 1;');\ }\ }

Regenerating the code results in an documented interface method but an empty method:\ public int test() {\ // TODO: implement this method\ // Ensure that you remove @generated or mark it @generated NOT\ throw new UnsupportedOperationException();\ }

The reason for this behavior is the fact that the documentation creates a second GenModel annotation that prevents the code generator from working correctly. If I add a documentation = '...' entry to the existing annotation (instead of using the / /-way) everything works fine. Therefore, I can workaround this problem. Nevertheless, I wanted to report the problem.

[eclipse-ocl-bot]

By Ed Willink on May 08, 2017 06:30

You have, hopefully accidentally, completely misused OCLinEcore.

You should specify your operation as:

/ Documentation /\ operation test() : ecore::EInt {\ body: 1;\ }

By using the explicit GenModel annotation you hijack the underlying mechanism that OCLinEcore uses to inject OCL2Java code into EMF's Ecore2Java code. Chaos ensues since you didn't study the code to see how to hijack safely..

You also deprive yourself of all OCL syntax help and checking.

---

OCLinEcore should detect or tolerate explicit GenModel annotations. Probably detect since I doubt that the Ecore2OCLinEcore translation can work.

[eclipse-ocl-bot]

By Bernhard Berger on May 15, 2017 10:57

For some reasons I've a mixed model. Some methods are specified in Java and some are specified in OCL. Just to note: The OCL methods do not use the Java methods. Furthermore, they cannot be expressed in OCL since they use some Java stuff. As you can guess the model has developed for quite a while (several years) and perhaps I should switch to abstract methods that will be implemented by custom subclasses and register my own factory. Nevertheless, I didn't expect the OCLinEcore editor to "silently" delete my implementation.

[eclipse-ocl-bot]

By Ed Willink on May 15, 2017 11:39

Surprisingly the OCLInEcore2AS2Ecore2AS2OCLInEcore round trip works fine, but when you look at the XMI I see the double Java annotation you observe.

<eOperations name="testJava">\
  <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">\
    <details key="documentation" value="Java Documentation"/>\
  </eAnnotations>\
  <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">\
    <details key="body" value="return 1;"/>\
  </eAnnotations>\
</eOperations>\
<eOperations name="testOCL">\
  <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">\
    <details key="documentation" value="OCL Documentation"/>\
  </eAnnotations>\
  <eAnnotations source="http://www.eclipse.org/emf/2002/Ecore/OCL/Pivot">\
    <details key="body" value="1"/>\
  </eAnnotations>\
</eOperations>

The double http://www.eclipse.org/emf/2002/GenModel for testJava is dubiously formed. Merging as you achieved with documentation = gives.

  <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">\
    <details key="documentation" value="Java Documentation"/>\
    <details key="body" value="return 1;"/>\
  </eAnnotations>

and the problem is solved.

OCLinEcore must not generate a second http://www.eclipse.org/emf/2002/GenModel.

[eclipse-ocl-bot]

By Ed Willink on May 16, 2017 05:48

(In reply to Ed Willink from comment #3)

OCLinEcore must not generate a second http://www.eclipse.org/emf/2002/GenModel.

Current As2Ecore.copyComments code seems to work needlessly hard to efficiently update multi-comments, which are in practice probably a typo. And since they cause GenModel to malfunction, the code can be simplified to just splice all multi-comments together, thereby successfully merging the troublesome mix of genmodel documentation and pivot comment.

Bug 509309 suggests a missing EMF validation that might have diagnosed this rather sooner.

[eclipse-ocl-bot]

By Ed Willink on May 16, 2017 07:34

commit d7e696b663c0268323e39ba883f3c021e72115b1 pushed to master for RC1

[eclipse-ocl-bot]

By Ed Willink on May 17, 2017 08:00

(In reply to Ed Willink from comment #5)

pushed to master for RC1

an M7a was needed and it includes this fix.