Hi, +1 Markus
I understand your point Romain but IMO BVal is just stable and the spec doesnt move currently. We are fine here. So there is no change required on our side, i would also maintain it in future if there are spec changes. Best regards, Thomas Am Mi., 26. Juni 2024 um 21:23 Uhr schrieb Romain Manni-Bucau < rmannibu...@gmail.com>: > Hi, > > No strong preference for me but no doing anything if it is sufficient looks > very tempting until somebody wants to reimplement all the core with java 17 > (so I'd be for a lazy move). > > Side note: I don't want to look harsh at all but from my window the real > topic is if we keep BVal as a TLP or we discuss if we donate it to another > project (think mainly tomee is consuming it today?) or even move it to > attic if there is no more any strong will/community around the project. > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > Le mer. 26 juin 2024 à 21:07, Markus Jung <ju...@apache.org> a écrit : > > > Hey all, > > > > I took a look at making BVal Jakarta Validation 3.1 compatible a couple > of > > days ago. The changes made in Jakarta Validation 3.1 compared to Jakarta > > Bean Validation 3.0 are negligible: > > - Record support has been clarified (BVal is working properly already) > > - Implementations only need to support Java 17+ (no hard requirement) > > - Spec renamed (doesn’t matter at all in code) > > > > I opened a pull request [1] with the changes needed to make BVal Jakarta > > Validation 3.1 compliant - absolutely no code changes were needed. BVal > > 3.0.1-SNAPSHOT is already Jakarta Validation 3.1 compliant if one was to > > run the 3.1 TCK against it. In my PR I mentioned that we _really_ should > > discuss if BVal itself should move to 3.1.x. > > > > IMO the pros are: > > - Easier to understand for users; BVal versioning = Jakarta Validation > > versioning is intuitive and AFAIK has been the case before > > - We are allowed to raise the minimum java version to 17 > > > > The huge con is we need to possibly maintain/release two different > > versions of BVal that are (except for a couple hundred lines of pom.xml) > > the same. > > > > An alternative would be to just claim compatibility on both Jakarta > > Validation 3.1 and Jakarta Bean Validation 3.0 at the same time for > 3.0.1+. > > But also means we are stuck at Java 11 for a while. WDYT? > > > > > > Thanks > > > > Markus > > > > > > [1] https://github.com/apache/bval/pull/119 >
