I meant... this repo, not staging:

        <repository>
          <id>apache-snapshot-repository</id>
          <url>https://repository.apache.org/content/repositories/snapshots/
</url>
          <releases><enabled>false</enabled></releases>
          <snapshots><enabled>true</enabled></snapshots>
        </repository>

On Wed, Jan 24, 2024 at 2:52 PM Daniel Dekany <ddek...@apache.org> 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/
>
> <repository>
>   <id>apache-staging-repository</id>
>   <url>https://repository.apache.org/content/repositories/staging/</url>
> </repository>
>
> On Tue, Jan 23, 2024 at 10:15 AM Daniel Dekany <ddek...@apache.org> 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 <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.
>>>>>>>
>>>>>>

Reply via email to