[pivot] *.oclinecore.oclas / *.ecore.oclas confusion

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 583197 | | Status | NEW | | Importance | P3 normal | | Reported | Apr 25, 2024 06:07 EDT | | Modified | Sep 08, 2024 10:09 EDT | | Depends on | 583353 | | See also | 583185, 583242 | | Reporter | Ed Willink |

Description

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).

[eclipse-ocl-bot]

By Ed Willink on Apr 27, 2024 05:51

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.

[eclipse-ocl-bot]

By Ed Willink on May 06, 2024 02:24

(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.

[eclipse-ocl-bot]

By Ed Willink on May 10, 2024 04:43

(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.

[eclipse-ocl-bot]

By Ed Willink on May 22, 2024 06:37

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.

[eclipse-ocl-bot]

By Ed Willink on Jun 22, 2024 06:09

Bug 583353 has the simpler precursor problem:

load .ocl\ save as .oclcs\ load again

[eclipse-ocl-bot]

By Ed Willink on Sep 06, 2024 04:58

Development of testValidate_Simple_oclinecore_and_ocl as pat of trying to develop a JUnit test for the ValidationTutorial hits a related problem.

Simple.oclinecore is opened and saved as Simple.ecore.

Then Simple.ocl is opened importing Simple.ecore. This hots a variety of inadequate AS2Ecore$InverseConversion issues that lead to unloading of the AS and consequent proxifying of the CS that then fails to resolve the import.

If we are keeping Simple.ecore.oclas and Simple.oclinecore.oclas as distinct contributions to the Complete model, why do we unload?

testValidate_Validate_completeocl seems to be the only test that uses the unload control path.

[eclipse-ocl-bot]

By Ed Willink on Sep 06, 2024 11:01

(In reply to Ed Willink from comment #6)

If we are keeping Simple.ecore.oclas and Simple.oclinecore.oclas as distinct contributions to the Complete model, why do we unload?

Surely PivotMetamodelManager.loadResource(URI, String, ResourceSet) loads a Resource or re-uses an already loaded Resource? If the user wants to unload a previous model surely the user must unload explicitly?

[eclipse-ocl-bot]

By Ed Willink on Sep 08, 2024 10:09

(In reply to Ed Willink from comment #6)

testValidate_Validate_completeocl seems to be the only test that uses the unload control path.

and it is a mis-test; the unload contrives to make the wrong OCL work rather than report an error.