Here's the PR (from Attila Kelemen): https://github.com/apache/freemarker/pull/104
This basically copies and modifies the content of the freemarker.ext.servlet and freemarker.ext.jsp packages (the javaxServlet source set), into freemarker.ext.jakarta.servlet and freemarker.ext.jakarta.jsp (the jakartaServlet source set, which is on-the-fly generated source set). This happens during the build, so you won't see the Jakarta-related source files in normal source code (like in your IDE), but you will see it in the build outputs, like freemarker.jar, the Maven source artifact, and in the javadoc output. The Servlet/JSP related tests also have a Jakarta "copy" (including those that run on an embedded Jetty, so no mocking), and based on that the taglib support also seems to work. Testing/feedback is welcome! Prefer commenting on the PR in this case. On Thu, Dec 28, 2023 at 3:46 PM Daniel Dekany <ddek...@apache.org> wrote: > 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. >>>> >>>
