Ah, sorry, it's not yet done on Git... posted that to the wrong thread. But, I have a question regarding Jakarta support. What features of Servlet/JSP support are you using? I'm asking because supporting JSP taglibs (TLD-based) might bring some complications, if that has to work on modern containers.
On Mon, Dec 25, 2023 at 9:05 PM Daniel Dekany <ddek...@apache.org> wrote: > This is done now (in Git). > > On Thu, Dec 21, 2023 at 6:38 PM Daniel Dekany <ddek...@apache.org> wrote: > >> So far it seems that using a new package, like >> freemarker.ext.jakarta.servlet and freemarker.ext.jakarta.jsp was the more >> popular compromise. As far as that part of the source code can be generated >> from the packages with similar names, I assume that we will give that >> approach a try. This we do after the Gradle PR was merged (which looks very >> close). Any comments? >> >> On Tue, Nov 7, 2023 at 11:50 PM Daniel Dekany <ddek...@apache.org> wrote: >> >>> The package of Servlet related classes has changed because of Jakarta, >>> which breaks our Servlet support (freemarker.ext.servlet), which is packged >>> into freemarker.jar. >>> >>> We have to choose which end result we want (ignore the "how" for now) as >>> the solution, from these two (as far as I can tell): >>> >>> 1. We can copy the `freemarker.ext.servlet` package into >>> `freemarker.ext.jakartaservlet` (or such), and we will only have the normal >>> artifact in Maven Central, which contains that, and also the older >>> freemarker.ext.servlet. Explanation: As you probably know, 2.x has a single >>> monolithic freemarker.jar artifact, which already contains support classes >>> of various optional dependencies. We already support multiple incompatible >>> Serlvet/JSP versions, and has separate version-specific classes for some. >>> But, classes like freemarker.ext.servlet.FreemarkerServlet managed to stay >>> common amongst Servlet API versions. For the Jakarta change not even that >>> can remain common of course. >>> >>> 2. We can have an additional artifact variant (let's say via Maven >>> classifier "jakarta"), that still uses the `freemarker.ext.servlet` >>> package, but there that links to the Jakarta Servlet classes. This artifact >>> will drop support for pre-Jakarta Servlet/JSP versions. >>> >>> Possibility 1 pro: We don't have to publish one more artifact. Also, >>> then users don't have to fiddle with dependency management to choose the >>> artifact with the "jakarta" classifier. >>> >>> Possibility 1 con: Any existing dependent Java code that used >>> `freemarker.ext.servlet` so far, and wants to migrate to a Jakarta Servlet >>> container, has to be modified to link to `freemarker.ext.jakartaservlet` >>> instead. That sounds quite bad, however, the same dependent Java code >>> likely has to be modified anyway, to link to Jakarta Servlet classes. >>> Except, there are tools, like >>> https://github.com/apache/tomcat-jakartaee-migration, that transforms >>> jar-s to depend on Jakarta Servlet API, but same tools of course won't >>> replace links to freemarker.ext.servlet with freemarker.ext.jakartaservlet, >>> so some pain is expected. Also, `web.xml`-s that refer to >>> `freemarker.ext.servlet.FreemarkerSerlvet` also have to be modified, if >>> someone uses a Jakarta container. >>> >>> Opinions? >>> >>> Note 1: We had two attempts so far on this issue, but certainly the >>> actual solution will be a 3rd one. Anyway, the "how" is now not the point >>> now, but here they are: >>> >>> - https://github.com/apache/freemarker/pull/94 >>> - https://github.com/apache/freemarker/pull/95 >>> >>> Note 2: At some later(!) point, maybe in a FreeMarker 2.4.0, we can get >>> rid of non-Jakarta servlet support. At the same point, we will also get rid >>> of the GAE/non-GAE variety. So we could end up with just a single variant >>> of the freemarker 2.x artifact, over time. >>> >>
