Skip to content
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

Add support for Jakarta EE 9.1 and higher #60

Merged
merged 3 commits into from
Jul 3, 2023
Merged

Add support for Jakarta EE 9.1 and higher #60

merged 3 commits into from
Jul 3, 2023

Conversation

melbeltagy
Copy link

This PR adds support for Jakarta EE Servlet API as a replacement for the previous JavaEE Servlet API (package change javax.servlet -> jakarta.servlet)
It can be used by Jakarta EE 9.1 and higher

Notes:

  • This is a breaking change, but essential for usability with newer applications, and is not backwards compatible with previous versions.
  • I think we need to pump the version of this library to version 2.0

@melbeltagy
Copy link
Author

@yegor256 May I ask your help reviewing this, please?

@yegor256
Copy link
Member

@melbeltagy I'm a bit scared here, since we totally move away from "standard" API. Is it possible to somehow maintain backward compatibility? WDYT?

@melbeltagy
Copy link
Author

Thank you @yegor256 for the quick reply. I'm not sure what you mean by "standard" API, to be honest.
As you know Jakarta EE is the new standard APIs after Oracle donating JavaEE to Eclipse. So, all javax.* packages from JavaEE have now moved to jakarta.* since Jakarta EE 9.

Regarding backwards compatibility, I am open for any suggestions on how to achieve it. The issue is that javax.servlet package is the old API from JavaEE days. jakarta.servlet is the new package replacement starting from JakartaEE 9. Having dependency on both will bring in unnecessary dependency to the users of the jcabi library.

I think what we can do is have two separate versions:

  • Version 1.x supporting Java EE,
  • Version 2.x to support Jakarta EE

WDYT?

@melbeltagy
Copy link
Author

@yegor256 Any thoughts/updates regarding this PR, please?

@melbeltagy
Copy link
Author

@yegor256 I can see that Version 2.0 is created and still doesn't have a Jakarta EE support.
The issue is that we're actually using it in our system and we have plans on upgrading to Spring Boot version 3.0 which, as you know, has migrated to Jakarta EE.

We tried using version 1.x of the library with Spring Boot 3.x, but it didn't work due to jcabi-manifests bringing in javax.servlet packages.

Your input/support with this topic is highly appreciated.

@yegor256
Copy link
Member

@melbeltagy how about instead of modifying the existing ServletMfs class, we add a new one called JakartaServletMfs, which will work with new Jakarta API? Also, we make all servlet* dependencies in pom.xml optional. This will allow users to use either old Servlet API or the new one.

@melbeltagy
Copy link
Author

melbeltagy commented Jun 22, 2023

@yegor256 That sounds like a good idea. Having both classes, and both dependencies.
So, to make sure I understand the idea correctly, users of javax.servlet.* package would use the ServletMfs.
Users of jakarta.servlet.* package would use the JakartaServletMfs.

But since these packages cannot be used together on the same classpath, how would we configure the build in this case, please?
This is my first time considering this approach, so any clarification on how it can be done would be much appreciated.

Edit: I guess your hint to the optional dependency is what I needed 😄 . Will play around with it then and update the you afterwards. Thank you.

@yegor256
Copy link
Member

yegor256 commented Jun 23, 2023

But since these packages cannot be used together on the same classpath

@melbeltagy why not?

I mean, in a webapp they definitely should not stay together on the classpath. But in this library they can easily co-exist on classpath during compilation, I believe.

@melbeltagy
Copy link
Author

@yegor256 Thank you so much. The PR is now updated according to your recommendations and uses optional for both javax.* and jakarta.* dependencies.

Also, the deprecated methods in manifests are now removed to limit the dependency on servlet.* package to ServletMfs class only.

Please let me know if something else is missing and requires to be updated.
Once again.. thank you :)

@yegor256
Copy link
Member

yegor256 commented Jul 3, 2023

@rultor merge

@rultor
Copy link
Contributor

rultor commented Jul 3, 2023

@rultor merge

@yegor256 OK, I'll try to merge now. You can check the progress of the merge here

@rultor rultor merged commit 2491e71 into jcabi:master Jul 3, 2023
8 checks passed
@rultor
Copy link
Contributor

rultor commented Jul 3, 2023

@rultor merge

@yegor256 Done! FYI, the full log is here (took me 3min)

@yegor256
Copy link
Member

yegor256 commented Jul 3, 2023

@rultor release, tag is 2.1.0

@rultor
Copy link
Contributor

rultor commented Jul 3, 2023

@rultor release, tag is 2.1.0

@yegor256 OK, I will release it now. Please check the progress here

@melbeltagy melbeltagy deleted the renovate/jakarta.servlet-jakarta.servlet-api-5.x branch July 3, 2023 14:33
@rultor
Copy link
Contributor

rultor commented Jul 3, 2023

@rultor release, tag is 2.1.0

@yegor256 Done! FYI, the full log is here (took me 14min)

@yegor256
Copy link
Member

yegor256 commented Jul 3, 2023

@melbeltagy it's released, thanks for your contribution!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants