optaplanner-core should offer a ConstraintConfiguration class that looks like this:

@ConstraintConfiguration
final class DynamicConstraintConfiguration<Score_> {

   Map<String, Score_> map;

}

So when users use this, they can do:

TSSolution {

   MapConstraintConfiguration<HardSoftScore> cc;
}
class TSConstraintProvider {

    from().filter().penalizeConfigurable("skill");
    from().filter().penalizeConfigurable("affinity");

}
class MyCP extends TSConstraintProvider {

    from().filter().penalizeConfigurable("my1");
    from().filter().penalizeConfigurable("my2");

}

Advantages:

• Users don't have to implement a ConstraintConfiguration class. Less code. Less boilerplate.
• Allows us to maybe remove the Solution class boilerplate too one day.

Fail fasts:

• from().filter().penalizeConfigurable("not exists")
  • error, map key "not exists" does not exist in constraint weight list (list of contraint weight keys)
• map.contains("key1 for which no constraint exists")
  • A) error, constraint "key1" has no constraint in constraint list (list of constraint names).
  • B) No error, like system properties, like quarkus.
    • Geoffrey: -1 because people write typos and it would fail silently. Also, for BC, we can go to no-error later, but not to error later.

Extra features for Quarkus and Spring-Boot:

• push application.properties that start with quarkus.optaplanner.constraint-weight.foo=5soft into that map by default
  => system properties can adjust constraint weights