Note that this is included in 2.3.33-SNAPHSOT that I published to the Apache Maven snapshot repo:
https://repository.apache.org/content/groups/snapshots/org/freemarker/freemarker/2.3.33-SNAPSHOT/ <repository> <id>apache-staging-repository</id> <url>https://repository.apache.org/content/repositories/staging/</url> </repository> On Tue, Jan 23, 2024 at 10:15 AM Daniel Dekany <ddek...@apache.org> wrote: > Has merged this... Please test. > > Now the freemarker jar artifact contains freemarker.ext.jakarta.servlet, > and freemarker.ext.jakarta.jsp, in addition to the old javax Serlvet/JSP > support classes. People who need to switch to Jakarta have to > search-and-replace their code, and use the new packages. > > On Sat, Dec 30, 2023 at 8:18 PM Daniel Dekany <ddek...@apache.org> wrote: > >> 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. >>>>>> >>>>>
