Bug 356243

Comment 1 Ed Willink 2011-08-30 15:36:00 EDT

property is_always_typed : Classifier<String> { ordered };

is also problematic (a syntax error)

Comment 2 Ed Willink 2012-01-05 01:42:35 EST

(In reply to comment #1)
> property is_always_typed : Classifier<String> { ordered };
> 
> is also problematic (a syntax error)

This is a variant of Bug 367523. OCLinEcore uses UML syntax so straight types are mandated.

Comment 3 Ed Willink 2012-01-05 01:49:35 EST

(In reply to comment #0)
> Save an OclInEcore file as Ecore with
> 
> property is_always_typed : OclAny { ordered };
> 
> Save could not be completed.
> 
> Reason:
> Unsupported pivot type 'OclAny' in Pivot2Ecore Reference pass

The immediate fix is to duplicate the visitVoidType case in Pivot2EcoreReferenceVisitor, which allows the Save to complete. But the round trip fails since the reconstructed type is EObject.

Need some mechanism to persist a reference to any OCL Standard Library type in Ecore.

Currently:
Integer etc are mapped reversibly to EBigInteger etc.
OclVoid, OclInvalid (and as above, OclAny) are mapped irreversibly to EObject.
what about OclElement, OclType, .... ?

Options:
reference an Ecore copy of the/a OCL Standard Library
reference a Pivot copy of the/a OCL Standard Library
create a bogus package of local synonym types

Comment 4 Ed Willink 2012-01-05 01:58:30 EST

Missing visitAnyType added and pushed to master; save no longer fails.

Commented out test case added for residual round tripping problem for OclAny.

Comment 5 Ed Willink 2013-03-18 05:31:42 EDT

see also Bug 401938

Comment 6 Ed Willink 2013-12-12 06:08:45 EST

commit 802cda12248bee4ee3c2e08113686a1d7587d173 pushed to master fopr M4 completes privision of a small oclstdlib.ecore that provides OclAny classes that can be referenced by *.ecore representations.

Comment 7 Ed Willink 2015-05-25 17:19:50 EDT

CLOSED after more than a year in the RESOLVED state.