Bug 583197

Summary: [pivot] *.oclinecore.oclas / *.ecore.oclas confusion
Product: [Modeling] OCL Reporter: Ed Willink <ed>
Component: CoreAssignee: OCL Inbox <mdt-ocl-inbox>
Status: NEW --- QA Contact:
Severity: normal    
Priority: P3    
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Windows 10   
See Also: https://bugs.eclipse.org/bugs/show_bug.cgi?id=583185
https://bugs.eclipse.org/bugs/show_bug.cgi?id=583242
Whiteboard:

Description Ed Willink CLA 2024-04-25 06:07:41 EDT
Once we start fixing the Bug 583185 unload proxifying anomalies we find new problems with testValidate_Validate_completeocl that variously uses Validate.oclinecore and a round-tripped Validate.ecore.

Depending which is loaded we get Validate.oclinecore.oclas and/or Validate.ecore.oclas. "or" is clumsy, fragile and indeterminate. "and" is a recipe for trouble that we are now exposing.

There can only be one oclas. "ecore" is the primary extension. "oclinecore" is just one of many potential CS forms for the XMI ES.

Therefore Validate.oclinecore should load as Validate.ecore.oclas.

Once Validate.ecore.oclas exists, any further load of a Validate.oclinecore or Validate.ecore should be an update (merge).
Comment 1 Ed Willink CLA 2024-04-27 05:51:58 EDT
The unload in PivotMetamodelManager.loadResource seems only to be activated for testValidate_Validate_completeocl and seems deeply suspewct. The relevant control path szeems to be when Validate.oclinecore is loaded when Validate.ecore is already. The code seems to assuime that the external2as should load the Validate.ecxore again rather than merging the Validate.oclinecore.

The control flow in PivotMetamodelManager.loadResource is too complicated.

TIme to tackle the diversity of API in PivotMetamodelManager/AbstractEnvironmentFactory.

-----

Clean up goals:

Retain existing methods as deprecated delegations to new API.

PivotMetamodelManager has protected installXXX methods for AS only. install does not load. install is guarded against re-install.

AbstractEnvironmentFactory has clear public load{AS/CS/ES}XXX methods. ?? load is guarded against re-load.

PivotMetamodelManager has AS state.

AbstractEnvironmentFactory has CS/ES and CS2AS/ES2AS state.
Comment 2 Ed Willink CLA 2024-05-06 02:24:46 EDT
(In reply to Ed Willink from comment #0)
> There can only be one oclas.

> Once Validate.ecore.oclas exists, any further load of a Validate.oclinecore
> or Validate.ecore should be an update (merge).

No.

The problem test case involves a save of Validate.oclinecore as Validate.ecore, then population of a test ResourceSet with dynamic instances of the ecore. Subsequently in a new ResourceSet, the dynamic instances of Validate.ecore are validated using Validate.ocl that imports Validate.oclinecore. For the test case we 'know' that the two are the same, and in real usage the user should likewise 'know' and avoid the redundant loading; typically by importing Validate.ecore from Validate.ocl.

Locally the code cannot 'know' that the Validate.oclinecore import is redundant, so the load should happen and we do have two Models but they should be 'merged' by the CompleteModel. If there is a problem, the integrity of the CompleteModel needs fixing.

Therefore Validate.oclinecore loads as Validate.oclinecore.oclas, and Validate.ecore as Validate.ecore.oclas. They share the same Package uri so should contribute to a unifying CompleteModel --- no problem.
Comment 3 Ed Willink CLA 2024-05-10 04:43:37 EDT
(In reply to Ed Willink from comment #2) 
> Locally the code cannot 'know' that the Validate.oclinecore import is
> redundant, so the load should happen and we do have two Models but they
> should be 'merged' by the CompleteModel. If there is a problem, the
> integrity of the CompleteModel needs fixing.

A section of code formerly in PivotMetamodelManager.loadResource migrating to AbstractEnvironmentFactory.loadExternalElement is commented: "If this resource already loaded under its internal URI reuse old one". specifically contradicting the above discussion. For testValidate_Validate_completeocl it unloads the  Validate.oclinecore.oclas immediately after loading, since  Validate.ecore.oclas is already loaded.

Commenting out this code breaks no further OCL or QVTd test; just the wip broken testValidate_Validate_completeocl.
Comment 4 Ed Willink CLA 2024-05-22 06:37:42 EDT
The provocative testValidate_Validate_completeocl has an additional problem with multiple Validate.ecore:

Each of ocl1 and ocl2 independently loads Validate.oclinecore synthesizing a distinct Validate.ecore. testInstance1 and testInstance2 use the corresponding Validate.ecore and are in a shared test ResourceSet that has no Validate.ecore.

The Complete Model philosophy is that multiple AS models are merged within the complete model so there is no fundamental problem with 'duplicates'. But EValidation requires the EClass rather than Class. Tests such as testValidate_Validate_completeocl create multiple EClass and validate using the wrong one.

Successful validation requires that the EClass be part of a model loaded by the EnvironmentFactory andf without a search for alternative AS2Ecore solutions 'the' model.

Perhaps we maintain a global mapping from canonical file URI to EPackage so that multiple physicals are inhibited. THese could be found in the new AbstractEnvironmentFactory.extraResourceSet.

Perhaps we barf on usage that is as ambitious/stupid as testValidate_Validate_completeocl.