Community
Participate
Working Groups
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).
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.
(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.
(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.
