[pivot] Unloading a CSResource gives inconsistent proxies

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 582947 | | Status | REOPENED | | Importance | P3 normal | | Reported | Feb 17, 2024 03:01 EDT | | Modified | Jun 14, 2024 11:20 EDT | | Depends on | 583353 | | See also | 574041 | | Reporter | Ed Willink |

Description

When trimming the Complete OCL Loader EnvironmentFactory attaching so that leaks are 'avoided' the reference from an ImportCS which is an AS reference gets proxified 'correctly' but it is in the wrong ResourceSet so subsequent proxy re-resolution fails.

Workaround: never unload and require re-resoluition.

A 'correct' solution may require customisation of the getXXX methods.

[eclipse-ocl-bot]

By Ed Willink on Apr 23, 2024 06:57

Bug 583185 seems to provide a less hypothetical repro.

This bug has been marked as a duplicate of bug 583185

[eclipse-ocl-bot]

By Ed Willink on Jun 12, 2024 04:35

While the problems have some similarity, different fixes are needed than for Bug 583185.

To make unload work we have to ensure that proxies are consistently created.

The CS/AS comprises persisted resources so any proxies must reference ES/CS elements. Loading must convert the ES/CS to AS if appropriate. Conversely saving must convert AS to ES/CS.

Loading is resolved in eResolveProxy, unloading in eSetProxyURI.

Once we ensure that unloading happens and works we get ripples. For instance the QVTd tests such as testOCL2QVTi_Source2Target_CG whose models reference a *.ecore but use a pre-compiled EPackage failed toi ensure that the EPackage registration applied to the additional two ResourceSEts used during serialization. (A "Resource 'platform:/resource/org.eclipse.qvtd.cs2as.compiler.tests/models/Source2Target/EnvExample1.ecore' already loaded as 'http://cs2as/tests/example1/env/1.0'" diagnostic had been ignored for too long.)

[eclipse-ocl-bot]

By Ed Willink on Jun 13, 2024 15:12

The PivotableElementCS.pivot festure is a problem since it was designed to be set as a CS2AS side effect. unloading / reloading was not envisaged. It is transient not volatile and not derived. It has no proxy resolution so the main reload response fails.

The transient suggests that it should be lazily resolved by a normal load, so a reload need be no different. So the problem moves to a regular load from persisted CS.

[eclipse-ocl-bot]

By Ed Willink on Jun 14, 2024 11:17

(In reply to Ed Willink from comment #3)

So the problem moves to a regular load from persisted CS.

which of course requires CS XMI persistence to work. Oops it doesn't see Bug 583353.