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 <[email protected]> wrote: > > On Thu, Dec 5, 2019 at 5:50 PM Denis Bredelet <[email protected] > <mailto:[email protected]>> wrote: >> >> Hello Woonsan, >> >>>> 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. >> >> 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
