eclipse-ocl-bot
commented
3 weeks ago By Ed Willink on Oct 02, 2023 03:39
While cleaning up EValidatorRegistry usage, it is surely time to see to what extent it is now possible to use EAnnotationValidator as the extension hook to enable OCL to extend EMF.
OCLinEcoreEObjectValidator is perhaps unavoidable to support custom messages pending resolution of Bug 337792.
PivotEObjectValidator can perhaps be deprecated in favour of an EAnnotationValidator.
CompleteOCLEObjectValidator could be migrated to an EAnnotationValidator, but adding triggering EAnnotations to an installed EMF model is just a different bad global abuse practice.
| --- | --- | | Bugzilla Link | 582494 | | Status | NEW | | Importance | P3 normal | | Reported | Sep 29, 2023 07:27 EDT | | Modified | May 23, 2024 05:34 EDT | | Blocks | 532757 | | See also | 510503, 337792, 571755, 582722, 583269 | | Reporter | Ed Willink |
Description
Whereas e.g PackageRegistry has a local ResourceSet-specific variant that delegates to the global PackageRegistry, the global ValidationRegistry has no ResourceSet-specific counterpart. OCL needs to enhance Ecore / UML validators to also validate embedded OCL, so OCL installs ComposedEValidators in the global registry that augment the standard validator with a PivotEObjectValidator.
Modifying the global registry is not a good practice. Every time stronger assertions are added to pivot code, JUnit tests seem to break, typically for one of the EditTests running after a UMLValidateTest. The problem is that the UML test modifies the global validation registry with extra validation. Later when an EditTest of e.g a custom OCLstdlib validates, it finds that it has a new and old OCLstdlib and gets confused. Arguably this should be avoided by a distinct tooling ResourceSet; see Bug 510503, but the changed global registry is also bad.
EValidatorRegistryImpl actually supports delegation just like the PackageRegistry, so EMF is only half as broken as it previously appeared. There are two problems to solve.
a) Maintain a local ResourceSet EValidatorRegistry. This is easily achieved by deriving Adapter functionality onto EValidatorRegistryImpl.
b) Ensure that the local ResourceSet EValidatorRegistry is used. This 'just' requires that the Diagnostician 'creation' uses new Diagnostician(localValidationRegistry) rather than Diagnostician.INSTANCE. This is easy for OCL-aware functionality, but hard for OCL-blind functionality such as the Sample Ecore Model Editor, UML Model Editor and Papyrus. The first two are already a problem and so we already have the OCL-aware OCL->Validate menu entry. Papyrus is semi-OCL-aware so if necessary we can tweak a couple of lines of Papyrus code.
For fuller compatibility we could continue to displace global EValidatorRegistry entries but with a DelegatingEValidator that is ResourceSet-aware and so able to uninstall itself once the OCL-ResourceSet disposes.