1552 variability improve handling of root constraints with grouping

[TorstenGoerg]

• Editor improvements for feature model root constraints.
• Added repositioning of feature model root constraints on constraint group assignment changes.

This solves #1552.

[kbirken]

Starting review. Functional testing looks good so far. First finding:

In the merge editor the editor for a constraint should be more compact. Currently it looks like this:

A more compact editor would be:

group1: feature1 && feature2

I.e., the group name (colored), colon, space, constraint

[kbirken]

UX finding: Placing the cursor at the end of a constraint in a group and pressing return will create a new constraint line directly below. However, this does not work for the last constraint in the group.

[TorstenGoerg]

Starting review. Functional testing looks good so far. First finding:

In the merge editor the editor for a constraint should be more compact. Currently it looks like this:

A more compact editor would be:

group1: feature1 && feature2

I.e., the group name (colored), colon, space, constraint

If it is not needed to make ot that explicit we can remove the keywords "Constraint group".

But the simplified syntax that you suggest collides with the extensions or default "c:" prefix of the expression constraints. So we would end up with group1: c: feature1 && feature2 which does not look good. What about the syntax group1 { c: feature1 && feature2 } ?

[TorstenGoerg]

UX finding: Placing the cursor at the end of a constraint in a group and pressing return will create a new constraint line directly below. However, this does not work for the last constraint in the group.

This is one of the UX findings that I already pointed out in our discussion a few days ago. It is probably not easy to fix as this behavior originates from the underlying query lists. I.e., this UX issue is not caused by the updates of this PR.

[TorstenGoerg]

But the simplified syntax that you suggest collides with the extensions or default "c:" prefix of the expression constraints. So we would end up with group1: c: feature1 && feature2 which does not look good. What about the syntax group1 { c: feature1 && feature2 } ?

Further possibilities would be [group1] c: feature1 && feature2 or just group1 c: feature1 && feature2.

[kbirken]

Further possibilities would be [group1] c: feature1 && feature2

I like this one best.

[kbirken]

This is one of the UX findings that I already pointed out in our discussion a few days ago.
Yes, I know.

It is probably not easy to fix as this behavior originates from the underlying query lists. I.e., this UX issue is not caused by the updates of this PR.
You're right. If it's not easy to fix, this should not block the PR. But we should improve it in a later step.

[kbirken]

Pls. remember to update CHANGELOG.md.

[kbirken]

Minor code finding: In intention AddConstraintGroup the expression constraint.@constraintGroup.groupRef.group.index could be extracted into an "additional method" (at the bottom of the intention).

[kbirken]

Looks good, thanks for the improvements for grouped root constraints. This will help the users by avoiding merge conflicts.

The code finding and the tests in preparation should be provided in a follow-up PR.

[arimer]

You need to run a gradlew migrate remigrate to make the build happy :)