On Sat, Jul 1, 2023 at 10:05 AM Volker Lamp <vl...@apache.org> wrote:
> Hi guys, Hello! > A quick update and a request for help and opinions about my progress. > > So I got working what I thought was a good approach: a Gradle convention > plugin that copies the Java sources whilst replacing the 'javax' imports with > 'jakarta'. Making use of with 'features' and 'capabilities' I got it to > compile nicely. So far so good. Awesome! Thanks! I'm looking forward to playing with it locally! > > What I'm stuck with now are missing method implementations. Tapestry's code > base ist against servlet-api 3.0.1, but the jakarta namespace doesn't appear > before jakarta.servlet-api:5.0.0. Here is an example. Tapestry's > BufferedGZipOutputStream class extends jakarta.servlet.ServletOutputStream > which has a setWriteListener(jakarta.servlet.WriteListener) method > (introduced in servlet-api 3.1, by the way). > > For this particular case, identified by a compile error, I guess I could add > an implementation of that method by calling sed or a similar tool. And that > code would be in build.gradle which is clumsy especially if the > implementation is more than a few lines of code. And then I would repeat the > same thing for all abstract methods that were added since servlet-api 3.0.1? > Probably not. So I guess, after 5.8.3, it will be time to go to 5.9.0 and require Servlet API 3.1 and do the changes needed for Tapestry to work with it. :) > Unless somebody else has a better idea, my preference for the way ahead would > be to switch to Jakarta EE 9 and some point rather than running in parallel. Since the work is already mostly done if we go through the Servlet API 3.1 upgrade route, I vote for keeping both javax.servlet and jakarta.servlet options for some time. I believe it's not feasible to expect the current Tapestry users want or are able to upgrade to Jakarta EE 9 and I really don't want them stranded without the latest Tapestry bufixes and improvements. > As this would break backward compatibility, we would have to think about how > than can be communicated in the best way, including the possibility of > calling it Tapestry 6? I would also be ok with sticking with Tapestry 5 even > though it's a breaking change. We've done it before, and even though it is > inconvenient for users it also provides benefit for users. I consider that Tapestry 5 is the project name. Tapestry 5.8, for example, according to my thinking, is major version 8 of Tapestry 5. >From a historical perspective, I'd say that Tapestry 6 would be a non-recommended idea, as Tapestry 5 retains some concepts but it's a complete, non-backward rewrite from Tapestry 4, which isn't backward compatible with 3, and so on. I think it would be bad PR. In hindsight, Tapestry 5 should have had a different name when it was first introduced. Same for Tapestry-IoC, that many people think needs Tapestry-the-web-framework (i.e. tapestry-core and tapestry-http) to work, and that's incorrect due to its misleading name. Cheers! > > Keen to hear your thoughts. > > Thanks, > > Volker > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > -- Thiago --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
