Re: Long-Awaited FreeMarker 3 Preview Available
Hi Jonathan, What about existing projects using the Apache version ? I mean the move from 2.3 version to 2.4. Like: 1. Would it be an easy move? 2. What does it brings? 3. What are the pros and cons of each version? 4. etc. I guess that's not easy questions to answer to (4 being somehow a joke ;), but they are fundamental. TIA Jacques Le 10/11/2023 à 02:50, Jonathan Revusky a écrit : On Thu, Nov 9, 2023 at 9:00 PM Benjamin Marwell wrote: I never knew there was an "original" freemarker project. So you actually thought that FreeMarker was developed at Apache? Well, no. FreeMarker is a very very old project at this point. FreeMarker 1 was originally written by a guy named Benjamin Geer, in the late 90's. Though Ben Geer was, strictly speaking, the original author, I don't think he was really involved in the project for very long. He wasn't involved when I showed up in the community in late 2001 anyway. At that point, I basically took over, and within a few months, the thing was a complete rewrite. And that was when FreeMarker 2.0 came into being. From 2002 to 2004/2005 we went through 4 release cycles, 2.0, 2.1, 2.2, and 2.3. Each release cycle added quite a bit more functionality. It is kinda sad that there is just about no meaningful difference between 2023 "Apache FreeMarker" and FreeMarker 2.3 from 2005 (or even late 2004). But the thing to understand is that this Apache FreeMarker code, the continuation of the FreeMarker 2.3 codebase, is really something very ancient. Most of the work on this was done in the period from 2002 to 2005 or so, about a decade before there was any "Apache FreeMarker". Basically, the project was very old and stagnant at that point and came to Apache to die, I guess. So I've decided to resuscitate it. Or give it my best shot... Your web site is down, the documentation on the GitHub project is sparse. That is true at the moment but is all quite remediable -- especially if some people want to get involved and do some heavy lifting. (I get the feeling that's not you!) In any case, I said quite clearly that this is a preview. You can't expect something that is a preview to be as polished as something as old as FreeMarker 2.3, which has been pretty stable since 2004 or thereabouts! There is no way to tell whether it really is more advanced or not. Well, frankly, this is just nonsense. There is no legitimate controversy over whether this version of FreeMarker is more advanced or not. Of course it is. As I explained in the previous note in response to Taher Alkhateeb, it is built on top of the 2.4 codebase, while Apache FreeMarker is a continuation of the 2.3 codebase. Aside from that, just scan over the commit record:https://github.com/freemarker/freemarker3/commits/master Truth told, over the last few months, I have effected something close to a complete rewrite. But this is just ridiculous! Tell me, do you think there is some legitimate controversy over whether JDK 8 is more advanced than JDK 7? That's just silly. In any case, both FreeMarker 2.3 and this FreeMarker 3.0 preview that I just announced are largely my work. Is it possible that an earlier version of work by the same author is more advanced than the later version? Does that make any sense? Of course this version is more advanced! It can never be on Maven central, because the namespace (groupid) "freemarker" is already claimed by Apache Freemarker. Well, Ben... it is kind of disrespectful to talk such blatant nonsense to somebody. This is supposed to be some serious technical forum, isn't it? The "groupid" used on Maven Central is not something with any real transcendence at all. It certainly has no technical meaning. I mean, look, here is an example. The main OSS project I'm working on, as I said before, is CongoCC. A few months ago, our project (finally!) put out an "artifact" on Maven Central. That is here: https://central.sonatype.com/artifact/org.congocc/org.congocc.parser.generator I later realized that somebody else had previously put up a Maven artifact. That is here: https://central.sonatype.com/artifact/com.clickhouse/org.congocc Funny enough, the guy who put that up was not even in touch with us about it beforehand. But the one we put up is, I guess, under org.congocc and the one put up earlier by a third party is under com.clickhouse, which I guess is the URL he controls or his employer, or... I dunno... Actually, I just looked, and there is a patched version of FreeMarker 2.3.29 put up by Liferay, which is this one: https://central.sonatype.com/artifact/com.liferay/org.freemarker But the point is that it just doesn't matter! The whole idea that I can't put something on Maven Central because this nothingburger project controls the freemarker.org domain... Well, okay, I guess it's true that we can't use "org.freemarker" as a groupid since it's taken but... so what? So we use something else. (Duh.) When I decided on CongoCC as a new name for the parser generator project, I chec
Re: Long-Awaited FreeMarker 3 Preview Available
On Thu, Nov 9, 2023 at 9:00 PM Benjamin Marwell wrote: > I never knew there was an "original" freemarker project. > So you actually thought that FreeMarker was developed at Apache? Well, no. FreeMarker is a very very old project at this point. FreeMarker 1 was originally written by a guy named Benjamin Geer, in the late 90's. Though Ben Geer was, strictly speaking, the original author, I don't think he was really involved in the project for very long. He wasn't involved when I showed up in the community in late 2001 anyway. At that point, I basically took over, and within a few months, the thing was a complete rewrite. And that was when FreeMarker 2.0 came into being. From 2002 to 2004/2005 we went through 4 release cycles, 2.0, 2.1, 2.2, and 2.3. Each release cycle added quite a bit more functionality. It is kinda sad that there is just about no meaningful difference between 2023 "Apache FreeMarker" and FreeMarker 2.3 from 2005 (or even late 2004). But the thing to understand is that this Apache FreeMarker code, the continuation of the FreeMarker 2.3 codebase, is really something very ancient. Most of the work on this was done in the period from 2002 to 2005 or so, about a decade before there was any "Apache FreeMarker". Basically, the project was very old and stagnant at that point and came to Apache to die, I guess. So I've decided to resuscitate it. Or give it my best shot... > Your web site is down, the documentation on the GitHub project is sparse. > That is true at the moment but is all quite remediable -- especially if some people want to get involved and do some heavy lifting. (I get the feeling that's not you!) In any case, I said quite clearly that this is a preview. You can't expect something that is a preview to be as polished as something as old as FreeMarker 2.3, which has been pretty stable since 2004 or thereabouts! > There is no way to tell whether it really is more advanced or not. > Well, frankly, this is just nonsense. There is no legitimate controversy over whether this version of FreeMarker is more advanced or not. Of course it is. As I explained in the previous note in response to Taher Alkhateeb, it is built on top of the 2.4 codebase, while Apache FreeMarker is a continuation of the 2.3 codebase. Aside from that, just scan over the commit record: https://github.com/freemarker/freemarker3/commits/master Truth told, over the last few months, I have effected something close to a complete rewrite. But this is just ridiculous! Tell me, do you think there is some legitimate controversy over whether JDK 8 is more advanced than JDK 7? That's just silly. In any case, both FreeMarker 2.3 and this FreeMarker 3.0 preview that I just announced are largely my work. Is it possible that an earlier version of work by the same author is more advanced than the later version? Does that make any sense? Of course this version is more advanced! It can never be on Maven central, because the namespace (groupid) > "freemarker" is already claimed by Apache Freemarker. > Well, Ben... it is kind of disrespectful to talk such blatant nonsense to somebody. This is supposed to be some serious technical forum, isn't it? The "groupid" used on Maven Central is not something with any real transcendence at all. It certainly has no technical meaning. I mean, look, here is an example. The main OSS project I'm working on, as I said before, is CongoCC. A few months ago, our project (finally!) put out an "artifact" on Maven Central. That is here: https://central.sonatype.com/artifact/org.congocc/org.congocc.parser.generator I later realized that somebody else had previously put up a Maven artifact. That is here: https://central.sonatype.com/artifact/com.clickhouse/org.congocc Funny enough, the guy who put that up was not even in touch with us about it beforehand. But the one we put up is, I guess, under org.congocc and the one put up earlier by a third party is under com.clickhouse, which I guess is the URL he controls or his employer, or... I dunno... Actually, I just looked, and there is a patched version of FreeMarker 2.3.29 put up by Liferay, which is this one: https://central.sonatype.com/artifact/com.liferay/org.freemarker But the point is that it just doesn't matter! The whole idea that I can't put something on Maven Central because this nothingburger project controls the freemarker.org domain... Well, okay, I guess it's true that we can't use "org.freemarker" as a groupid since it's taken but... so what? So we use something else. (Duh.) When I decided on CongoCC as a new name for the parser generator project, I checked whether congocc.org was available and registered it. But I had anticipated having github.com/congocc as our "organization" location, but somehow that was taken, so we use github.com/congo-cc with a hyphen. Whatever. It would be a bit nicer if we had congocc without the hyphen, but it's hardly a sine qua non either. Well, anyway, look, we're not acquainted, but I find this quite off
Re: Long-Awaited FreeMarker 3 Preview Available
On Thu, Nov 9, 2023 at 6:40 PM Taher Alkhateeb
wrote:
Hi Taher,
> I'm a little confused. Why aren't we joining efforts on the apache version?
Well, in an ideal world, that is what would happen, yes. But this is
hardly an ideal situation.
> Why make it "a pity if a wider group of
> people never get the benefit of this work"? Am I missing something too
> obvious or too old or something? Is this code base completely incompatible?
> Is this a technical issue?
>
There is a technical issue, a very big one, that I shall explain below.
However, that said, the problem here is not exclusively technical
Well, I reckon that hardly anybody here really understands that "Apache
FreeMarker" is a continuation of the FreeMarker 2.3.x codebase that really,
by all rights, reached the end of the line at some point in 2005, at the
latest.
Any subsequent work in the SVN trunk ("trunk" being what is called in Git
"master" or nowadays "main") was, in principle, the main line of
development for the 2.4 release cycle. (Or possibly it was going to
eventually be labeled 3.0.) All the work that I myself did in 2006, 2007,
and 2008 was in the SVN trunk.
For reasons that I can only speculate about, when Daniel Dekany took the
FreeMarker code to Apache, he took the 2.3.x maintenance branch, not the
trunk of the code, i.e. the main line of development. As for why he did
this, you'd have to ask Daniel.
As I explained in the previous message, I picked up my older parser
generator work (a fork and eventually a total rewrite of JavaCC) again at
the end of 2019 and that work had always used the newer version of
FreeMarker (that Daniel abandoned for whatever reason). So all improvements
to FreeMarker that I have made over the last few months were built on top
of the 2.4.x codebase. For example, here specifically is an example from
the wishlist for the vaporware FreeMarker 3 here
https://cwiki.apache.org/confluence/display/FREEMARKER/FreeMarker+3
"Replace #assign/#global/#local with #var/#set. Allow block-scope
variables. [Status: Not done]"
Okay, it is still unimplemented in Apache FreeMarker. Now, I believe I
mentioned this feature in the announcement. In any case, it is described
here: https://github.com/freemarker/freemarker3/wiki/Strict-Vars
But here is the real point. This is NOT something that I added recently. I
implemented this back in 2008(!) (Or possibly earlier!) Interestingly,
there was actually one preview release of 2.4, labeled "2.4 preview 1" that
was released on 16 July 2008. And that definitely had #var/#set in it.
Funny, that release is only mentioned on the Russian language wikipedia
page. See the sidebar here: https://ru.wikipedia.org/wiki/FreeMarker Okay,
probably most of you can't read Russian, but the sidebar mentions the
latest development release as being 2.4 preview 1, and the date there is 16
July 2008.
I mean, all of this is really ancient history. The version of FreeMarker
that is used internally in CongoCC has had #set/#var from the very
beginning. (That project actually existed back in 2008 but was called
FreeCC.) In any case, if you look at the main FM template for generating
grammar productions in CongoCC here
https://github.com/congo-cc/congo-parser-generator/blob/main/src/templates/java/ParserProductions.java.ftl
you can see that all the variable assignments use the "new" (I put that in
scare quotes) #set/#var and there is no #assign or #local anywhere (in that
template or any of the others) and that has been the case from project's
beginnings back in 2008.
But hopefully, you can understand the implications of what I'm telling you.
Apache FreeMarker, now in 2023 (soon 2024) is still missing features that
were in the FreeMarker codebase in 2008! 15 years ago!
And it's not just #set/#var. The more advanced version of FreeMarker
exposes an API for accessing the AST (abstract syntax tree) of a parsed
template and that facilitates all kinds of things that would be very hard
(maybe impossible) to do against the 2.3.x codebase.
Well, anyway, the FreeMarker 3 that I recently announced is based on
continued work on what was really the main line of development, the SVN
trunk. There was quite a bit of radical change in the 2006-2008 time period
and the 2.4 (now 3.0) codebase is simply not compatible with the older 2.3
branch, which is what Apache FreeMarker really is.
Anyway, what I describe above is the technical side of the conversation.
The non-technical side of things is that it's just not very appealing to
try to collaborate with this "community". I put in enough work on this
thing and I would like to reactivate the project into something real
instead of the nothingburger project that it currently is. (The
nothingburger concept is something that I explained in this essay:
https://wiki.parsers.org/doku.php?id=nothingburger and if you want to
understand how I perceive this situation, you would do well to read that.).
So, if there are people lurking who are sick of all the nothingburger-ism
a
Re: Jakarta Servlet support decision
> 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: Long-Awaited FreeMarker 3 Preview Available
I never knew there was an "original" freemarker project. Your web site is down, the documentation on the GitHub project is sparse. There is no way to tell whether it really is more advanced or not. It can never be on Maven central, because the namespace (groupid) "freemarker" is already claimed by Apache Freemarker. - Ben Am Do., 9. Nov. 2023 um 18:40 Uhr schrieb Taher Alkhateeb : > > > I'm a little confused. Why aren't we joining efforts on the apache version? > Why make it "a pity if a wider group of > people never get the benefit of this work"? Am I missing something too > obvious or too old or something? Is this code base completely incompatible? > Is this a technical issue? > > Taher Alkhateeb > > On Wednesday, November 08, 2023 04:03 +03, Jonathan Revusky > wrote: > Greetings, > > I thought to let people know that there is a vastly more advanced version > of FreeMarker available here: https://github.com/freemarker/freemarker3 > > You can build it via: > > git clone https://github.com/freemarker/freemarker3.git > cd freemarker3 > ant > > Or, if you want, there is a prebuilt jarfile you can grab here: > https://parsers.org/download/freemarker.jar > > Though it is actually a rather superficial new feature, I think that one > thing that people will enjoy is the new terser syntax. Basically, if a > directive starts a line (aside from whitespace) there is no need for any > pointy (or square) brackets. So you can just write: > > #if foo == bar > blah blah > /#if > > You can look here for a more complete description: > https://github.com/freemarker/freemarker3/wiki/Terse-Syntax and here is an > example of a template from the old test suite rewritten using the terser > syntax: > https://github.com/freemarker/freemarker3/blob/master/src/freemarker/testcase/template/test-switch.html > > In this version of FreeMarker, the #assign and #local directives (though > they still work in a backward-compatible mode) were replaced with the newer > #var and #set. This is (IMHO) a significant improvement and is described > here: https://github.com/freemarker/freemarker3/wiki/Strict-Vars > > Just generally speaking though, the biggest changes are really under the > hood and would not be so visible to the casual user. This FreeMarker > codebase has been refactored so that it largely does away with all of those > TemplateXXXModel wrappers and mostly just directly uses POJOs. (Plain Old > Java Objects.) This is described here: > https://github.com/freemarker/freemarker3/wiki/Under-the-Hood > > Various longstanding annoyances, like not being able to directly use a map > with non-string keys, have been addressed. > > Oh, it suddenly occurs to me that many (perhaps most) people on this > mailing list do not know who I am. I am effectively the original author of > FreeMarker. I say "effectively" because there was a FreeMarker 1.x, which > was really little more than a weekend hack. The version that 99% of > FreeMarker users have used, which is 2.x, was a complete rewrite and is > largely my work. > > As for other questions about what is going on with this, for example, why I > have put some renewed effort into FreeMarker after all years... well, my > main open source efforts have been going into my rewrite of that old JavaCC > parser generator that FreeMarker 2.x was originally built with. The new > version of JavaCC was originally called FreeCC, then when I resuscitated it > a few years ago, I called it JavaCC 21, but it is now rebranded as CongoCC. > So, since FreeMarker is a key part of CongoCC, I found myself adding the > occasional new feature to FreeMarker (my own version, not Apache > FreeMarker). For example, the feature described here > https://github.com/freemarker/freemarker3/wiki/Macros-as-Functions was > added to support CongoCC development back in 2020, but probably a lot of > FreeMarker users would appreciate this. > > So, at some point, I did rework FreeMarker to use CongoCC instead of the > legacy JavaCC. CongoCC is a much, much more powerful parser generator than > the original JavaCC, so it makes FreeMarker development comparatively a > breeze. For example, I quite recently implemented assertions in FreeMarker > and this is where it is implemented: > https://github.com/freemarker/freemarker3/blob/master/src/parser/Directives.inc.ccc#L417-L445 > > Or here is where ternary expressions are implemented: > https://github.com/freemarker/freemarker3/blob/master/src/parser/Expressions.inc.ccc#L98-L118 > You really should compare the FreeMarker grammar expressed with CongoCC to > the one that was written with legacy JavaCC, that is here: > https://github.com/apache/freemarker/blob/2.3-gae/src/main/javacc/FTL.jj > > So I rewrote FreeMarker (it is largely a rewrite at this point) to: (a) > have a better tool for CongoCC development and (b) to provide a showcase > for CongoCC's capabilities. > > As for my plans, well, I do think it would be a pity if a wider group of > people never get the benefit of this work. Whet
Re: Long-Awaited FreeMarker 3 Preview Available
I'm a little confused. Why aren't we joining efforts on the apache version? Why make it "a pity if a wider group of people never get the benefit of this work"? Am I missing something too obvious or too old or something? Is this code base completely incompatible? Is this a technical issue? Taher Alkhateeb On Wednesday, November 08, 2023 04:03 +03, Jonathan Revusky wrote: Greetings, I thought to let people know that there is a vastly more advanced version of FreeMarker available here: https://github.com/freemarker/freemarker3 You can build it via: git clone https://github.com/freemarker/freemarker3.git cd freemarker3 ant Or, if you want, there is a prebuilt jarfile you can grab here: https://parsers.org/download/freemarker.jar Though it is actually a rather superficial new feature, I think that one thing that people will enjoy is the new terser syntax. Basically, if a directive starts a line (aside from whitespace) there is no need for any pointy (or square) brackets. So you can just write: #if foo == bar blah blah /#if You can look here for a more complete description: https://github.com/freemarker/freemarker3/wiki/Terse-Syntax and here is an example of a template from the old test suite rewritten using the terser syntax: https://github.com/freemarker/freemarker3/blob/master/src/freemarker/testcase/template/test-switch.html In this version of FreeMarker, the #assign and #local directives (though they still work in a backward-compatible mode) were replaced with the newer #var and #set. This is (IMHO) a significant improvement and is described here: https://github.com/freemarker/freemarker3/wiki/Strict-Vars Just generally speaking though, the biggest changes are really under the hood and would not be so visible to the casual user. This FreeMarker codebase has been refactored so that it largely does away with all of those TemplateXXXModel wrappers and mostly just directly uses POJOs. (Plain Old Java Objects.) This is described here: https://github.com/freemarker/freemarker3/wiki/Under-the-Hood Various longstanding annoyances, like not being able to directly use a map with non-string keys, have been addressed. Oh, it suddenly occurs to me that many (perhaps most) people on this mailing list do not know who I am. I am effectively the original author of FreeMarker. I say "effectively" because there was a FreeMarker 1.x, which was really little more than a weekend hack. The version that 99% of FreeMarker users have used, which is 2.x, was a complete rewrite and is largely my work. As for other questions about what is going on with this, for example, why I have put some renewed effort into FreeMarker after all years... well, my main open source efforts have been going into my rewrite of that old JavaCC parser generator that FreeMarker 2.x was originally built with. The new version of JavaCC was originally called FreeCC, then when I resuscitated it a few years ago, I called it JavaCC 21, but it is now rebranded as CongoCC. So, since FreeMarker is a key part of CongoCC, I found myself adding the occasional new feature to FreeMarker (my own version, not Apache FreeMarker). For example, the feature described here https://github.com/freemarker/freemarker3/wiki/Macros-as-Functions was added to support CongoCC development back in 2020, but probably a lot of FreeMarker users would appreciate this. So, at some point, I did rework FreeMarker to use CongoCC instead of the legacy JavaCC. CongoCC is a much, much more powerful parser generator than the original JavaCC, so it makes FreeMarker development comparatively a breeze. For example, I quite recently implemented assertions in FreeMarker and this is where it is implemented: https://github.com/freemarker/freemarker3/blob/master/src/parser/Directives.inc.ccc#L417-L445 Or here is where ternary expressions are implemented: https://github.com/freemarker/freemarker3/blob/master/src/parser/Expressions.inc.ccc#L98-L118 You really should compare the FreeMarker grammar expressed with CongoCC to the one that was written with legacy JavaCC, that is here: https://github.com/apache/freemarker/blob/2.3-gae/src/main/javacc/FTL.jj So I rewrote FreeMarker (it is largely a rewrite at this point) to: (a) have a better tool for CongoCC development and (b) to provide a showcase for CongoCC's capabilities. As for my plans, well, I do think it would be a pity if a wider group of people never get the benefit of this work. Whether I intend to call this version of FreeMarker "FreeMarker 3" or rename it to "Congo Templates", I still haven't decided about that. I really only put some serious effort into the FreeMarker codebase starting this summer and the work kind of took on a life of its own. In any case, anybody who is interested in getting involved, by all means. Maybe start a discussion here: https://github.com/freemarker/freemarker3/discussions Best Regards and Greetings from Spain, Jonathan Revusky
Re: Jakarta Servlet support decision
> 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
> 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. >
