Hi Thiago, I haven't looked it up in detail, but if it's just the package names, 1:1 matchable classes, and the Servlet API dependency, and adapting Tapestry code with default methods, your idea might be the best/easiest one.
Automating the process of a parallel Jakarta-based Jar would minimize the required effort by not needing another major version for it, no backporting, double the releases, etc. And when Tapestry switches to Jakarta with a major version somewhere in the future, the tool could be used to convert the current code and remove the automation for the jakarta-ee Jars. I like it. Cheers Ben
