Ok so let's keep it as it is while it passes and nobdy want to leverage new features widely maybe
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 jeu. 27 juin 2024 à 09:37, Thomas Andraschko <andraschko.tho...@gmail.com> a écrit : > 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 > > >
