Re: What's the status of FREEMARKER-35?
On Tue, Feb 6, 2024 at 10:53 AM Taher Alkhateeb
wrote:
>
> When you have two code bases that share a common ancestry, then the two
> different lines of development are called forks,
Well, no. That's just not true. Do people say that JDK 7 and JDK 8 are
forks? No. The latter is not a fork, but just a continuation of development
on the same project.
I already explained the history of this. The FreeMarker 3 that I am working
on is the continuation of development on the trunk ("master" or "main" in
Git-speak) of the code from when the project was hosted on Sourceforge. A
continuation of development by the person who is, to all intents and
purposes, the original author. I daresay that nobody who understood the
situation would call this a "fork".
> it's not a bad thing and if you check github you'll notice that it's kind
> of a popular button over there.
Well, it's true that in git, the term "fork" does not have a negative
connotation, but I was pretty certain that the way you were using the term,
you did mean it negatively. That view is reinforced by the hostile tone of
your message.
In any case, if anything is a "fork", it is "Apache FreeMarker" because
Daniel chose to fork off from the main stream of development by taking an
older obsolete version of the code base, the FreeMarker 2.3 maintenance
branch and using that as the basis for "Apache FreeMarker". Once I resumed
my FreeCC work, which used the more advanced version of the code (the trunk
in the code repository), yes, there was effectively a fork, as in a
bifurcation, but the record is clear. The person who forked, i.e. caused a
bifurcation, was Daniel. My work is simply a continuation of work on the
main stream of development.
The history of all this is kind of convoluted in a way, but it's not really
that hard to understand either -- unless you very much don't want to
understand, which I suspect is your case...
> Sorry but I will refrain from nothing, especially when it's just _your_
> interpretation or mind-reading attempt.
>
Well, I do not think that I am imagining the hostility in your tone.
Anyway, I would re-iterate that you really ought to refrain from referring
to my work as a "fork" because it is not, and I already explained this. If
somebody was misspelling your last name, let's say with one 'e' instead of
two, and you corrected him, and he kept misspelling your name regardless,
would this not be some kind of passive aggression?
>
> I don't know you nor do I know Daniel beyond just interactions in here,
> but at this point and after everything I read, I don't care if your code
> quality is 10,000 times better. I just don't want to deal with you
> regardless of who you are or what your code is like.
Well, the "Apache FreeMarker" code was also largely written by me. I mean,
certainly the core parser/renderer part which is what FreeMarker mostly is.
"Apache FreeMarker" also includes the BeansWrapper written entirely by
Attila Szegedi, which was 12000 lines of rather grotesquely over-engineered
code. I ended up rewriting all of that in about 400 lines. So, as you could
imagine, it is a lot easier to work with!
But the problem with what you're saying is that if you get in there and
work on the "Apache FreeMarker" code, you're largely just working with an
older, obsolete version of the code by same author. Me!
But anyway, there's not much point in announcing loudly to the world that
you don't want to collaborate with me. Just don't collaborate with me. I
don't know what the point of this is. It's like you're trying to "virtue
signal" or something. Somehow making a show of this hostility towards me is
somehow virtuous or something... (SMH).
Check out new FreeMarker 3 features:
https://github.com/freemarker/freemarker3/wiki
Jonathan Revusky
>
> On Monday, February 05, 2024 15:44 +03, Jonathan Revusky <
> revu...@gmail.com> wrote:
> (Sigh.)
>
> Well, first of all, your characterization of the overall situation is
> pretty dubious. For one thing, you refer to *my* work as a "fork", which is
> quite loaded language, since a "fork" is usually taken to be a bad thing.
> But really, this is a very tenuous concept in this context. A "fork" is
> short for a bifurcation of effort, no? That would mean that I'm doing
> something and you guys are doing something, right? Except that is hardly a
> correct characterization. The cold, hard truth is that, over the last year
> in particular, I have been working on the thing (I mean in a fundamental,
> meaningful way, making significant, even revolutionary changes, to the code
> base, it's much better structured now) and this community has done
> basically NOTHING. That, my friends, is not a "bifurcation of effort". So I
> would suggest that you refrain from referring to my work as a "fork"
> because it isn't really, and to keep using this loaded language would be
> something of a provocation frankly.
>
> Now look, the very first thing anybody needs to understand about the
> situation is this:
Re: What's the status of FREEMARKER-35?
When you have two code bases that share a common ancestry, then the two different lines of development are called forks, it's not a bad thing and if you check github you'll notice that it's kind of a popular button over there. Sorry but I will refrain from nothing, especially when it's just _your_ interpretation or mind-reading attempt. I don't know you nor do I know Daniel beyond just interactions in here, but at this point and after everything I read, I don't care if your code quality is 10,000 times better. I just don't want to deal with you regardless of who you are or what your code is like. On Monday, February 05, 2024 15:44 +03, Jonathan Revusky wrote: (Sigh.) Well, first of all, your characterization of the overall situation is pretty dubious. For one thing, you refer to *my* work as a "fork", which is quite loaded language, since a "fork" is usually taken to be a bad thing. But really, this is a very tenuous concept in this context. A "fork" is short for a bifurcation of effort, no? That would mean that I'm doing something and you guys are doing something, right? Except that is hardly a correct characterization. The cold, hard truth is that, over the last year in particular, I have been working on the thing (I mean in a fundamental, meaningful way, making significant, even revolutionary changes, to the code base, it's much better structured now) and this community has done basically NOTHING. That, my friends, is not a "bifurcation of effort". So I would suggest that you refrain from referring to my work as a "fork" because it isn't really, and to keep using this loaded language would be something of a provocation frankly. Now look, the very first thing anybody needs to understand about the situation is this: the only reason that there is such a thing as "Apache FreeMarker" is that I made a pretty massive donation of my work roughly 10 years ago. At that time, I did not anticipate ever doing anything in FreeMarker again and it seemed like the existing community was enthusiastic about going to ASF -- and, more importantly, since I had not done anything in the project for about 5 years, I did not think I really had any right to block the move to ASF, even though I myself did not like the idea at all. Besides, at that point, one could not know what the results of all this would be. Maybe the move to ASF would give FreeMarker development a shot in the arm and wonderful things were going to happen. How do you know if you don't try it? But, obviously, that is most certainly not what happened. But anyway, what you are asking me, when you ask me why I don't try to merge my ongoing work with "Apache FreeMarker" is why, after making the substantial code donation (to which "Apache FreeMarker" owes its existence) I decline to even try to donate any further work. Well, why should I? If I feel (and I do!) that the initial code donation was a mistake on my part, wouldn't it stand to reason that I am not interested in repeating the mistake? I mean, let's be honest here (or try...). If you were in my shoes, would you want to donate any more work to ASF? Already, when one is treated with an incredible lack of graciousness after donating this much work, why would you ever donate any work again? Does that make any sense? Just think about that... And again, I see no reason to make any bones about the fact that I consider the code donation I made back then to have been a terrible mistake. And, really, the results are pretty much a fiasco. There has been some work done on the thing, but I reckon that what has happened in ten years is quite a bit less than a single motivated person such as myself would do in a single month. The project was already pretty dead when it came to Apache, comatose at least, but now it's a full-blown nothingburger project. (I explain the "nothingburger" concept as best I can here: https://wiki.parsers.org/doku.php?id=nothingburger ) But, look, there is another basic point to make about all of this. In this life, if you want to work on something with other people, you have to find people who share that common intersest. For example, if you're a guitarist or drummer and you want to be part of a musical group, you need to find other people who also (like you, presumably) genuinely want to make music! The same if you want to get involved in some local theater, or whatever. And this is no different in principle. If you do want to collaborate on a software development project, you need to find the right people who also want to do that. But regardless, if you really want to do something, it's just masochistic to try to get involved with people who don't really want to do anything. Why waste one's time? So this is a juncture where a person really has to be honest with himself, no? Do you really want to get involved in FreeMarker development? Or is this just some kind of weird posturing? Because if you do want to get involved, obviously you should want to get involved with people
Re: What's the status of FREEMARKER-35?
> 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, 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 wrote:
> >
> > Hi Vinay. Nice to see you here.
> >
> >> On Mon, Feb 5, 2024 at 11:50 AM Vinay Sajip .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 stil
Re: What's the status of FREEMARKER-35?
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 wrote:
>
> Hi Vinay. Nice to see you here.
>
>> On Mon, Feb 5, 2024 at 11:50 AM Vinay Sajip
>> 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
Re: What's the status of FREEMARKER-35?
Hi Vinay. Nice to see you here.
On Mon, Feb 5, 2024 at 11:50 AM Vinay Sajip
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
Re: What's the status of FREEMARKER-35?
(Sigh.) Well, first of all, your characterization of the overall situation is pretty dubious. For one thing, you refer to *my* work as a "fork", which is quite loaded language, since a "fork" is usually taken to be a bad thing. But really, this is a very tenuous concept in this context. A "fork" is short for a bifurcation of effort, no? That would mean that I'm doing something and you guys are doing something, right? Except that is hardly a correct characterization. The cold, hard truth is that, over the last year in particular, I have been working on the thing (I mean in a fundamental, meaningful way, making significant, even revolutionary changes, to the code base, it's much better structured now) and this community has done basically NOTHING. That, my friends, is not a "bifurcation of effort". So I would suggest that you refrain from referring to my work as a "fork" because it isn't really, and to keep using this loaded language would be something of a provocation frankly. Now look, the very first thing anybody needs to understand about the situation is this: the only reason that there is such a thing as "Apache FreeMarker" is that I made a pretty massive donation of my work roughly 10 years ago. At that time, I did not anticipate ever doing anything in FreeMarker again and it seemed like the existing community was enthusiastic about going to ASF -- and, more importantly, since I had not done anything in the project for about 5 years, I did not think I really had any right to block the move to ASF, even though I myself did not like the idea at all. Besides, at that point, one could not know what the results of all this would be. Maybe the move to ASF would give FreeMarker development a shot in the arm and wonderful things were going to happen. How do you know if you don't try it? But, obviously, that is most certainly not what happened. But anyway, what you are asking me, when you ask me why I don't try to merge my ongoing work with "Apache FreeMarker" is why, after making the substantial code donation (to which "Apache FreeMarker" owes its existence) I decline to even try to donate any further work. Well, why should I? If I feel (and I do!) that the initial code donation was a mistake on my part, wouldn't it stand to reason that I am not interested in repeating the mistake? I mean, let's be honest here (or try...). If you were in my shoes, would you want to donate any more work to ASF? Already, when one is treated with an incredible lack of graciousness after donating this much work, why would you ever donate any work again? Does that make any sense? Just think about that... And again, I see no reason to make any bones about the fact that I consider the code donation I made back then to have been a terrible mistake. And, really, the results are pretty much a fiasco. There has been some work done on the thing, but I reckon that what has happened in ten years is quite a bit less than a single motivated person such as myself would do in a single month. The project was already pretty dead when it came to Apache, comatose at least, but now it's a full-blown nothingburger project. (I explain the "nothingburger" concept as best I can here: https://wiki.parsers.org/doku.php?id=nothingburger ) But, look, there is another basic point to make about all of this. In this life, if you want to work on something with other people, you have to find people who share that common intersest. For example, if you're a guitarist or drummer and you want to be part of a musical group, you need to find other people who also (like you, presumably) genuinely want to make music! The same if you want to get involved in some local theater, or whatever. And this is no different in principle. If you do want to collaborate on a software development project, you need to find the right people who also want to do that. But regardless, if you really want to do something, it's just masochistic to try to get involved with people who don't really want to do anything. Why waste one's time? So this is a juncture where a person really has to be honest with himself, no? Do you really want to get involved in FreeMarker development? Or is this just some kind of weird posturing? Because if you do want to get involved, obviously you should want to get involved with people who actually want to do something. (Isn't that just common sense finally?) In terms of reviving a "nothingburger" project, which is what "Apache FreeMarker" is, granted, it's not entirely impossible, I suppose, but the prognosis is really very poor. And this basic problem, that "Apache FreeMarker" is a classic nothingburger, that's not something that can be laid at my doorstep. Basically, you have a choice between working on an earlier version of my work without me -- or the latest version, with the cleanest, best structured codebase... WITH my collaboration, the involvement of the original author. Based on my own values, it would be a very easy decision. Jon Revusky On
Re: What's the status of FREEMARKER-35?
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. 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. 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). 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. 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. 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. Regards, Vinay Sajip On Monday, 5 February 2024 at 06:22:15 GMT, Taher Alkhateeb 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 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 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
Re: What's the status of FREEMARKER-35?
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 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 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 > wrote: > >Specifically - is there anything contributors can help with to get this > >completed? >
Re: What's the status of FREEMARKER-35?
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 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 > wrote: > >Specifically - is there anything contributors can help with to get this > >completed? >
Re: What's the status of FREEMARKER-35?
Just pushed status and TODO here (was my personal notes): https://github.com/apache/freemarker/blob/FREEMARKER-35/FREEMARKER-35-README.txt java.time support is 2.x. (Yeah, it's very belated... and the other stuff soaked up my arguably quite limited time invested in FM in the winter sprint push, again.) On Sat, Feb 3, 2024 at 9:57 AM Alon Ziv wrote: > As far as I can see, FREEMARKER-35 is not related to FM3 - it's just > adding Java8 types to FM2, extremely belatedly. > > On Sat, Feb 3, 2024, 10:21 AM Taher Alkhateeb > 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. >> >> On February 3, 2024 10:51:15 AM GMT+03:00, Alon Ziv >> wrote: >> >Specifically - is there anything contributors can help with to get this >> >completed? >> > -- Best regards, Daniel Dekany
Re: What's the status of FREEMARKER-35?
As far as I can see, FREEMARKER-35 is not related to FM3 - it's just adding Java8 types to FM2, extremely belatedly. On Sat, Feb 3, 2024, 10:21 AM Taher Alkhateeb 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. > > On February 3, 2024 10:51:15 AM GMT+03:00, Alon Ziv > wrote: > >Specifically - is there anything contributors can help with to get this > >completed? > smime.p7s Description: S/MIME Cryptographic Signature
Re: What's the status of FREEMARKER-35?
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. On February 3, 2024 10:51:15 AM GMT+03:00, Alon Ziv wrote: >Specifically - is there anything contributors can help with to get this >completed?
What's the status of FREEMARKER-35?
Specifically - is there anything contributors can help with to get this completed? smime.p7s Description: S/MIME Cryptographic Signature
