Bugzilla – Full Text Bug Listing
| Summary: | Cannot generate diagram with GMF-Tooling 2.4.0 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Modeling] GMF-Tooling | Reporter: | Mickael Istria <mistria> | ||||||
| Component: | Core | Assignee: | Michael Golubev <borlander> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | borlander | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | 2.4 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | 347960 | ||||||||
| Bug Blocks: | |||||||||
| Attachments: |
|
||||||||
|
Description
Mickael Istria
Created attachment 196415 [details]
Error log when generating
The Exception (Boolean expected (was: org.eclipse.emf.ecore.impl.DynamicEObjectImpl)!:in xpt::diagram::commands::CreateNodeCommand, line 104) while generating code Boolean expected (was: org.eclipse.emf.ecore.impl.DynamicEObjectImpl)!:in xpt::diagram::commands::CreateNodeCommand, line 104 is due to the upperBound.oclAsType(Integer) returning an OclInvalid_Class. After removing all the .oclAsType(Integer), all these errors are gone away. The problems are related to these changes in the OCL:
#261008 - [library] UnlimitedNatural erroneously conforms to Real (in our case - to Integer)
GMF has a couple of places where feature.upperBound is being casted and compared to integers, which is not allowed anymore.
And to this particular addition to the org.eclipse.ocl.EvaluationVisitorImpl, rev 1.8
public Object visitOperationCallExp(
...
if (opCode == PredefinedType.EQUAL) {
+ if (sourceVal == getInvalid()) {
+ return getInvalid();
+ }
// evaluate argument
OCLExpression<C> arg = args.get(0);
Object argVal = safeVisitExpression(arg);
+ if (argVal == getInvalid()) {
+ return argVal;
+ }
which explictly returns the oclUndefined when oclUndefined is being compared to anything. The previous version of OCL returned false in this cases and GMF has a lot of places where this is written without any ocIsUndefined checks.
Fortunately the first part of the problem is easily detectable: The unlimitedNatural may appear in the runtime only as a result of eCoreTypedElement.upperBound, so we may just replace all the occurrences like : «IF ecoreFeature.upperBound.oclAsType(Integer) > 0-» into «IF ecoreFeature.upperBound <> *-» and reasonably expect we are done with this part. The second part of the problem is much more difficult to detect beyond try-and-fix approach. Also this is the problem (added lines from the same commit as above). The old code returned null, the new code returns oclUndefined
case PredefinedType.FIRST:
// OrderedSet::first()
+ if (((Collection<?>) sourceVal).isEmpty()) {
+ return getInvalid();
+ }
return CollectionUtil.first((Collection<?>) sourceVal);
case PredefinedType.LAST:
// OrderedSet::last()
+ if (((Collection<?>) sourceVal).isEmpty()) {
+ return getInvalid();
+ }
return CollectionUtil.last((Collection<?>) sourceVal);
Created attachment 197102 [details]
Fixes the tests, but not necessary fixes the whole problem
Ok, the generation for the diagrams covered by test cases is fixed, as well as Taipan samples. I don't see how the problems described in the #347960 may be fixed easily for all generation flow paths, but the same approach as in the patch may be used for every particular case. So I am closing this bug. version -> 2.4 Rollback, Set target to 2.4 instead of accidenatlly set Version |