In https://bugs.eclipse.org/bugs/show_bug.cgi?id=427152, I provided an extension that enabled validation of a UML model to validate the bodies of OpaqueExpressions; most notably embedded OCL, Use of an extension point could support any body language.
This Bug was WONTFIXED ensuring that Eclipse UML2 retained its narrow hard to extend focus.
As a consequence, by default, UML users are not implicitly informed about bad embedded bodies.
Eclipse OCL added an additional OCL->Validate context menu entry so that astute users could validate explicitly.
Eclipse OCL added a UMLOCLEValidator whose API enables Papyrus and other astute users to perform full validation.
Unfortunately EMF does not support a local validation registry analoguously to local PackageRegistry and ResourceFactoryRegistry. This forces inelegant tweaks to the global validation registry whenever improved validation needs configuration. This forces OCL to fight with EMF in order to workaround the UML2 inflexibility; never a good idea.
IMHO extensibility via extension points is at the heart of the Eclipse philosophy and it is a great shame that Eclipse UML2 has not followed that Eclipse philosophy. #135 is a clear example of where an extension point should have been introduced long ago.
@juergen-albert Do we want Eclipse UML2 to remain narrowly focussed on just the model, or extensibly focussed on what users need to do with the model?
In https://bugs.eclipse.org/bugs/show_bug.cgi?id=427152, I provided an extension that enabled validation of a UML model to validate the bodies of OpaqueExpressions; most notably embedded OCL, Use of an extension point could support any body language.
This Bug was WONTFIXED ensuring that Eclipse UML2 retained its narrow hard to extend focus.
As a consequence, by default, UML users are not implicitly informed about bad embedded bodies.
Eclipse OCL added an additional OCL->Validate context menu entry so that astute users could validate explicitly.
Eclipse OCL added a UMLOCLEValidator whose API enables Papyrus and other astute users to perform full validation.
Unfortunately EMF does not support a local validation registry analoguously to local PackageRegistry and ResourceFactoryRegistry. This forces inelegant tweaks to the global validation registry whenever improved validation needs configuration. This forces OCL to fight with EMF in order to workaround the UML2 inflexibility; never a good idea.
IMHO extensibility via extension points is at the heart of the Eclipse philosophy and it is a great shame that Eclipse UML2 has not followed that Eclipse philosophy. #135 is a clear example of where an extension point should have been introduced long ago.
@juergen-albert Do we want Eclipse UML2 to remain narrowly focussed on just the model, or extensibly focussed on what users need to do with the model?