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 <[email protected]> wrote:
> 
> Hi Siegfried,
> 
> On Tue, Dec 3, 2019 at 5:06 AM Siegfried Goeschl
> <[email protected]> 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

Reply via email to