eclipse-ocl / org.eclipse.ocl

Eclipse Public License 2.0
0 stars 0 forks source link

[pivot] Support OCLstdlib AS XMI references #2291

Open eclipse-ocl-bot opened 2 weeks ago

eclipse-ocl-bot commented 2 weeks ago

| --- | --- | | Bugzilla Link | 582053 | | Status | NEW | | Importance | P3 normal | | Reported | Jun 12, 2023 05:31 EDT | | Modified | Jun 22, 2024 06:11 EDT | | Depends on | 583353 | | See also | 579025 | | Reporter | Ed Willink |

Description

Adding a roundtrip test of Pivot.oclas fails.

Changing PivotStucturalecore to make TemplateableElement.unspecializedElement non-transient and testPivot_AS_resource/bundle fails.

Problem is that the ...oclstdlib.oclas#xxxxx does not load the ...oclstdlib.

oops there is no OCLstdlibASResourceImpl to perform the auto CS2AS.

Fixing that and we hit a problem with the Bug 579025 assertion that checks that no early LUSSID assignment occurs.

From Bug 579025: "So. We do not need LUSSIDs till save. ASResourceImpl.getURIFragment does not need to create LUSSIDs."

No, for derived ASResources (resulting from CS2AS) whose creation is triggered by a load reference rather than editor, we must allocate the LUSSIDs at the end of load. Thereafter the derived resource should be immutable.

eclipse-ocl-bot commented 2 weeks ago

By Ed Willink on Jun 12, 2023 08:28

(In reply to Ed Willink from comment #0)

Changing PivotStucturalecore to make TemplateableElement.unspecializedElement non-transient and testPivot_AS_resource/bundle fails.

No. problem was too much customization of TemplateableElement.unspecializedElement; needed resolveProxies and re-instated default functinality.

eclipse-ocl-bot commented 2 weeks ago

By Ed Willink on Jun 12, 2023 10:40

(In reply to Ed Willink from comment #0)

Adding a roundtrip test of Pivot.oclas fails.

...

oops there is no OCLstdlibASResourceImpl to perform the auto CS2AS.

All working on ewillink/582053

Fixing that and we hit a problem with the Bug 579025 assertion that checks that no early LUSSID assignment occurs.

Problem seems to go away once the missing resolveProxies/transient is fixed.

eclipse-ocl-bot commented 2 weeks ago

By Ed Willink on Jun 19, 2023 03:36

(In reply to Ed Willink from comment #0)

Adding a roundtrip test of Pivot.oclas fails.

But this remains a problem. It seems that conversion of EAnnotation is pretty patchy. Some are converted. Some are pruned, correctly when they represent Pivot semantics such as nullFree, erroneously when e.g. ExtendedMetaData is suppressed.

Supporting all EAnnotations detects a collision for Ecore.ecore whereby the distinct ExtendedMetaData eAnnotations for e.g. EBoolean/EBooleanObject are inconsistent for Boolean. (UML adds further opportunities for confusion with its Boolean from the types package).

If roundtripping is to work, each e.g. 'Boolean' should map to a distinct PartialClass. These are merged via the CompleteClass for Boolean. This potentially makes the DataType.behavioralClass redundant since it will always be the CompleteClass. Once CompleteClass and PartialClass share the Class inheritance, the need to choose a primaryClass for the behavioralClass should go away.

eclipse-ocl-bot commented 2 weeks ago

By Ed Willink on Jun 21, 2023 06:07

(In reply to Ed Willink from comment #3)

If roundtripping is to work, each e.g. 'Boolean' should map to a distinct PartialClass.

This is exactly what happens.

Supporting all EAnnotations detects a collision for Ecore.ecore whereby the distinct ExtendedMetaData eAnnotations for e.g. EBoolean/EBooleanObject are inconsistent for Boolean.

Yes. It is Ecore2AS.resolveDataTypeMappings that causes the problem by replacing EBoolean by Boolean so that the EBoolean Annotations are merged into the immutable stdlib Boolean. It is not clear that Ecore2AS.resolveDataTypeMappings does anything useful. Eliminating it causes one triple of DelegatesTest to fail with a "String"/"ecore::EString" spelling difference in a diagnostic. The new spelling with EString seems more precise.

eclipse-ocl-bot commented 2 weeks ago

By Ed Willink on Jun 21, 2023 06:55

(In reply to Ed Willink from comment #4)

It is not clear that Ecore2AS.resolveDataTypeMappings does anything useful.

The first half initialiazing ecore2as is ok. It is the second half that augments the creation map that must be deleted.

eclipse-ocl-bot commented 2 weeks ago

By Ed Willink on Jun 22, 2024 06:01

The ewillink/582053 branch has never been merged to master.

The need for *.oclas references is also addressed by 583353; a CS resource is not saveable. Solve that fiorst then revist the branch.