eclipse-ocl-bot
commented
1 month ago By Ed Willink on Dec 16, 2021 04:31
(In reply to Ed Willink from comment #0)
1) Why was the built-in Standard Library loaded at all?
It shouldn't have been. Two tweaks can avoid the premature load and break 12 other tests instead.
Fundamentally we have potentially nine permutations of:
{read-only-built-in / complemented-cloned-built-in / custom} standard library\ {read-only-built-in / complemented-cloned-built-in / custom} pivot metamodel
Not all permutations are safe - must only reference non-read-only from non-read-only to avoid proxies.
The 99% use case of all read-only-built-in works fine. The other use cases lack clear definition and so there are too many APIs with magic lazy deduction of load needs/progress.
Need to clarify
A) How to declare a custom model
B) How to import a custom model
C) How lo load the custom/built-in models for use
A) Declaration by re-use of the URIs or Library rather than Package is too magic so we have Annotations that are inconsistently used for pivot metamodel / standard library. Need to make these annotations consistent in .ecore and .oclas.
B) Import could use a distinct library rather than import keyword, but it's all a bit magic. Should be able to import anything and react to the distinction annotation.
C) (Re-)loading should occur at a precise instant, so that asserts can diagnose too-soon / too-late coding errors.
For CS2AS, a suitable instant could be after the containment visitor has created all the primary AS tree (and probably before the containment continuations). Imports can be similarly containment-parsed so that the top level packages/libraries and their annotations are available. Pre-instant use of metamodel/library is forbidden.
For ES2AS, a suitable instant could be after XMI load, since top level EPackage and EAnnotations should be available from the outset.
It is not necessary to analyze imports transitively. If a specialized library needs a specialized metamodel, the consumer can and probably should specify both.
Once (re-)loading occurs at a single instant we should only need a single API. The diverse get/install/Library/Metamodel MetaModelmanager APIs and magic fields can mostly be deprecated in favour of a single clear EnvironmentFactory API.
For now just one test fails because validating the built-in standard library in the prior presence of a custom library leads to proxies. Just suppress validation of the built-in standard library for now.
2) Should the parser operation resolution break the choice between equally good candidates to favour the not-saveable built-in Standard Library version?
No. Fix the problem rather than mitigate its presence.
3) Should the proxy have resolved anyway in the next test?
Probably not. We're dealing with custom test projects.
4) Does this problem go away or just change once CompleteClasses go away?
It's an orthogonal issue.
| --- | --- | | Bugzilla Link | 577825 | | Status | NEW | | Importance | P3 normal | | Reported | Dec 15, 2021 09:35 EDT | | Modified | Mar 24, 2023 05:55 EDT | | Blocks | 581543 | | See also | 574430, 526813 | | Reporter | Ed Willink |
Description
After activating full Pivot Validation of ExpressionInOCL bodies, potentially triggering nested parses, testOCLstdlib_AS fails with unresolved proxies when run after testOCLstdlib.
The problem is that testOCLstdlib loads a custom Standard Library that occludes the complete-merged built-in Standard Library. OperationCallExp's within the built-in Standard Library resolve to the custom Standard Library. At the end of the test when the custom Standard Library is unloaded, the 'immutable' built-in Standard Library acquires proxies that fail to resolve in the following test.
1) Why was the built-in Standard Library loaded at all?
2) Should the parser operation resolution break the choice between equally good candidates to favour the not-saveable built-in Standard Library version?
3) Should the proxy have resolved anyway in the next test?
4) Does this problem go away or just change once CompleteClasses go away?