Re: javax.servlet -> jakarta.servlet
Volker Lamp <[email protected]> Mon, 25 Jul 2022 22:11:42 +0200
| Newsgroups | gmane.comp.jakarta.tapestry.devel |
|---|---|
| Message-ID | <[email protected]> |
+1 for a clean cut / move to jakarta with Tapestry release 5.9. I guess this implies upgrading from Java Servlet 3.0 to Jakarta Servlet 5.0. Would this again imply Tomcat 10.+ is required to run Tapestry? > Am 23.07.2022 um 15:36 schrieb David Taylor <[email protected]>: > > Hi everyone, > > We have a similar requirement since we are looking to make the jump to Spring Boot 3.0 and Hibernate 6.1 which require Jakarta EE 9 and Java 17. Thanks to everyone's hard work, we have a very solid release that made it easy to move to Java 17. The transition to Jakarta EE is looking to be much more daunting since it is an all or nothing upgrade. > > I personally agree with Ben's preference for making a clean break. I imagine maintaining separate releases would not be trivial and would add significant overhead to the testing and release process. The Java ecosystem is clearly arriving a major inflection point. I believe we should embrace the trend since doing otherwise may begin to feel like death by a thousand cuts due to the never ending stream of updates to stay ahead of security vulnerabilities. > > Best regards, > David > >> On 7/23/2022 8:03 AM, Ben Weidig wrote: >> Hi Andrus! >> >> Personally, I would prefer a hard cut with a minor version bump to 5.9 for >> a Jakarta-only Tapestry with 5.8 remaining JavaEE, instead of creating >> additional projects like tapestry-http-jakarta. >> >> Essential features, bug fixes, etc., should be backported to 5.8 for a >> migration phase to allow users to get newer features even if they can't >> migrate to Jakarta at the moment. >> And if they finally can migrate, they hopefully don't need to change much, >> at least regarding Tapestry itself. >> >> At some point in the future, though, we should only backport >> security-related changes from 5.9 to 5.8, especially if the branches start >> to differ too much and backporting becomes a chore thanks to too many merge >> conflicts, etc. >> >> Please consider that I don't have much experience handling breaking changes >> / library deprecations in an open-source setting, so I'm looking forward to >> any suggestion on how to handle it :-) >> >> Cheers >> Ben >> >> On Sat, Jul 23, 2022 at 11:08 AM Andrus Adamchik <[email protected]> >> wrote: >> >>> Hi folks, >>> >>> As you probably know, JavaEE has been EOL'd for some time, and everyone is >>> slowly moving to JakartaEE. And this requires an entirely new build of >>> every application and framework because of the package change from >>> "javax.*" to "jakarta.*". >>> >>> So are there any plans to create a JakartaEE-compatible version of >>> Tapestry (either next to or instead of JavaEE) ? >>> >>> FWIW, in the Bootique project we decided to keep both JavaEE and Jakarta >>> options for at least the next major release. E.g. >>> https://github.com/bootique/bootique-jetty < >>> https://github.com/bootique/bootique-jetty> . But with every passing >>> month, I am less inclined to keep supporting JavaEE :) >>> >>> Andrus > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >