jakarta bean validation

[mwiede]

hi, do you have any plans to update this library to jakarta bean validation 3.0?

[alwins0n]

hello. this repo is called vavr-beanvalidation2.

the next iteration of bean validation would require its own artifact (vavr-beanvalidation3) as to not break clients on updating.
afaik is the only change a namespace one to 3, which is trivial, but a new repo with a new release setup requires the help of vavr organisation.

maybe @danieldietrich can chime in?

[danieldietrich]

Hi @mwiede, hi @alwins0n,

a few seconds ago I was about to create a new repository but then I asked myself:

wouldn't it make sense to have multiple branches in one repository, one branch per bean validation number? The "old" version would still be maintainable, the main branch could point to the latest version of bean validation that is supported. The maven central creates the artifacts based on the Maven configuration, that should be possible. We would "only" need to register new artifact-ids at the Maven Central (as far as I know, haven't done that for years now).

What do you think?
(We could just rename this repo to vavr-beanvalidation)

[alwins0n]

Thank you for your input @danieldietrich ,

I do not expect another major version of the spec/api soon (at all? - nothing changed except namepace for years!) so I am in favor of the solution that is easiest for you as the repo owner!

I find it highly unlikely that we will need to regularely maintain vavr-beanvalidationX branches/repos

[rfuerst87]

Hi all

Any updates on this issue? We are unfortunately blocked to upgrade our application from spring boot 2 to version 3. Please let me / us know if we can help.

[alwins0n]

If you need this asap and have a company private repository I suggest to build the project from your fork and upload it in your repo. I doubt that whatever we will do here will deviate from your PR if we keep a single repository and rename it.

one more thing to add - a changed repo name to vavr-beanvalidation suggests support for BV 1.0 which is not the case atm... just sayin

[alwins0n]

I have been thinking and I pondered if the following is possible:

leave the repo as is targating BV2 (javax.validation)
have a github/maven action/script/mojo/whateever which does the following: replace javax.validation with jakarta.validation and replace vavr-beanvalidation2 with vavr-beanvalidation3.

so that the development is continuing as it is while "jakarta" is nothing but a release target.

i am thinking "deploy" and "deploy jakarta" logically.

[mwiede]

This recipe could do the trick https://docs.openrewrite.org/recipes/java/migrate/jakarta/javaxvalidationmigrationtojakartavalidation Alwin ***@***.***> schrieb am Fr., 23. Juni 2023, 22:26:

…

I have been thinking and I pondered if the following is possible: leave the repo as is targating BV2 (javax.validation) have a github/maven action/script/mojo/whateever which does the following: replace javax.validation with jakarta.validation and replace vavr-beanvalidation2 with vavr-beanvalidation3. so that the development is continuing as it is while "jakarta" is nothing but a release target. i am thinking "deploy" and "deploy jakarta" logically. — Reply to this email directly, view it on GitHub <#11 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAL6NOANZG4A4SVUQDDLFTLXMX3YFANCNFSM6AAAAAAX3GHGZU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[rfuerst87]

I would advise against such an approach for the following reasons:

1. Jakarta migration is not just replacing imports, dependencies have changed as well
2. beanvalidation 2 and 3 have different JDK targets, making CI complicated
3. Maintainability suffers

In the end you will find yourself working against build tools, making things unnecessary intransparent and complex.

However if you insist on not having duplicated code we could come up with a template using one of the many template engines. Individual beanvalidation versions are then derived from that template. This will most probably lead to a multi-module approach again. Backdraw is that you probably lose code completion and syntax highlighting in the template. Also things are a bit more complex.

I'd like to raise the question whether this is worth the effort. If it was on me to decide, I'd avoid accidental complexity whenever possible and keep things simple. To me it looks a bit like we're overengineering the problem here.

[alwins0n]

well, code duplication is the least of my concerns.

...and I am back full circle:

having an independent repo vavr-beanvalidation3 and treat it as a different codebase targeting a different api.

eventually the vavr-beanvalidation2 repo will be deprecated as are the old javax namespaces.

as of now I don't see a benefit having a single repo or any share code/maven modules.

@danieldietrich wdyt?