search

eclipse-ocl / org.eclipse.ocl

Eclipse Public License 2.0
0 stars 0 forks source link

[pivot] Conflicting OCL's after GenModel diagnose #1942

Closed eclipse-ocl-bot closed 2 hours ago

eclipse-ocl-bot commented 2 hours ago

| --- | --- | | Bugzilla Link | 529484 | | Status | RESOLVED FIXED | | Importance | P3 normal | | Reported | Jan 07, 2018 05:47 EDT | | Modified | Jan 17, 2018 17:03 EDT | | Blocks | 529181 | | Reporter | Ed Willink |

Description

From Bug 529181. Subsequent to the introduction of custom EAnnotation validators, the Generate QVTd AS launch fails.

The problem is that the GenModel diagnose() now starts up OCL to validate embedded OCL in referenced Ecore's. These are managed by WeakOCLReference's to avoid unnecessary churning. Fine for the foirst AS model, but for the next, an old WeakOCLReference may allow a disposed OCL to be re-activated.

Either an explicit OCL dispose must really dispose, or perhaps mark dispose, or be of no consequence.

Really dispose is hard with out inverses to the WeakOCLReference.

Marking as dispose gives a scenario whereby an EnvironmentFactory may have many stale disposed adapters that need to be searched.

Why shouldn't an undisposed WeakOCLReference be re-useable? The problem is that an explicit OCL was created and disposed after the shared weak OCLs. The explicit OCL should have used the shared OCL.

NB multiple OCL's per Resource are possible.\ NB multiple OCL's per ResourceSet are not. User must use an additional REsourceSet.

Therefore, diagnose attempt to create multiple OCL's per ResourceSet / re-use the one.

eclipse-ocl-bot commented 2 hours ago

By Ed Willink on Jan 10, 2018 07:46

The problem was much aggravated by using the GenerateModel's clearResourceSet in default true polarity to generate successive models. The clearResourceSet successfully unloaded all the old Resources forcing a reload next time, but the metamodel schizophrenia disambiguation continued to remember the old Resource as the 'first loaded' so that nsURI references used a stale resource while platform resources used the new. The metamodel schizophrenia disambiguation for the first GenerateModel therefore created ambiguity for the second.

StandaloneProjectMap.PackageLoadStatus must forget its EPackage resolutions in response to a new reset() API.

eclipse-ocl-bot commented 2 hours ago

By Ed Willink on Jan 10, 2018 08:36

(In reply to Ed Willink from comment #1)

StandaloneProjectMap.PackageLoadStatus must forget its EPackage resolutions in response to a new reset() API.

This is just one of many improvements that are necessary to allow a ProjectMap to track project registrations throughout a long interactive Eclipse usage session.

May need to split into a 'global' ProjectMap that tracks the prevailing project state and a much lighter weight ProjectLoadStatus that provides the usage-specific resolution of ambiguous model references. It would be nice if the 'global' ProjectMap and EcorePlugin.ExtensionProcessor can share their analyses.

As a workaround just modify GenerateModel to diagnose a request to clearResourceSet when the ResourceSet is non-empty. It seems to be ok to just re-use the ResourceSet without clearing for multi-model OCL and QVTd MWE2 scripts.

Where that fails multiple ResourceSets can be defined.

eclipse-ocl-bot commented 2 hours ago

By Ed Willink on Jan 17, 2018 17:03

Diagnosis of unsupport clearResourceSet pushed to master for M5.

Raise a new bug if it's actually needed.