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. >>>>> >>>>
