We're updating the issue view to help you get more done. 

Revisit concept of ConstraintLocation

Description

Is the ConstraintLocation abstraction still helpful or should its information be merged into the ConstrainedElement hierarchy?

In ValidatorImpl, there are still some references to methods from ConstraintLocation; ideally this shouldn't be the case as the validation routine should only work on the aggregated model, while ConstraintLocation (with properties for physical elements such as getMember() belongs to the raw model.

Environment

None

Status

Assignee

Unassigned

Reporter

Gunnar Morling

Components

Fix versions

Priority

Major