Hi Hardy,
To me your proposal looks like the way to go if we want to have this
feature in. With giving 1.0 interpolation precedence over EL evaluation,
also backwards compat. issue should be solved.
* Is the benefit offered by this solution big enough to introduce a
dependency to another API/JSR?
This is the major question, and I haven't quite made up my mind.
We don't really use types from the EL API in BV, so AFAICS the dependency
would not be there in terms of a Maven dependency from the BV API to the EL
API, right? That is, BV providers could handle it optionally and require it
only if EL expressions are actually used, or?
In any case we're adding quite a lot just for the use case of the
"inclusive" flag.
On a related note, WDYT about
https://hibernate.onjira.com/browse/BVAL-339?
I think if we add support for EL evaluation, it would make very much sense
to allow for setting additional message parameters. At least we should add
ConstraintValidatorContext#unwrap() to allow for BV providers adding
proprietary means for doing so.
--Gunnar