Hello Woonsan, >> On Tue, Dec 3, 2019 at 5:06 AM Siegfried Goeschl >> <siegfried.goes...@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
