>From a Maven PoV, only solution 2 is the clean approach. I would not want to have both jakarta and javax imports in the same jar, even though I am only using one of them. Then, classifiers are really common. Take Apache Johnzon (JSON (de-)serializer and mapper) for example, as well as plenty of others (Apache Shiro). This is so common, it was a no-brainer for us.
This is how it looks like: [1] https://repo1.maven.org/maven2/org/apache/johnzon/johnzon-core/1.2.21/ [2] https://repo1.maven.org/maven2/org/apache/shiro/shiro-core/1.13.0/ To be honest, this is the first time I hear that a library in the Apache namespace even suggests putting both implementations into the same jar. It is much more work to maintain, as the jakarta-artifact can just be generated from the existing one. About: > Possibility 1 pro: We don't have to publish one more artifact You are not. It is just another classifier .jar file within the very same namespace (gid:aid:v). This is technically not a "pro" and it is not more work. Within a maven or gradle build, it is the same "deploy" step. > users don't have to fiddle with dependency management to choose the > artifact with the "jakarta" classifier Users don't "fiddle" with their dependency management, they just use it. And they use it THAT WAY since forever. I already showed you two artifacts doing the same thing, and there are countless more examples. I am really puzzled why anyone would describe this as "fiddling". Please don't make freemarker "special" to use and choose the path every one else already went. Another con: Approach 1 might also be problematic for dependency scanners, as not all dependencies can be loaded at the same time. Jakarta + Javax in the same jar is usually marked as "problematic" in scanners. Solution 1: -1 Solution 2: +1 - Ben Am Di., 7. Nov. 2023 um 23:50 Uhr schrieb Daniel Dekany <ddek...@apache.org>: > > 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.
