-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(deps): update Hibernate validator #146
base: master
Are you sure you want to change the base?
Conversation
* 7.0.5 is the last JDK8-compatible version Signed-off-by: Jan Thiart <[email protected]>
Codecov Report
@@ 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
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
import jakarta.validation.ConstraintViolation; | ||
import jakarta.validation.Validator; | ||
import jakarta.validation.ValidatorFactory; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Signed-off-by: Jan Thiart [email protected]