[Markers] Missing problem marker target for "The required feature 'base_Interface' of ..."

[eclipse-uml2-bot]

| --- | --- | | Bugzilla Link | 529767 | | Status | NEW | | Importance | P3 normal | | Reported | Jan 12, 2018 15:04 EDT | | Modified | Jan 13, 2018 18:55 EDT | | Depends on | 529780 | | Reporter | Ed Willink |

Description

(The new EAnnotationValidator support provokes OCL to provide a nature/builder that auto-validates OCL embedded in Ecore or UML. This highlights some very poor functionality.)

Validating http://git.eclipse.org/c/ocl/org.eclipse.ocl.git/tree/plugins/org.eclipse.ocl/model/OCLCST.uml, which has hardly changed for many years, in the UML Model Editor shows over 100 errors

Most of these take the form "The required feature 'base_Interface' of 'EClass -> <> DefCS' must be set"

Double clicking in the Problems View does not navigate to the corresponding problem object in the UML editor. This is usually due to a bad/missing eObject argument for the BasicDiagnostic.data[].

(In contrast double clicking "The feature 'target' of '' with 0 values must have at least 1 values" navigates as expected.)

[eclipse-uml2-bot]

By Kenn Hussey on Jan 12, 2018 15:45

I suspect this happens because the offending objects are stereotype applications, which are suppressed from the tree view of the UML editor. I was going to suggest intercepting the lookup attempt and redirecting it to the base element instead, but that won't work if the base element reference is empty (which is the exact problem being reported)...

[eclipse-uml2-bot]

By Christian Damus on Jan 12, 2018 15:53

(In reply to Kenn Hussey from comment #1)

Perhaps stereotype applications whose base element is either unset or unresolved should be shown in the editor, so that they user may notice that they are broken.

[eclipse-uml2-bot]

By Kenn Hussey on Jan 12, 2018 15:59

(In reply to comment #2)

(In reply to Kenn Hussey from comment #1)

Perhaps stereotype applications whose base element is either unset or unresolved should be shown in the editor, so that they user may notice that they are broken.

Yes, the logic that suppresses their display could be modified to only suppress those with values for their base elements. Contributions are most welcome.

[eclipse-uml2-bot]

By Ed Willink on Jan 12, 2018 17:19

Bug 529780 highlights that the real problem is a missing child element for the stereotype application.

Since the Problem Marker navigation occurs via a URI, it may be possible to do some heroic EMF overloading to redirect the URI to the stereotype application feature in the stereotyped class' properties page.

[eclipse-uml2-bot]

By Kenn Hussey on Jan 13, 2018 11:52

(In reply to comment #4)

Bug 529780 highlights that the real problem is a missing child element for the stereotype application.

As I've just commented there, it doesn't make sense to show stereotype applications as children of their base elements because they aren't.

Since the Problem Marker navigation occurs via a URI, it may be possible to do some heroic EMF overloading to redirect the URI to the stereotype application feature in the stereotyped class' properties page.

IMO, it should navigate to the base element (if such a reference exists); otherwise, it should navigate to the stereotype application element itself (assuming it is being displayed in the editor as Christian has suggested).

[eclipse-uml2-bot]

By Kenn Hussey on Jan 13, 2018 18:55

(In reply to comment #1)

I suspect this happens because the offending objects are stereotype applications, which are suppressed from the tree view of the UML editor. I was going to suggest intercepting the lookup attempt and redirecting it to the base element instead, but that won't work if the base element reference is empty (which is the exact problem being reported)...

Actually, given additional context from bug 529769 I believe the stereotype application in this particular case does actually have a base element (a class), just not a base interface. I should have realized this based on the way the stereotype application label was rendered (with a reference to the "DefCS" base class). So navigating to the base element (the "DefCS" class) would in fact be a viable solution in this particular scenario.

(In reply to comment #5)

As I've just commented there, it doesn't make sense to show stereotype applications as children of their base elements because they aren't.

Actually, since the Ecore editor has already set a precedent of displaying child tree elements for things that aren't strictly children (in the containment sense), it may not be such a bad idea to optionally allow stereotype applications to be displayed as child tree elements of their base elements.

Since the Problem Marker navigation occurs via a URI, it may be possible to do some heroic EMF overloading to redirect the URI to the stereotype application feature in the stereotyped class' properties page.

IMO, it should navigate to the base element (if such a reference exists); otherwise, it should navigate to the stereotype application element itself (assuming it is being displayed in the editor as Christian has suggested).

I just took a look and diverting navigation to a base element instead of its referring stereotype application should be a simple matter of further customizing the UMLEditor#gotoMarker(IMarker) method. The default behavior could be to navigate to the base element of a stereotype application or, if the stereotype application is being rendered as a tree element (either because it has no resolvable base element or because an option has been added to display stereotype applications as child tree elements has been added and enabled per bug 529780) it would just navigate to that (using the existing behavior).