-
Notifications
You must be signed in to change notification settings - Fork 34
Add Jakarta EE 8 support #53
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
Conversation
fixes #52 |
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.
Looks good, and will fix issues for many people, including me. Two questions for your
- Should we update the readme to outline the existence of this classifier?
- I'm not familiar with how this library is deployed, but will they need to do something special to deploy it ?
task copyJavaSources(type: Copy) { | ||
into generatedSrc | ||
from 'src/main/java' | ||
filter { line -> line.replaceAll("javax\\.", "jakarta\\.") } |
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.
That's a bit a funny hack to make it work. I don't mind much personally as this is rather temporary, but are we sure there are no changes between javax
and jakarta
outside the package name ?
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 am sure for Java EE 8/Jakarta EE 9 developers there is no difference from the API level between Jakarta EE 8 and Jakarta EE 9, the biggest change is the namespace migrating to new jakarta.
@@ -60,6 +71,11 @@ task javadocJar(type: Jar, dependsOn: javadoc) { | |||
from javadoc.destinationDir | |||
} | |||
|
|||
jar { | |||
// add jakarta classier for Jakarta EE 9 | |||
archiveClassifier = isJakarta ? "jakarta" : "" |
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.
is emtpy string the default value, or should it be null?
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 am not sure the default value of the classifier, I think empty string works.
@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 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). |
Is there any update on this PR? So we can unblock: Netflix/dgs-framework#659 |
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. |
@pelletier197 @sbilello Tried to create two branches(jakartaee8, jakartaee9) on my fork(not created PRs yet), the
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. |
If we can make a change that would make it clear and keep |
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 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 #53 (comment) |
I ended up making a PR and branch and released a new version So we should be right to go. Please test that release (its in Maven now) and tell me if there are any problems |
see #53 (comment) and #53 (comment)