You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@freemarker.apache.org by Woonsan Ko <wo...@apache.org> on 2019/12/02 20:02:48 UTC
Re: Apache FreeMarker - Sharing Is Caring ...
Please see my comments inline. Thanks!
On Tue, Nov 19, 2019 at 4:35 AM Siegfried Goeschl
<si...@gmail.com> wrote:
>
> Hi Woonsan,
>
> please see my comments below …
>
> Thanks in advance,
>
> Siegfried Goeschl
>
>
> > On 19 Nov 2019, at 00:03, Woonsan Ko <wo...@apache.org> wrote:
> >
> > Hi Siegfried,
> >
> > On Sun, Nov 17, 2019 at 1:02 PM Siegfried Goeschl
> > <si...@gmail.com> wrote:
> >>
> >> Hi folks,
> >>
> >> since I'm currently mostly busy with non-coding tasks I spent some time honing my coding skills - probably to no avail as my colleagues would say ;-)
> >>
> >> 1) I migrated my pet project "freemarker-cli" from Groovy to JDK 8 (see https://github.com/sgoeschl/freemarker-cli <https://github.com/sgoeschl/freemarker-cli>)
> >>
> >> 2) At https://github.com/sgoeschl/presentations/blob/master/javameetup/freemarker/slides/src/docs/asciidoc/index.adoc <https://github.com/sgoeschl/presentations/blob/master/javameetup/freemarker/slides/src/docs/asciidoc/index.adoc> you find a presentation I gave some while ago
> >>
> >> 3) I also wrote a Spring Boot FreeMarker sample project as part of the presentation (see https://github.com/sgoeschl/presentations/tree/master/javameetup/freemarker/demo <https://github.com/sgoeschl/presentations/tree/master/javameetup/freemarker/demo>)
> >>
> >> My plans / questions
> >>
> >> I would be awesome if I could get some feedback about "freemarker-cli" in its current JDK incarnation :-) Later on I will release 2.0.0 and push it to Maven Central.
> >
> > I like the idea in principle. We have some other "generators" - code
> > generators for example, but this simple transformation/generation in
> > CLI seems very useful too. Just as an example, I have seen my
> > colleagues writing python scripts to convert one format to another.
> > Your tool seems easier and more maintainable to me.
> > I'd like to try it out later this week.
>
>
> +1
I've take a look at the code. It is really nice! Thanks again for
sharing this great tool. I wish we could make a nice common CLI tool
out of this together.
I have some other remarks (which could be improvement ideas):
- It would be nice if people can drop their jar or classes to register
a custom tool, not just built-in tools. e.g, custom xml stream based
reading tool, commons-vfs based tool, s3 tool, etc.
- Sometimes people might want to use the `FreeMarkerTask` in
multi-threaded env or framework-integrated env (e.g, spring-batch /
spring-boot). At the moment, `FreeMarkerTask` creates the FreeMarker
`Configuration` every time. It might be better to have an option to
pass a shareable `Configuration` object to the caller task for those
cases.
Kind regards,
Woonsan
>
> >
> >>
> >> In the mean time I wrote three applications (micro services in new speak) using Apache FreeMarker and found it hard to find a starting point for a Spring Boot applications - therefore I wrote the sample project (see above). One way or the other a Spring Boot (and Micronaut) blue print should find its way into Apache FreeMarker officially. I think Apache FreeMarker is awesome for adding a developer UI to some micro service but developers don't care about the template engine but only about a quick and painless way to get the job done ...
> >
> > FWIW, in v3 branch, we also have a new submodule, freemarker-spring,
> > substituting the spring mvc jsp tag libraries:
> > - https://github.com/apache/freemarker/tree/3/freemarker-spring
> > Some examples in templates:
> > - https://github.com/apache/freemarker/tree/3/freemarker-spring/src/test/resources/META-INF/web-resources/views/test/model
> >
> > The template models, which replaces the spring jsp taglibs, are more
> > lightweight and performant.
> > I had my own GitHub repo for demo purpose, but intended to merge it to
> > v3 branch someday:
> > - https://github.com/woonsan/spring-mvc-freemarker3-demo
> > It might be a bit outdated, but you will get the idea.
> > And, I assume that mvc examples would be helpful to make a nice boot
> > example with templates.
>
> Will check out the v3 branch ...
>
> >
> >>
> >> Anyone volunteering to give a presentation about Apache Freemarker at ApacheCon? I could do but I'm not really qualified :-)
> >
> > I can give a hand, and I know you're really a qualified presenter
> > (I've attended your session about JSPWiki before).
> > So, if there's anyone, like Daniel or someone else, I'd just help out
> > with anything. If no one can join in ApacheCon NA next year, I also
> > want to volunteer preparations or even presenting together. ;-)
> >
>
> I’m honoured - I think there were altogether less than 10 attendees for my two JSPWiki presentations @ ApacheCon :)
>
> > Kind regards,
> >
> > Woonsan
> >
> >>
> >> Thanks in advance,
> >>
> >> Siegfried Goeschl
> >>
> >>
>
Re: Apache FreeMarker - Sharing Is Caring ...
Posted by Woonsan Ko <wo...@apache.org>.
Hi Siegfried,
On Wed, Dec 4, 2019 at 10:17 AM Siegfried Goeschl
<si...@gmail.com> wrote:
>
> Hi Woonsan,
>
> integrating Spring Boot is currently not an option for me
>
> * It adds additional libraries causing bloat - think of using “freemarker-cli” in Docker Images.
> * It increase the startup time significantly and JVM startup is already slow
I see.
>
> Having said that
>
> * Making the "Tools" being loaded configurable is a good idea and rather simple
+1
> * In a perfect world the “Tools" don’t have any dependency on “freemarker-cli” which is also an easy task (need to get rid of Settings.java used in two tools)
+1
Thanks! And I have no problem without spring-boot as long as it can be
used easily in that kind of frameworks. ;-)
Cheers,
Woonsan
>
> Thanks in advance,
>
> Siegfried Goeschl
>
>
> > On 4 Dec 2019, at 01:27, Woonsan Ko <wo...@apache.org> wrote:
> >
> > Hi Siegfried,
> >
> > On Tue, Dec 3, 2019 at 5:06 AM Siegfried Goeschl
> > <si...@gmail.com> wrote:
> > ---8<--- snip --->8---
> >> Regarding remarks (improvement ideas)
> >>
> >> Having an easy way to add custom tools would be nice but a bit tricky
> >
> > Right. I was imagining a Spring Boot based app which can take
> > advantage of extra libraries loading, application configuration,
> > executable jar distribution, etc. But I admit that I didn't consider
> > all different environment issues.
> > So, I'm not suggesting we should adopt something like spring-boot
> > right now, but just want to share what I was thinking below.
> >
> >>
> >> * How to pick up custom tools - config file versus class path scanning? What dependencies to pull in?
> >
> > As the current tool objects such as XmlTool are just POJO beans, it
> > seems nice if we can configure extra beans _easily_.
> > In spring-boot apps, we can provide (a) the default application
> > configuration file (e.g, application.yaml), (b) people can override
> > some properties through command line (e.g,
> > "-Dtools=com.example.tools.MyTool,com.example.tools.MyTool2"), or (c)
> > they can replace the whole configuration file through command line
> > (e.g, --spring.config.location=my.yaml).
> > And spring-boot allows to specify extra classpah too. i.e, java
> > -Dloader.path="mylib/" ...
> >
> > I'm not sure yet whether this kind of approach - simple executable jar
> > with depending on the framework's feature - may bring other drawbacks
> > that do not exist with your current solution.
> >
> > Please share what you think - pros and cons.
> >
> > Cheers,
> >
> > Woonsan
> >
> >> * How to integrate custom libs with the generated wrapper scripts - I would like to cleanly separate out-of-the-box freemarker-cli from user-specific changes, e.g. I support loading FreeMarker templates from “~/.freemarker-cli/templates”
> >>
> >> Using FreemarkerTask in a different environment
> >>
> >> * No problem to keep a shared “Configuration”
> >>
> >> Thanks in advance,
> >>
> >> Siegfried Goeschl
>
Re: Apache FreeMarker - Sharing Is Caring ...
Posted by Siegfried Goeschl <si...@gmail.com>.
Hi Woonsan,
integrating Spring Boot is currently not an option for me
* It adds additional libraries causing bloat - think of using “freemarker-cli” in Docker Images.
* It increase the startup time significantly and JVM startup is already slow
Having said that
* Making the "Tools" being loaded configurable is a good idea and rather simple
* In a perfect world the “Tools" don’t have any dependency on “freemarker-cli” which is also an easy task (need to get rid of Settings.java used in two tools)
Thanks in advance,
Siegfried Goeschl
> On 4 Dec 2019, at 01:27, Woonsan Ko <wo...@apache.org> wrote:
>
> Hi Siegfried,
>
> On Tue, Dec 3, 2019 at 5:06 AM Siegfried Goeschl
> <si...@gmail.com> wrote:
> ---8<--- snip --->8---
>> Regarding remarks (improvement ideas)
>>
>> Having an easy way to add custom tools would be nice but a bit tricky
>
> Right. I was imagining a Spring Boot based app which can take
> advantage of extra libraries loading, application configuration,
> executable jar distribution, etc. But I admit that I didn't consider
> all different environment issues.
> So, I'm not suggesting we should adopt something like spring-boot
> right now, but just want to share what I was thinking below.
>
>>
>> * How to pick up custom tools - config file versus class path scanning? What dependencies to pull in?
>
> As the current tool objects such as XmlTool are just POJO beans, it
> seems nice if we can configure extra beans _easily_.
> In spring-boot apps, we can provide (a) the default application
> configuration file (e.g, application.yaml), (b) people can override
> some properties through command line (e.g,
> "-Dtools=com.example.tools.MyTool,com.example.tools.MyTool2"), or (c)
> they can replace the whole configuration file through command line
> (e.g, --spring.config.location=my.yaml).
> And spring-boot allows to specify extra classpah too. i.e, java
> -Dloader.path="mylib/" ...
>
> I'm not sure yet whether this kind of approach - simple executable jar
> with depending on the framework's feature - may bring other drawbacks
> that do not exist with your current solution.
>
> Please share what you think - pros and cons.
>
> Cheers,
>
> Woonsan
>
>> * How to integrate custom libs with the generated wrapper scripts - I would like to cleanly separate out-of-the-box freemarker-cli from user-specific changes, e.g. I support loading FreeMarker templates from “~/.freemarker-cli/templates”
>>
>> Using FreemarkerTask in a different environment
>>
>> * No problem to keep a shared “Configuration”
>>
>> Thanks in advance,
>>
>> Siegfried Goeschl
Re: Apache FreeMarker - Sharing Is Caring ...
Posted by Siegfried Goeschl <si...@gmail.com>.
Hi folks,
Following up the discussion
* The various tools are now instantiated using "freemarker-cli.properties" and support a single argument constructor taking a map (passing configuration data) or a default constructor.
* The "freemarker-cli.properties" is picked up from the file system or class path and can be overridden on the command line
* Removed some redundancy across the available tools and aligned the namings
Regarding Spring Boot integration - not sure how feasible that is since "freemarker-cli" is still leaking command line tool abstractions. The various factory methods can be overridden in "FreeMarker Task" ...
Thanks in advance,
Siegfried Goeschl
> On 06.12.2019, at 02:21, Woonsan Ko <wo...@apache.org> wrote:
>
> On Thu, Dec 5, 2019 at 5:50 PM Denis Bredelet <bredelet@me.com.invalid <ma...@me.com.invalid>> wrote:
>>
>> Hello Woonsan,
>>
>>>> On Tue, Dec 3, 2019 at 5:06 AM Siegfried Goeschl
>>>> <si...@gmail.com> wrote:
>>>> ---8<--- snip --->8---
>>>>> Regarding remarks (improvement ideas)
>>>>>
>>>>> Having an easy way to add custom tools would be nice but a bit tricky
>>>>
>>>> Right. I was imagining a Spring Boot based app which can take
>>>> advantage of extra libraries loading, application configuration,
>>>> executable jar distribution, etc. But I admit that I didn't consider
>>>> all different environment issues.
>>>> So, I'm not suggesting we should adopt something like spring-boot
>>>> right now, but just want to share what I was thinking below.
>>
>> The settings described below are quite nice, it should be simple enough to adopt the functionality without depending on Spring.
>>
>> Just use a different configuration file name by default. Make the tool compatible with current version of Spring config file.
>>
>> If used with Spring, then pass the settings down to it.
>
> I don't think it is necessary to make it compatible with spring
> configuration file.
> freemarker-cli already has a nice abstraction,
> `com.github.sgoeschl.freemarker.cli.model.Settings`, for
> `FreeMarkerTask`.
> Anyone who wants to integrate with other framework can create the
> `Settings` from whatever-style configurations.
>
> Woonsan
>
>>
>> Does that sound good?
>> — Denis.
>>
>>>>
>>>>>
>>>>> * How to pick up custom tools - config file versus class path scanning? What dependencies to pull in?
>>>>
>>>> As the current tool objects such as XmlTool are just POJO beans, it
>>>> seems nice if we can configure extra beans _easily_.
>>>> In spring-boot apps, we can provide (a) the default application
>>>> configuration file (e.g, application.yaml), (b) people can override
>>>> some properties through command line (e.g,
>>>> "-Dtools=com.example.tools.MyTool,com.example.tools.MyTool2"), or (c)
>>>> they can replace the whole configuration file through command line
>>>> (e.g, --spring.config.location=my.yaml).
>>>> And spring-boot allows to specify extra classpah too. i.e, java
>>>> -Dloader.path="mylib/" ...
>>>
>>> Just in case, I have a spring-boot app project, which helps migrate
>>> Apache Jackrabbit binary data store from one to another:
>>> - https://github.com/woonsan/jackrabbit-datastore-migration
>>> You can find some examples about the framework features in the README.md.
>>>
>>>>
>>>> I'm not sure yet whether this kind of approach - simple executable jar
>>>> with depending on the framework's feature - may bring other drawbacks
>>>> that do not exist with your current solution.
>>>>
>>>> Please share what you think - pros and cons.
>>>>
>>>> Cheers,
>>>>
>>>> Woonsan
>>>>
>>>>> * How to integrate custom libs with the generated wrapper scripts - I would like to cleanly separate out-of-the-box freemarker-cli from user-specific changes, e.g. I support loading FreeMarker templates from “~/.freemarker-cli/templates”
>>>>>
>>>>> Using FreemarkerTask in a different environment
>>>>>
>>>>> * No problem to keep a shared “Configuration”
>>>>>
>>>>> Thanks in advance,
>>>>>
>>>>> Siegfried Goeschl
Re: Apache FreeMarker - Sharing Is Caring ...
Posted by Woonsan Ko <wo...@apache.org>.
On Thu, Dec 5, 2019 at 5:50 PM Denis Bredelet <br...@me.com.invalid> wrote:
>
> Hello Woonsan,
>
> >> On Tue, Dec 3, 2019 at 5:06 AM Siegfried Goeschl
> >> <si...@gmail.com> wrote:
> >> ---8<--- snip --->8---
> >>> Regarding remarks (improvement ideas)
> >>>
> >>> Having an easy way to add custom tools would be nice but a bit tricky
> >>
> >> Right. I was imagining a Spring Boot based app which can take
> >> advantage of extra libraries loading, application configuration,
> >> executable jar distribution, etc. But I admit that I didn't consider
> >> all different environment issues.
> >> So, I'm not suggesting we should adopt something like spring-boot
> >> right now, but just want to share what I was thinking below.
>
> The settings described below are quite nice, it should be simple enough to adopt the functionality without depending on Spring.
>
> Just use a different configuration file name by default. Make the tool compatible with current version of Spring config file.
>
> If used with Spring, then pass the settings down to it.
I don't think it is necessary to make it compatible with spring
configuration file.
freemarker-cli already has a nice abstraction,
`com.github.sgoeschl.freemarker.cli.model.Settings`, for
`FreeMarkerTask`.
Anyone who wants to integrate with other framework can create the
`Settings` from whatever-style configurations.
Woonsan
>
> Does that sound good?
> — Denis.
>
> >>
> >>>
> >>> * How to pick up custom tools - config file versus class path scanning? What dependencies to pull in?
> >>
> >> As the current tool objects such as XmlTool are just POJO beans, it
> >> seems nice if we can configure extra beans _easily_.
> >> In spring-boot apps, we can provide (a) the default application
> >> configuration file (e.g, application.yaml), (b) people can override
> >> some properties through command line (e.g,
> >> "-Dtools=com.example.tools.MyTool,com.example.tools.MyTool2"), or (c)
> >> they can replace the whole configuration file through command line
> >> (e.g, --spring.config.location=my.yaml).
> >> And spring-boot allows to specify extra classpah too. i.e, java
> >> -Dloader.path="mylib/" ...
> >
> > Just in case, I have a spring-boot app project, which helps migrate
> > Apache Jackrabbit binary data store from one to another:
> > - https://github.com/woonsan/jackrabbit-datastore-migration
> > You can find some examples about the framework features in the README.md.
> >
> >>
> >> I'm not sure yet whether this kind of approach - simple executable jar
> >> with depending on the framework's feature - may bring other drawbacks
> >> that do not exist with your current solution.
> >>
> >> Please share what you think - pros and cons.
> >>
> >> Cheers,
> >>
> >> Woonsan
> >>
> >>> * How to integrate custom libs with the generated wrapper scripts - I would like to cleanly separate out-of-the-box freemarker-cli from user-specific changes, e.g. I support loading FreeMarker templates from “~/.freemarker-cli/templates”
> >>>
> >>> Using FreemarkerTask in a different environment
> >>>
> >>> * No problem to keep a shared “Configuration”
> >>>
> >>> Thanks in advance,
> >>>
> >>> Siegfried Goeschl
>
Re: Apache FreeMarker - Sharing Is Caring ...
Posted by Denis Bredelet <br...@me.com.INVALID>.
Hello Woonsan,
>> On Tue, Dec 3, 2019 at 5:06 AM Siegfried Goeschl
>> <si...@gmail.com> wrote:
>> ---8<--- snip --->8---
>>> Regarding remarks (improvement ideas)
>>>
>>> Having an easy way to add custom tools would be nice but a bit tricky
>>
>> Right. I was imagining a Spring Boot based app which can take
>> advantage of extra libraries loading, application configuration,
>> executable jar distribution, etc. But I admit that I didn't consider
>> all different environment issues.
>> So, I'm not suggesting we should adopt something like spring-boot
>> right now, but just want to share what I was thinking below.
The settings described below are quite nice, it should be simple enough to adopt the functionality without depending on Spring.
Just use a different configuration file name by default. Make the tool compatible with current version of Spring config file.
If used with Spring, then pass the settings down to it.
Does that sound good?
— Denis.
>>
>>>
>>> * How to pick up custom tools - config file versus class path scanning? What dependencies to pull in?
>>
>> As the current tool objects such as XmlTool are just POJO beans, it
>> seems nice if we can configure extra beans _easily_.
>> In spring-boot apps, we can provide (a) the default application
>> configuration file (e.g, application.yaml), (b) people can override
>> some properties through command line (e.g,
>> "-Dtools=com.example.tools.MyTool,com.example.tools.MyTool2"), or (c)
>> they can replace the whole configuration file through command line
>> (e.g, --spring.config.location=my.yaml).
>> And spring-boot allows to specify extra classpah too. i.e, java
>> -Dloader.path="mylib/" ...
>
> Just in case, I have a spring-boot app project, which helps migrate
> Apache Jackrabbit binary data store from one to another:
> - https://github.com/woonsan/jackrabbit-datastore-migration
> You can find some examples about the framework features in the README.md.
>
>>
>> I'm not sure yet whether this kind of approach - simple executable jar
>> with depending on the framework's feature - may bring other drawbacks
>> that do not exist with your current solution.
>>
>> Please share what you think - pros and cons.
>>
>> Cheers,
>>
>> Woonsan
>>
>>> * How to integrate custom libs with the generated wrapper scripts - I would like to cleanly separate out-of-the-box freemarker-cli from user-specific changes, e.g. I support loading FreeMarker templates from “~/.freemarker-cli/templates”
>>>
>>> Using FreemarkerTask in a different environment
>>>
>>> * No problem to keep a shared “Configuration”
>>>
>>> Thanks in advance,
>>>
>>> Siegfried Goeschl
Re: Apache FreeMarker - Sharing Is Caring ...
Posted by Woonsan Ko <wo...@apache.org>.
On Tue, Dec 3, 2019 at 7:27 PM Woonsan Ko <wo...@apache.org> wrote:
>
> Hi Siegfried,
>
> On Tue, Dec 3, 2019 at 5:06 AM Siegfried Goeschl
> <si...@gmail.com> wrote:
> ---8<--- snip --->8---
> > Regarding remarks (improvement ideas)
> >
> > Having an easy way to add custom tools would be nice but a bit tricky
>
> Right. I was imagining a Spring Boot based app which can take
> advantage of extra libraries loading, application configuration,
> executable jar distribution, etc. But I admit that I didn't consider
> all different environment issues.
> So, I'm not suggesting we should adopt something like spring-boot
> right now, but just want to share what I was thinking below.
>
> >
> > * How to pick up custom tools - config file versus class path scanning? What dependencies to pull in?
>
> As the current tool objects such as XmlTool are just POJO beans, it
> seems nice if we can configure extra beans _easily_.
> In spring-boot apps, we can provide (a) the default application
> configuration file (e.g, application.yaml), (b) people can override
> some properties through command line (e.g,
> "-Dtools=com.example.tools.MyTool,com.example.tools.MyTool2"), or (c)
> they can replace the whole configuration file through command line
> (e.g, --spring.config.location=my.yaml).
> And spring-boot allows to specify extra classpah too. i.e, java
> -Dloader.path="mylib/" ...
Just in case, I have a spring-boot app project, which helps migrate
Apache Jackrabbit binary data store from one to another:
- https://github.com/woonsan/jackrabbit-datastore-migration
You can find some examples about the framework features in the README.md.
>
> I'm not sure yet whether this kind of approach - simple executable jar
> with depending on the framework's feature - may bring other drawbacks
> that do not exist with your current solution.
>
> Please share what you think - pros and cons.
>
> Cheers,
>
> Woonsan
>
> > * How to integrate custom libs with the generated wrapper scripts - I would like to cleanly separate out-of-the-box freemarker-cli from user-specific changes, e.g. I support loading FreeMarker templates from “~/.freemarker-cli/templates”
> >
> > Using FreemarkerTask in a different environment
> >
> > * No problem to keep a shared “Configuration”
> >
> > Thanks in advance,
> >
> > Siegfried Goeschl
Re: Apache FreeMarker - Sharing Is Caring ...
Posted by Woonsan Ko <wo...@apache.org>.
Hi Siegfried,
On Tue, Dec 3, 2019 at 5:06 AM Siegfried Goeschl
<si...@gmail.com> wrote:
---8<--- snip --->8---
> Regarding remarks (improvement ideas)
>
> Having an easy way to add custom tools would be nice but a bit tricky
Right. I was imagining a Spring Boot based app which can take
advantage of extra libraries loading, application configuration,
executable jar distribution, etc. But I admit that I didn't consider
all different environment issues.
So, I'm not suggesting we should adopt something like spring-boot
right now, but just want to share what I was thinking below.
>
> * How to pick up custom tools - config file versus class path scanning? What dependencies to pull in?
As the current tool objects such as XmlTool are just POJO beans, it
seems nice if we can configure extra beans _easily_.
In spring-boot apps, we can provide (a) the default application
configuration file (e.g, application.yaml), (b) people can override
some properties through command line (e.g,
"-Dtools=com.example.tools.MyTool,com.example.tools.MyTool2"), or (c)
they can replace the whole configuration file through command line
(e.g, --spring.config.location=my.yaml).
And spring-boot allows to specify extra classpah too. i.e, java
-Dloader.path="mylib/" ...
I'm not sure yet whether this kind of approach - simple executable jar
with depending on the framework's feature - may bring other drawbacks
that do not exist with your current solution.
Please share what you think - pros and cons.
Cheers,
Woonsan
> * How to integrate custom libs with the generated wrapper scripts - I would like to cleanly separate out-of-the-box freemarker-cli from user-specific changes, e.g. I support loading FreeMarker templates from “~/.freemarker-cli/templates”
>
> Using FreemarkerTask in a different environment
>
> * No problem to keep a shared “Configuration”
>
> Thanks in advance,
>
> Siegfried Goeschl
Re: Apache FreeMarker - Sharing Is Caring ...
Posted by Siegfried Goeschl <si...@gmail.com>.
Hi Woonsan,
thanks for having a look - and nothing stops us making a nice common CLI tool :-)
Regarding remarks (improvement ideas)
Having an easy way to add custom tools would be nice but a bit tricky
* How to pick up custom tools - config file versus class path scanning? What dependencies to pull in?
* How to integrate custom libs with the generated wrapper scripts - I would like to cleanly separate out-of-the-box freemarker-cli from user-specific changes, e.g. I support loading FreeMarker templates from “~/.freemarker-cli/templates”
Using FreemarkerTask in a different environment
* No problem to keep a shared “Configuration”
Thanks in advance,
Siegfried Goeschl
> On 2 Dec 2019, at 21:02, Woonsan Ko <wo...@apache.org> wrote:
>
> Please see my comments inline. Thanks!
>
> On Tue, Nov 19, 2019 at 4:35 AM Siegfried Goeschl
> <siegfried.goeschl@gmail.com <ma...@gmail.com>> wrote:
>>
>> Hi Woonsan,
>>
>> please see my comments below …
>>
>> Thanks in advance,
>>
>> Siegfried Goeschl
>>
>>
>>> On 19 Nov 2019, at 00:03, Woonsan Ko <wo...@apache.org> wrote:
>>>
>>> Hi Siegfried,
>>>
>>> On Sun, Nov 17, 2019 at 1:02 PM Siegfried Goeschl
>>> <si...@gmail.com> wrote:
>>>>
>>>> Hi folks,
>>>>
>>>> since I'm currently mostly busy with non-coding tasks I spent some time honing my coding skills - probably to no avail as my colleagues would say ;-)
>>>>
>>>> 1) I migrated my pet project "freemarker-cli" from Groovy to JDK 8 (see https://github.com/sgoeschl/freemarker-cli <https://github.com/sgoeschl/freemarker-cli>)
>>>>
>>>> 2) At https://github.com/sgoeschl/presentations/blob/master/javameetup/freemarker/slides/src/docs/asciidoc/index.adoc <https://github.com/sgoeschl/presentations/blob/master/javameetup/freemarker/slides/src/docs/asciidoc/index.adoc> you find a presentation I gave some while ago
>>>>
>>>> 3) I also wrote a Spring Boot FreeMarker sample project as part of the presentation (see https://github.com/sgoeschl/presentations/tree/master/javameetup/freemarker/demo <https://github.com/sgoeschl/presentations/tree/master/javameetup/freemarker/demo>)
>>>>
>>>> My plans / questions
>>>>
>>>> I would be awesome if I could get some feedback about "freemarker-cli" in its current JDK incarnation :-) Later on I will release 2.0.0 and push it to Maven Central.
>>>
>>> I like the idea in principle. We have some other "generators" - code
>>> generators for example, but this simple transformation/generation in
>>> CLI seems very useful too. Just as an example, I have seen my
>>> colleagues writing python scripts to convert one format to another.
>>> Your tool seems easier and more maintainable to me.
>>> I'd like to try it out later this week.
>>
>>
>> +1
>
> I've take a look at the code. It is really nice! Thanks again for
> sharing this great tool. I wish we could make a nice common CLI tool
> out of this together.
>
> I have some other remarks (which could be improvement ideas):
> - It would be nice if people can drop their jar or classes to register
> a custom tool, not just built-in tools. e.g, custom xml stream based
> reading tool, commons-vfs based tool, s3 tool, etc.
> - Sometimes people might want to use the `FreeMarkerTask` in
> multi-threaded env or framework-integrated env (e.g, spring-batch /
> spring-boot). At the moment, `FreeMarkerTask` creates the FreeMarker
> `Configuration` every time. It might be better to have an option to
> pass a shareable `Configuration` object to the caller task for those
> cases.
>
> Kind regards,
>
> Woonsan
>
>>
>>>
>>>>
>>>> In the mean time I wrote three applications (micro services in new speak) using Apache FreeMarker and found it hard to find a starting point for a Spring Boot applications - therefore I wrote the sample project (see above). One way or the other a Spring Boot (and Micronaut) blue print should find its way into Apache FreeMarker officially. I think Apache FreeMarker is awesome for adding a developer UI to some micro service but developers don't care about the template engine but only about a quick and painless way to get the job done ...
>>>
>>> FWIW, in v3 branch, we also have a new submodule, freemarker-spring,
>>> substituting the spring mvc jsp tag libraries:
>>> - https://github.com/apache/freemarker/tree/3/freemarker-spring
>>> Some examples in templates:
>>> - https://github.com/apache/freemarker/tree/3/freemarker-spring/src/test/resources/META-INF/web-resources/views/test/model
>>>
>>> The template models, which replaces the spring jsp taglibs, are more
>>> lightweight and performant.
>>> I had my own GitHub repo for demo purpose, but intended to merge it to
>>> v3 branch someday:
>>> - https://github.com/woonsan/spring-mvc-freemarker3-demo
>>> It might be a bit outdated, but you will get the idea.
>>> And, I assume that mvc examples would be helpful to make a nice boot
>>> example with templates.
>>
>> Will check out the v3 branch ...
>>
>>>
>>>>
>>>> Anyone volunteering to give a presentation about Apache Freemarker at ApacheCon? I could do but I'm not really qualified :-)
>>>
>>> I can give a hand, and I know you're really a qualified presenter
>>> (I've attended your session about JSPWiki before).
>>> So, if there's anyone, like Daniel or someone else, I'd just help out
>>> with anything. If no one can join in ApacheCon NA next year, I also
>>> want to volunteer preparations or even presenting together. ;-)
>>>
>>
>> I’m honoured - I think there were altogether less than 10 attendees for my two JSPWiki presentations @ ApacheCon :)
>>
>>> Kind regards,
>>>
>>> Woonsan
>>>
>>>>
>>>> Thanks in advance,
>>>>
>>>> Siegfried Goeschl