> If you want to take ownership it should be possible to fork Jonathan’s
FreeMarker 3
If, by "you", you mean the Apache Foundation: there's no plan to fork
FreeMarker 3 from Jonathan. Apache FreeMarker is a continuation of Apache
FreeMarker 2.
On Tue, 6 Feb 2024, 07:24 Denis Bredelet, <brede...@mac.com.invalid> wrote:
> 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?
> >>>
> >>
>
