Hi David,
To expand the answer a little further, no schedule still means "the next thing to release". We absolutely understand the community's need for Jakarta EE. It's just that, given our available resources, we won't/can't commit to a fixed timeline. The Java 21 release was done first to get a better starting point and not prolong the duration for the next release. After evaluating different approaches to handle the Jakarta EE migration, we believe a manual approach might be best for our project/maintainer size. An automated patch and build process sounds quite alluring, and we invested some time looking into it. But the migration is sadly not a simple plug-and-play. Fighting Gradle is already no fun, even without trying to add Jakarta shenanigans... And requiring more extensive changes of the overall build process would definitely delay the release. Also, the more time passes, the more difficult it will be to keep feature parity without manual intervention, for example, if a dependency is updated and no longer compatible with the older version. That's why we decided on a two-branch approach, with Jakarta EE becoming the new main development branch based and non-Jakarta getting all the features, security fixes, etc., backported manually for the foreseeable future. This way, we have more control and can handle problems with incompatibilities directly instead of replacing an automatic system when it can no longer do its job. Manual backporting is, of course, a chore. But we think it's doable for the foreseeable future and in the community's interest. As Thiago already said, there's also a roadmap on the horizon, so the community gets a better understanding of what we're working on and in which direction the project is going, and to gather feedback earlier and give everyone a chance to participate and contribute. tl;dr; - Jakarta EE will be released next - However, we can't commit to a timeline, given our resources, but it's ASAP - Two-branch manual approach instead of developing an automatic solution. Backporting all the things as long as it's feasible - Roadmap coming soon! Cheers Ben On Wed, Feb 14, 2024 at 1:48 PM Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > On Tue, Feb 13, 2024 at 6:57 PM David Taylor > <david.tay...@extensiatech.com> wrote: > > > First, thanks for the 5.8.4 release! The timing was perfect since > > underscore.js was one of the items flagged in a recent vulnerability > scan. > > Nice! > > > Given there is no schedule for official Tapestry Jakarta EE support, we > > decided to create and host an internal build of Tapestry. I applied the > > changes provided by Christian Köberl in pull request TAP5-2741 to the > > 5.8.4 sources and everything is looking good so far. Thank you so much > > for providing the pull request! > > We already expected Köberl's pull request to work, but it's nice to > see some additional testing being done by the community. :) Thanks you > for that and thanks Köberl for the PR! > > > I would be very interested in everyone's thoughts on how the official > > Jakarta EE support should work. Perhaps it would be feasible to create > > an automated patch and build process that can be maintained in parallel > > to the official Tapestry build? While it may not be as elegant as a > > fully integrated approach, I believe it would address the immediate need > > for Jakarta EE artifacts without significantly increasing the > > maintenance costs. Thoughts? > > Volker Lamp already tried that approach, but it reached a few dead > ends since it's not just a package name change, but some Servlet API > changes too. > > The Tapestry team should announce the project's planned roadmap, > including the Jakarta EE issue, in the upcoming weeks. Stay tuned! :) > > Cheers! > > -- > Thiago H. de Paula Figueiredo > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
