Re: Jakarta Servlet support decision

[Daniel Dekany]

I meant... this repo, not staging:


  apache-snapshot-repository
  https://repository.apache.org/content/repositories/snapshots/

  false
  true


On Wed, Jan 24, 2024 at 2:52 PM Daniel Dekany  wrote:

> 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/
>
> 
>   apache-staging-repository
>   https://repository.apache.org/content/repositories/staging/
> 
>
> On Tue, Jan 23, 2024 at 10:15 AM Daniel Dekany  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  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 
>>> 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 
 wrote:

> This is done now (in Git).
>
> On Thu, Dec 21, 2023 at 6:38 PM Daniel Dekany 
> 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 
>> 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

Re: Jakarta Servlet support decision

[Daniel Dekany]

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/


  apache-staging-repository
  https://repository.apache.org/content/repositories/staging/


On Tue, Jan 23, 2024 at 10:15 AM Daniel Dekany  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  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  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 
>>> wrote:
>>>
 This is done now (in Git).

 On Thu, Dec 21, 2023 at 6:38 PM Daniel Dekany 
 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 
> 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
>> 

Re: Jakarta Servlet support decision

[Daniel Dekany]

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  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  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  wrote:
>>
>>> This is done now (in Git).
>>>
>>> On Thu, Dec 21, 2023 at 6:38 PM Daniel Dekany 
>>> 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 
 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
>

Re: Jakarta Servlet support decision

[Daniel Dekany]

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  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  wrote:
>
>> This is done now (in Git).
>>
>> On Thu, Dec 21, 2023 at 6:38 PM Daniel Dekany  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 
>>> 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.

>>>

Re: Jakarta Servlet support decision

[Daniel Dekany]

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  wrote:

> This is done now (in Git).
>
> On Thu, Dec 21, 2023 at 6:38 PM Daniel Dekany  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  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.
>>>
>>

Re: Jakarta Servlet support decision

[Daniel Dekany]

This is done now (in Git).

On Thu, Dec 21, 2023 at 6:38 PM Daniel Dekany  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  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.
>>
>

Re: Jakarta Servlet support decision

[Daniel Dekany]

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

Re: Jakarta Servlet support decision

[Benjamin Marwell]

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

Re: Jakarta Servlet support decision

[Daniel Dekany]

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

Re: Jakarta Servlet support decision

[Benjamin Marwell]

> For 2.x that's too late (or for 2.3.x at least). freemarker.jar contains a
> mix of stuff (for some 23 years now). Like classes compiled with different
> Java versions, and classes that depend on a different version of the same
> artifact.

I don't see why this would be a reason against approach 2. Yes, it's too
late to not have mixed stuff in the jar files.
But that doesn't mean we *need* to add more mixed stuff.

I'm not even sure this approach would work at all.

And this is not a technical reason.

On Wed, 8 Nov 2023, 23:26 Daniel Dekany,  wrote:

> > Please don't make freemarker "special" to use and choose the path
> > every one else already went.
>
> For 2.x that's too late (or for 2.3.x at least). freemarker.jar contains a
> mix of stuff (for some 23 years now). Like classes compiled with different
> Java versions, and classes that depend on a different version of the same
> artifact. (This is coming from the old times when users just copied jar-s
> into some lib directory manually, and then this was convenient for
> them.) The really good approach for this would be a more modular structure
> (as it is on the "3" branch), like you have freemarker-core that has
> (basically) no dependencies, and then freemarker-jakarta-servlet.jar, and
> then you don't even need classifiers for this. But anyway, that's not for
> 2.3.x for sure.
>

RE: Jakarta Servlet support decision

[lenny]

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.

RE: Jakarta Servlet support decision

[lenny]

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

Re: Jakarta Servlet support decision

[Daniel Dekany]

> Please don't make freemarker "special" to use and choose the path
> every one else already went.

For 2.x that's too late (or for 2.3.x at least). freemarker.jar contains a
mix of stuff (for some 23 years now). Like classes compiled with different
Java versions, and classes that depend on a different version of the same
artifact. (This is coming from the old times when users just copied jar-s
into some lib directory manually, and then this was convenient for
them.) The really good approach for this would be a more modular structure
(as it is on the "3" branch), like you have freemarker-core that has
(basically) no dependencies, and then freemarker-jakarta-servlet.jar, and
then you don't even need classifiers for this. But anyway, that's not for
2.3.x for sure.

Re: Jakarta Servlet support decision

[Benjamin Marwell]

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

Re: Jakarta Servlet support decision

[Christoph Rüger]

Vote for Option 1 (package into freemarker.ext.jakartaservlet...),
I think people dealing with jakarta-namespace migrations are expecting code
changes anyway.

Am Di., 7. Nov. 2023 um 23:50 Uhr schrieb Daniel Dekany :

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

-- 
Synesty GmbH
Berggasse 1
07745 Jena
Tel.: +49 3641 5596493Internet: 
https://synesty.com 
Informationen zum Datenschutz: 
https://synesty.com/datenschutz 

Geschäftsführer: Christoph Rüger
Unternehmenssitz: Jena
Handelsregister B 
beim Amtsgericht: Jena
Handelsregister-Nummer: HRB 508766
Ust-IdNr.: 
DE287564982

Re: Jakarta Servlet support decision

[Woonsan Ko]

On Wed, Nov 8, 2023 at 7:50 AM 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?

It seems better with option 1 (adding freemarker.ext.jakartaservlet to
the freemarker.jar artifact), at least in v2.3, to me as we already
have something similar to that approach.
Also, it sounds like a smoother upgrade experience to most users.

Regards,

Woonsan

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