I read the whole ramblings so you don’t have to.
In short:
Apache FreeMarker 3 is not a viable project.
Jonathan is working on FreeMarker 3 which is a continuation of the original
project before the Apache fork. It uses a new parser (CongoCC) which makes it
much easier to modify and extend the grammar. It uses POJOs instead of
“models”. Expect big improvements in all areas.
Jonathan is looking for collaborators who are dedicated to the project. He is
very much against moving FreeMarker 3 to Apache.
My personal comment:
I don’t know how Jonathan is as a project leader, but the tone of these
ramblings does not put me at ease. If you want to take ownership it should be
possible to fork Jonathan’s FreeMarker 3. But I expect any license change would
have to go through him first.
— Denis.
> On 5 Feb 2024, at 13:46, Jonathan Revusky <revu...@gmail.com> wrote:
>
> Hi Vinay. Nice to see you here.
>
>> On Mon, Feb 5, 2024 at 11:50 AM Vinay Sajip <vinay_sa...@yahoo.co.uk.invalid>
>> wrote:
>>
>> I happen to use FreeMarker, because I work on CongoCC, which uses it, but
>> I don't work on any FreeMarker codebase itself. I'm not speaking for
>> Jonathan, but my view on "why not join hands in here ...? " might be
>> answered in part by comments Dániel Dékány made - "I think the next logical
>> step in FM3 is replacing the whole parser" - not exactly a small amount of
>> work, but something that's already been done in the project Jonathan linked
>> to.
>
>
> Well, yeah. Again, if one is really interested in moving the thing
> forward... But there are some niggles in all this. The rewrite of the
> parser that I undertook last summer, all of this is best understood as a
> result of using the more advanced features of CongoCC. ("Apache FreeMarker"
> still uses legacy JavaCC, as you no doubt know.) But anyway, this gets into
> some nooks and crannies of history now. You see, when I started working on
> my own "fork" (not really a fork since it wasn't a bifurcation of effort
> either!) of JavaCC back in 2008, I switched the trunk of FreeMarker
> development to using FreeCC (which is what my version was called back then,
> now it's CongoCC).
>
> When Daniel took the project to ASF (the "incubator" yah dee dah...) he did
> not take the trunk (trunk in SVN is called "master" or now "main" in git)
> but took the older 2.3.x. maintenance branch and effectively threw away all
> the work I had been doing from 2006-2008. (So, for one thing, this Apache
> FreeMarker is based on a really, really old version of FreeMarker!)
>
> Now, the question is why did Daniel take the older version of FreeMarker to
> ASF rather than the trunk? Did he really believe that the older codebase
> was somehow better than the newer one?
>
> As best I can guess (though Daniel could clarify) the reason that Daniel
> threw away the latest version of the code is because that was built using
> FreeCC and he wanted to revert to using legacy JavaCC for the build. Later,
> I noticed, looking at the archives of this dev list that the whole question
> came up of using a different (perhaps actively maintained) parser generator
> rather than the JavaCC abandonware, and various possibilities were floated
> and I notice that Daniel never even mentioned the existence of FreeCC.
> That, despite the fact that there was at least one actual release that was
> built with FreeCC. So, my own theory on that whole thing is that Daniel
> threw away the most up-to-date version of the code for that reason, he
> wanted to get rid of the FreeCC dependency. And then, when the topic of
> parser generators came up, he somehow did not know that FreeCC had ever
> existed.
>
> But anyway, all this gets back to why it would be quite difficult to merge
> my ongoing work with Apache FreeMarker, since Apache FreeMarker is based on
> the older codebase, while the FreeMarker 3 that is used in CongoCC (and its
> predecessor JavaCC21, of course) is one based on an ongoing evolution from
> the main line of FreeMarker development, the SVN trunk.
>
> So, again, Daniel took the older obsolete codebase to ASF, the 2.3.x
> maintenance branch, and quite a bit later, when I decided to resuscitate my
> FreeCC (now CongoCC work) the FreeMarker version that I was using, that was
> under my control, was the more advanced one based on the SVN trunk. That is
> why our templates in CongoCC do not use #assign/#local but rather
> #set/#var, which IIRC I implemented at some point in 2008, or possibly even
> 2007. By the way the #set/#var is still on the wish list as a feature to be
> implemented in the "Apache FreeMarker 3" vaporware. I mean think about
> that. That feature was already implemented in 2008, 16 years ago! And it is
> on the wish list of things to have in the next major release of Apache
> FreeMarker, which now, by Daniel's admission, is never going to happen
> anyway! Can you really characterize this as anything other than a total
> train wreck?
>
> So all of the above, though it is a bit involved to understand it, can give
> anybody a sense of how FUBAR all of this was. But an interesting
> side-effect of all this is that the FreeMarker 3 codebase that I have been
> working on, the continuation of the SVN trunk, was NEVER at ASF. Well, in
> principle, I was donating the latest version of the code, or I thought I
> was. But it was never taken back then and just continued to sit there at
> Sourceforge. So, basically, towards the end of 2019, or early 2020, I
> picked it up and started doing some things with it. Not so much until last
> year, when I really went on a tear and rewrote the parser and the core of
> it.
>
> But, you know, as I relate all the above, all of this was pretty... well...
> sleazy, really, and the whole idea that I would be interested in donating
> any more code to ASF, or at least to this Apache FreeMarker project, after
> all of this... it's pretty fanciful.
>
> So, anyway, the FreeMarker 3 code that I'm working on is not a "fork". It's
> just a continuation (after a long hiatus) of the main line of development
> which stems from the SVN trunk back when the project was on Sourceforge.
>
>
>> If the interest of the community is in moving the technology forwards,
>> then that work would seem a suitable starting point, rather than an old
>> branch which seems very out of date but just happens to be in the same
>> repository.
>
>
> Well, sure, but the most advanced version of the code was just mothballed
> for no obvious reason back when, so... Actually, I think the reason mainly
> was to NOT use FreeCC. Daniel very much did not want any further
> involvement on my part (and I think still doesn't) so that would surely be
> the reason for all that. But if there is some other reason, Daniel is
> around and can explain it.
>
>
>> You'll see that for whatever reason, it's hard to innovate in the Apache
>> project because the challenges are not only technical (getting some work
>> done) but also social (getting others to accept to work with it, or with
>> you).
>
>
> Well, yeah. Even aside from the aforementioned skullduggery with so much of
> my work (everything I did from 2006-2008) being thrown away, just the whole
> idea of trying to operate in this scene... it just looks so unappealing.
> Well, the appealing aspect is that your work automatically gets a lot more
> usage and visibility, but for me, that's just not a positive tradeoff.
> There are aspects of the "culture" here that I would be very disinclined to
> deal with...
>
>
>
>> What are the recent innovations in Apache FreeMarker, apart from working a
>> bit on the margins like servlet API-related stuff (hardly core to a
>> template engine)? I'm only a recent subscriber to this list so I've only
>> seen discussion of that kind of thing, but happy to be informed about other
>> more substantial innovations. Now it's a very mature project that perhaps
>> doesn't need much in the way of innovation, but for me the new syntax
>> changes in Jonathan's project (the ability to use e.g. #if ... /#if
>> instead of [#if...] [/#if] in many contexts) is a readability win, even if
>> it seems a small change.
>
>
> Well, actually, there are much more profound changes now in FreeMarker 3
> that are not so readily apparent. Pretty much all that object wrapper stuff
> is gone. Objects are exposed to the template layer as POJOs. So, in
> FreeMarker 2.x, anything exposed to the template layer was some sort of
> TemplateModel instance. So, if you exposed a string, it was either a
> SimpleScalar or a StringModel, depending on whether you were using the full
> beans wrapping or not. Now, any string you expose is just a
> java.lang.String. Same with numbers as well as maps and lists. This version
> of FreeMarker just uses POJOs pretty much, so it's much less unwieldy to
> deal with -- for any application programmer who has to interface with
> FreeMarker.
>
> Of course, also, the rewritten parser using CongoCC is such that it is
> vastly easier to implement new language features than it ever was before.
>
>
>
>> Not sure how much work would be required to retrofit that in Apache
>> FreeMarker, but I doubt anyone will step up to do that kind of thing.
>
>
> It seems quite unlikely. :-) In any case, any new language feature is much
> harder to implement in Apache FreeMarker, because it still uses the old
> legacy JavaCC.
>
>
>> So if one's primary interest is in the technology and advancing the state
>> of the art, one tries to work with whatever is the best of breed in an
>> area. If one's interest is more in being part of a community, then one
>> works with the community, no matter the technical and social limitations
>> that this entails. In that case, the technology / technical solutions seem
>> secondary.
>>
>
> Well, the desire to be part of a community that coalesces around some very
> obsolete, inferior version of something... also, probably with the
> unwritten rule that you're never supposed to mention that the more advanced
> version of the tool exists... Really, c'mon, WTF kind of "community" is
> that to want to get involved in?
>
> But, okay, it's true that different people have a different world view,
> so....
>
> JR
>
>
>>
>> Regards,
>> Vinay Sajip
>>
>> On Monday, 5 February 2024 at 06:22:15 GMT, Taher Alkhateeb
>> <ta...@pythys.com.invalid> wrote:
>>
>>
>> Hello Jonathan,
>>
>> Why yes if you recall I actually replied to you in that thread, and I was
>> asking you why not join hands in here instead of maintaining a fork and
>> confusing everyone as to what's going on not to mention fragmenting an
>> already small community?
>>
>> Regards,
>>
>> Taher Alkhateeb
>>
>> On Sunday, February 04, 2024 23:27 +03, Jonathan Revusky <
>> revu...@gmail.com> wrote:
>> Hi Taher (and everyone else).
>>
>> A couple of months ago, I announced the availability of a more advanced
>> FreeMarker 3 version here: https://github.com/freemarker/freemarker3
>>
>> Really, the bottom line is that if you do want to get involved in hacking
>> the FreeMarker code, this is the one you should get involved in. This is a
>> continuation of work by the original author (ME) and if you get in there
>> and have whatever questions about how the code works, you have the
>> collaboration of the original author (ME).
>>
>> If you work on Apache FreeMarker 2.x or 3.x you're working on a much more
>> primitive, older version of the code. For one thing, the FreeMarker 3 that
>> I point to is rewritten to use a much more powerful parser generator, which
>> is CongoCC. And this really has allowed quite a streamlining of the code.
>> Just look at what the CongoCC grammar looks like:
>> https://github.com/freemarker/freemarker3/tree/master/src/parser And
>> compare that with what the legacy JavaCC grammar looks like for Apache
>> FreeMarker:
>>
>> https://github.com/apache/freemarker/blob/2.3-gae/freemarker-core/src/main/javacc/freemarker/core/FTL.jj
>>
>> Just eyeball the two and think about which one you would rather work with!
>> I can be quite objective because I am basically the author of both
>> versions!
>>
>> On Sat, Feb 3, 2024 at 9:20 AM Taher Alkhateeb <ta...@pythys.com.invalid>
>> wrote:
>>
>>> Hello, we were just having a discussion about this:
>>>
>>> https://lists.apache.org/thread/2p3521br9jnp9ww1f5vf80l90fntmfdf
>>>
>>> Essentially the way I understood it, it's better to focus on 2 and get
>>> things done as 3's future is not very clear and requires a lot of work
>> from
>>> developers intimate with the code base.
>>>
>>
>> Look, the real truth of the matter is that working with either Apache
>> FreeMarker 2 codebase or the 3, it's just an exercise in necrophilia.
>> Nothing meaningful has been done for ages and, at this point, there is just
>> about no prospect of anything happening. By all means, you could get in
>> there and try to clean it all up and so on, but frankly, your prospects of
>> ever catching up to the state of the FreeMarker 3 that I have pointed to...
>> it's quite bleak really.
>>
>> I mean, really, c'mon, even just reading between the lines in Daniel's
>> response to this question about FreeMarker development, you can get the
>> feeling that it's really just a waste of time. The thing is dead and Daniel
>> is not hardly even trying to hide this.
>>
>> But anyway, 'nuff said. I just would tell you to do your due diligence and
>> figure out which way is up! I would be delighted to have collaborators, and
>> you would be collaborating with the person who is, to all intents and
>> purposes, the original author of the tool.
>>
>> It really ought to be a very easy decision.
>>
>> Best Regards,
>>
>> Jonathan Revusky
>>
>>
>>>
>>> On February 3, 2024 10:51:15 AM GMT+03:00, Alon Ziv
>>> <nola...@google.com.INVALID> wrote:
>>>> Specifically - is there anything contributors can help with to get this
>>>> completed?
>>>
>>
