> To be clear, if it will be Option 1 (new package), that will happen on > build time as well (most likely).
If you intend to go for option 1, that is a sensible decision. Am Do., 9. Nov. 2023 um 12:16 Uhr schrieb Daniel Dekany <daniel.dek...@gmail.com>: > > > Furthermore, its automated with Maven Shade plugin, which prevents code > duplication and maintenance headaches. > > To be clear, if it will be Option 1 (new package), that will happen on > build time as well (most likely). > > On Thu, Nov 9, 2023 at 7:14 AM <le...@flowlogix.com> wrote: > > > As a Jakarta EE, PrimeFaces and Apache Shiro committer and contributor, > > there is only one option, which is #2. This is the “standard” way > > countless other projects added support for Jakarta EE 9+ > > namespace conversion, and FreeMarker should be no different. > > Option 2 is clean, standard and everybody understands how to do it. > > Furthermore, its automated with Maven Shade plugin, which prevents code > > duplication and maintenance headaches. > > > > On 2023/11/07 22:50:02 Daniel Dekany 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. > > > > > -- > Best regards, > Daniel Dekany
