[ui] Rationalize validators

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 532817 | | Status | RESOLVED FIXED | | Importance | P3 normal | | Reported | Mar 23, 2018 07:23 EDT | | Modified | Mar 28, 2018 10:49 EDT | | Reporter | Ed Willink |

Description

The standard Xtext functionality is to start a ValidationJob for the AnnotationIssueProcessor in XtextDocumentProvider.registerAnnotationInfoProcessor invoked by AbstractTextEditor.doSetInput.

In the absence of a builder OCL/QVTd editors installs ValidatingEditorCallback that starts a ValidationJob for the MarkerIssueProcessor in afterCreatePartControl.

Now that there is an OCL/QVTx builder there are multiple markers sources, which is at best confusing.

Presumably if there is a builder, the MarkerIssueProcessor ValidationJob must be killed to ensure markers are exvlusively related to the builder validation.

(The CompletionProposalsTests seems to provide an animation that demonstrates everything happening.)

Design choice: do we retain the MarkerIssueProcessor ValidationJob when there is no OCL/QVTx nature? KISS. The non-nature markers are an accidental consequence of editor usage. If the user wants markers, then a nature is required; just like Java etc.

[eclipse-ocl-bot]

By Ed Willink on Mar 23, 2018 12:02

Need to rationalize markers too.

Currently the OCL reports are variously EMF Problems or Xtext problems. The EMF problems fail to navigate to the source.

Probably need to report OCL problems that are derived EMF problems, but not derived Xtext problems; we need no Xtext marker inheritance; we just re-use the Xtext Issue processing which is richer than the EditUIMarkerHelper and might one help with quickfix support.

Identifying the correct marker is not easy. Potentially the org.eclipse.ui.ide.markerResolution extension point has some detail, but by default, Xtext has a marker-type bound by the relevant injector. The MultiValidatorJob needs multi-marker-types. Probably easiest to add an AbstractASResourceFactory.getMarkerType returning the marker-id string, with EMF as the fall-back/default.

[eclipse-ocl-bot]

By Ed Willink on Mar 24, 2018 04:36

(In reply to Ed Willink from comment #1)

Xtext has a marker-type bound by the relevant injector. The MultiValidatorJob needs multi-marker-types. Probably easiest to add an AbstractASResourceFactory.getMarkerType returning the marker-id string, with EMF as the fall-back/default.

But by the time an Issue is converted to a marker, the offending semantic object and so resource is long lost, unless we re-resolve the URI.

Options:

a) Add a marker-id field to Issue. IssueImpl is a private class so there is an unpleasant amount of code to clone.

b) Abandon the attempt at per-language problem markers; everything will be an Xtext problem, even though the use of the Xtext nature/builder/index is suppressed. Likely to get unpleasant/obscure interactions. Not user friendly.

c) Install a separate MultiValidator per language emulating the Xtext injector binding. Still need sharing to avoid separate QVTc/QVTi/QVTr/UMLX validators with a single QVTd nature and to avoid too many validators starting concurrently.

d) Pass a real-marker-id as part of the MultiValidator session request and then use the real-marker-id in an override of the Issue-to-Marker conversion.

d) seems a clear winner.

[eclipse-ocl-bot]

By Ed Willink on Mar 24, 2018 06:10

(In reply to Ed Willink from comment #1)

Probably easiest to add an AbstractASResourceFactory.getMarkerType returning the marker-id string

This breaks UI/non-UI modularity. The marker-id is an IDE-specific attribute that should not be known to the AS code.

Once we have the distinct OCL/QVTdBuilders passing the marker-id through the MultiValidatorJob, it is not so bad that each builder has a hard-coded extension to marker-id conversion, similar to the hard-coded builder parameters.

[eclipse-ocl-bot]

By Ed Willink on Mar 28, 2018 10:49

ValidatingEditorCallback bypassed.

MultiValidatorJob revamped using IProject-specific class loader.

Pushed to master for M7.