Forward: Jakarta Servlet support decision (insight to a discussion in freemarker-devs)

[Peter Rader <p....@gmx.net>]

FYI I share this mail from the freemarker-mailsystem for your entertainment, enjoy.

> Gesendet: Dienstag, 07. November 2023 um 23:50 Uhr
> Von: "Daniel Dekany" <dd...@apache.org>
> An: "FreeMarker developer list" <de...@freemarker.apache.org>
> Subject: Jakarta Servlet support decision
>
> 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/94]
> - https://github.com/apache/freemarker/pull/95[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.
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org