+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 <david.tay...@extensiatech.com>:
> 
> 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 <aadamc...@gmail.com>
>> 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: dev-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: dev-h...@tapestry.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org

Reply via email to