chore(deps): update Hibernate validator

[ghost]

• 7.0.5 is the last JDK8-compatible version

Signed-off-by: Jan Thiart jan.thiart@tngtech.com

[codecov-commenter]

Codecov Report

Merging #146 (d122efb) into master (bfbcb31) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #146   +/-   ##
=========================================
  Coverage     96.78%   96.78%           
  Complexity      233      233           
=========================================
  Files            45       45           
  Lines           591      591           
  Branches         63       63           
=========================================
  Hits            572      572           
  Misses           10       10           
  Partials          9        9           

Impacted Files	Coverage Δ
...ch/configbuilder/exception/ValidatorException.java	100.00% <ø> (ø)
...gtech/configbuilder/util/ConfigBuilderFactory.java	100.00% <ø> (ø)
...om/tngtech/configbuilder/util/ConfigValidator.java	100.00% <ø> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[hankem]

I wouldn't call the commit chore(deps), but rather BREAKING CHANGE, as it changes the ConfigValidator to use Jakarta Bean Validation 3.0 / Jakarta EE 9, right?

Should we release config-builder version 2.0 after this update?
Should there be a version 1.7.1 released before this is merged?

[ghost]

Good question. On the one hand, this is just a dependency update, the config-builder API does not change at all, unless you want to acknowledge people using custom validation logic in their project, but that is not really something that worries me.
I thought about upgrading to Hibernate 8 directly, but that would indeed require a newer JRE version, a true breaking change.
Maybe merge the rest first, release an 1.7.x version, then update Hibernate and release 1.8. 2.0 would be a JDK11-compatible version.

[hankem]

I think that it is breaking, because I assumed that the new jakarta.validation.Validator wouldn't validate javax.validation.constraints (which users might currently use), cf. ConfigBuilderIntegrationTest.

IMO, we transitively expose the Bean Validation API.

[ghost]

Yes, the user would need to keep two different Hibernate versions, and both jakarta.validation and javax.validation around, and exclude the transitive dependency from config-builder if necessary. That is probably enough to constitute a breaking change.
Will update the version accordingly and let this PR sit for a while.