Community
Participate
Working Groups
[Axel: after re-reading your description of Impact Analysis and EMF Editor integration, it was much more obvious. Must have been a 'blonde' day.] A facility that I think TopCased offers is a check box overview of the available constraints so that there is a hierarchical GUI context for failures, rather than the flat problem view, and so that individual constraints can be switched off and retried. This seems like a natural extension of the Revalidator EMF Editor integration. With the Impact Analyzer offering a much more complex suite of validations, a much stronger GUI is probably useful. In principle this should not be OCL-specific, so it would be good to make the facility neutral so that it can migrate to EMF, if and when, the Event Manager migrates. Since TopCased is a semi-Eclipse project, it may be possible to acquire their code as a starting point. If so, do minor renaming, get IP approval, then enhance.
Particularly the generalization you're mentioning sounds more like pertaining to the EMF Validation project. Are you suggesting to not let OCL constraint violations flow into the regular problem view? I would have assumed that the problem view was a natural place to visualize and manage constraint violations, also because it nicely integrates EMF-based editors with non-EMF-based ones.
(In reply to comment #1) > Particularly the generalization you're mentioning sounds more like pertaining > to the EMF Validation project. Could be. But someone needs to develop this code and EMFv is short of active developers, so if we want it for our userrs we will have to do it. > Are you suggesting to not let OCL constraint violations flow into the regular > problem view? No. But note that the ProblemView should be populated by the decisions of the designated builder. The EMF editor is a little irregular in leaking an interactive 'Validate' into the Problem View without any mechanism to refresh stale problems during a project rebuild. > I would have assumed that the problem view was a natural place to > visualize and manage constraint violations, also because it nicely integrates > EMF-based editors with non-EMF-based ones. I'm suggesting a new 'Validation View' that gives a more controllable display than the ProblemView, and a more controllable invocation then select-object-then-validate. To resolve the EMF builder issue, perhaps the ValidationView has a preferred set of validations that a builder propagates to the Problem View, and alternate interactive selections that are just for experimentation.
Validation View is available for Luna. Maybe promote to EMFv for Mars.
CLOSED after more than a year in the RESOLVED state.
