consolidate validation framework contributions

[abelhegedus]

There are a number of issues with the validation framework extensions and menu contributions:

• The Constraint annotation has the targetEditorId as a(n optional) parameter but it is not used by the code generator (only when deciding on removable extensions). However, it would be important to allow specific editors to be set (in addition to the currently used list of imported packages, which are not removed).
• Furthermore, there is a redundant "notifierDef" restriction, although we only use the editor based initialization at the moment and it's handler doesn't care about the selection.
• The generated contributions place the command into the EMF-IncQuery category while the GMF built-in definitions place the command at the top level of the menu. Additionally, the label of the default and generated menus are different.
• On my machine, the generated contributions do not appear in the appropriate editor (even when selecting a Notifier to circumvent the unneeded constraint). Also, even the default menu is missing when both commands use the same location URI (Ecore editor).
• There is a default command for the Ecore editor, although it is not needed as it is a special case (when someone writes a constraint over the Ecore metamodel)

[szabta89]

Should these issues be solved after the triggerengine based validation framework is commited?

[ujhelyiz]

These issues should be solved before the release 0.6.5, as this causes the validation framework not working, while the trigger engine based validation framework should not be included in this release.

As far as I know, the new validation engine is 100% compatible with the old API, so this should not cause any duplicate work.

[szabta89]

I have checked the various issues and my experiences are the following:

• the code generator uses the targetEditorId annotation parameter and sets it according to the import list
• the notifierDef is not redundant as if we omit this the 'Init. validators...' label will appear in the context menu without selection too.
• I have checked the validation engine with the school example and it worked fine.

[abelhegedus]

Thank you for taking time to look into the matter:

• the generator does not use the targetEditorId annotation parameter, it uses the import list to set the editorId parameter of the generated validation extension. (see this line)
• it is redundant in the case of editors with an editing domain, as the InitValidationOnEditor handler gets the model from the domain, not the selection (see this line).
• please check with the Ecore queries example, it may be that the two extensions for the same editor somehow cancel each other out (although I know that shouldn't be the case).

As a last question, did you use the original validation framework or the triggerengine based one? Similarly, I will double-check that I had each required plugin selected in my run configuration as that could cause some of the mentioned issues.

[szabta89]

I used the original validation framework here, I just want to make sure these issues are solved first.

[abelhegedus]

The validation framework and its code generator has been updated to address the issues outlined above.

• The current implementation stores the editors where the "initialize validation" menu is enabled in the constraint extension. This list is compiled using the import declarations and the spcified targetEditorId parameter of the annotation.
• Menu contributions are no longer generated as they are not needed.
• Legacy support is given by using a wildcard editor id for constraints without explicit editorIds.
• Users can still enable constraints for any editor with using targetEditorId="*". This is mentioned in the description of the parameter.

[abelhegedus]

Remaining issues:

• the menu contributions of the GMF and Graphiti editors are not consistent with the regular validation framework menu contribution.

[abelhegedus]

I'm marking the issue resolved after checking the GMF/Graphiti runtime projects for consistency.