The template engine used internally in CongoCC is now Congo Template Engine, a project which is hosted here.
That is not really such a radical change because the Congo Template Engine is, in fact, just forward development on the version of FreeMarker that is under my control here. That is actually the main branch of FreeMarker development, but was effectively abandoned in 2014 when the existing FreeMarker project was incorporated into Apache Software Foundation. (I describe all this rather sordid history here.)
Work on the FreeMarker3 branch was resuscitated (somewhat) when I revived my work on FreeCC (which was the original name of the Congo CC project) at the very end of 2019. I think in 2020 I added a feature or two and also fixed a few bugs I ran across but basically just used it as is. In mid-2023, I decided to do something of a revamp on the template engine and that resulted in some significant changes (improvements IMHO) as described here.
So, at some point nearly 2 years ago (how time flies!) I did some incremental work on it that resulted in the more streamlined syntax. I also stripped away some features that were probably of marginal interest, such as support for non-Java JVM languages, such as Jython and JRuby. I also drastically revamped the core engine to use mostly POJO's (plain old Java objects) as opposed to the older approach of wrapping objects throughout.
After I started the Congo Template Engine project I continued the stripping down of the codebase. In fact, I got rid of things that I may later put back in, but I wanted to get down to the essential functionality of the template engine. Thus, for example, I ripped out all the support for declarative processing of XML -- and, actually, the associated #visit/#recurse/#fallback directives. I may put some of that functionality back in later, but I wanted to get the library down to a minimalist functionality and then put things back on an as-needed basis. In that vein, I ripped out all the existing date/time support and intend to put the time/date functionality back in, but using exclusively the JDK 8 date/time API (which did not exist when time/date functionality was implemented in FreeMarker.)
Now, all that said, "congo templates" is quite usable in its current state. You can grab a pre-built jarfile here: https://github.com/congo-cc/congo-parser-generator/tree/main/bin
Or you can build it from source via:
git clone https://github.com/congo-cc/congo-template-engine.git
cd congo-template-engine
antThe main thing you would have to know is that the package hierarchy has changed from freemarker.* to org.congocc.templates.*.
I intend to put in some tests, of course, but I didn't want to carry forward the tests that are in FreeMarker3 because I didn't like how they were structured. At the moment, the main functional test is that you can build ctemplates.jar and drop it into the congocc project and all of the congocc tests pass. But I will add some other testing framework at some point soon.
Aside from being usable on its own, the stripped down congo template engine does actually stand as a moderately complex real-world use of CongoCC. The current ctemplates code is about 4100 lines of CongoCC and 9000 lines of Java. I may manage to strip it down some more before adding anything back in. Regardless, I am quite confident that the final result of this process will be something much more clean and modern.
Now, one decision I had to make, in terms of rebranding FreeMarker3 as "Congo templates" was what the minimal supported level of the Java language was to be. I decided (at least for now) on JDK 17, which is the LTS (long-term support) version that was released in September 2021, nearly 4 years ago. Since JDK >=17 is going to be necessary to use Congo Templates, the CongoCC tool will henceforth require JDK 17.
BUT... note that, for the moment, all of the code that the CongoCC tool generates is still runnable on JDK >=8. That said, I think it's high time to bump that up too, so my intention is that we will now freely use the Java language as specified up through JDK 17 in code generation as well. But again, there is still nothing in the templates (i.e. generated code) that requires anything greater than JDK 8 level.
But my intention now is that we can freely use Java beyond the JDK 8 level (up to JDK 17, I figure) in the templates as well, and I think the next Maven artifact that generates code that requires JDK >=8, we'll go to a 2.1.x version number. So the next Maven artifact should be 2.1pre1 or maybe 2.1RC1. (I'll tell Stefan Bischoff that.)
You are encouraged to discuss this here.