search

graphql-java / graphql-java-extended-validation

Validation library for graphql-java input
MIT License
128 stars 34 forks source link

Add Jakarta EE 8 support #53

Closed hantsy closed 2 years ago

hantsy commented 3 years ago

see https://github.com/graphql-java/graphql-java-extended-validation/pull/53#issuecomment-957122700 and https://github.com/graphql-java/graphql-java-extended-validation/pull/53#issuecomment-957146265

hantsy commented 3 years ago

fixes #52

hantsy commented 3 years ago

@pelletier197 Thanks for reviewing my PRs.

But I need more help to polish this PR to make it more mature, as the check list in the original post.

Personally I hope to build a special jakarta version for Jakarta EE 9 , and keep the default version for Jakarta EE 8, but it seems the MavenPublishPlugin can not set the artifactId dynamically.

And if possible to add a new archive(jakarta) for Jakarta EE 9 besides the default archives(src, docs, jar, and a new jar with jakarta postfix in the name).

sbilello commented 3 years ago

Is there any update on this PR? So we can unblock: https://github.com/Netflix/dgs-framework/pull/659

hantsy commented 3 years ago

Another possible solution is maintaining a branch for Jakarta EE 8,and make the main/master for Jakarta EE 9. This is maybe the most common options to maintain multi versions.

hantsy commented 3 years ago

@pelletier197 @sbilello Tried to create two branches(jakartaee8, jakartaee9) on my fork(not created PRs yet), the build.gradle looks more clear.

Looks more clear?

Hope the maintainer of this project can work together and decide the final solution. If this is acceptable, I will create two smaller PRs instead of this one to avoid the source code transforming process.

sbilello commented 3 years ago

If we can make a change that would make it clear and keep jakartaee8 working: it should allow any project to avoid dealing with runtime dependency conflicts. I guess it is a good workaround to avoid to upgrade jakartaee8 in the Spring Framework

pelletier197 commented 3 years ago

I'm personally completely okay with this and I would merge as is.

Unfortunately I'm not a maintainer of this repo, so even if we can merge it, I cannot deploy it. And the maintainers of the repo are not really reactive to PRs. I have not had any update on my recent PRs as well for a while.

I was personally able to use the library with Jakarta in spring. Adding Jakarta to your classpath should resolve this, but it is indeed a dirty workaround.

bbakerman commented 2 years ago

Another possible solution is maintaining a branch for Jakarta EE 8,and make the main/master for Jakarta EE 9. This is maybe the most common options to maintain multi versions.

I think this is a much better option that gradle config that edits files at runtime. I think a branch is a much better option

hantsy commented 2 years ago

I think this is a much better option that gradle config that edits files at runtime. I think a branch is a much better option

@bbakerman Described in this comment https://github.com/graphql-java/graphql-java-extended-validation/pull/53#issuecomment-957146265 This is ready in my side, there is a jakartaee8 branch required to be created on this project,, thus I can create new PRs for different branches.

bbakerman commented 2 years ago

I ended up making a PR and branch and released a new version

https://github.com/graphql-java/graphql-java-extended-validation/pull/54

https://github.com/graphql-java/graphql-java-extended-validation/releases/tag/17.0-hibernate-validator-6.2.0.Final

So we should be right to go. Please test that release (its in Maven now) and tell me if there are any problems