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
