Hi Daniel, yesterday's email was a bit short since I was drained from the heat :-(
* I would like to provide a bunch of useful / generic templates together with the FreeMarker Generator CLI - if those templates solve or mostly solve one's problem we successfully increased the community * The useful / generic templates will be relying on code from freemarker-generator-tools so they are currently not generic since the Maven plugin will not use freemarker-generator-tools due to the transitive dependencies * Bundling useful templates can be done as file or from a JAR - personally I prefer files to make things more visible by having files but class path resources are also possible * Strictly personal opinion - problem with bundled templates is that they might collide with user-supplied templates (rather theoretical issue but log4j.properties picked up from the class path drove me crazy in the past) * Consequently if a user really wants to remove / modify provided templates or add some new templates that's fine for me - it is a free country and they obviously know what they are doing * On my last cloud project it would have been actually feasible to assemble a custom "freemarker-generator-cli" with more / other templates, e.g. dumping Java keystores (which was done by some ugly shell script) So at the end of the day I think we are discussing a very minor point where we have different opinions and I don't see any real benefit from using class path loading Thanks in advance, Siegfried Goeschl > On 11.08.2020, at 09:30, Daniel Dekany <daniel.dek...@gmail.com> wrote: > > On Mon, Aug 10, 2020 at 8:53 PM Siegfried Goeschl < > siegfried.goes...@gmail.com> wrote: > >>> The fundamental problem with that is this. Currently, if you pull in >>> freemarker-generator-cli as Maven dependency, the templates will not be >>> available. Surely, because it's the CLI, you could say that it's not >>> supposed to be used without the FreeMarker Generator Home Directory >> created >>> somewhere, which contains the launch script and templates/ and all. But, >> if >>> these templates are guaranteed functionality in FreeMarker Generator, >> then >>> they don't strictly belong to the CLI. When we will have a proper Maven >>> plugin for example, they should be still accessible. In that case you >> only >>> have your Maven dependencies, so the templates must come from there. >>> >>> Regarding visibility, it's a bit like with Java. Java classes are not too >>> readable without looking at the source code either. That's not an >> advantage >>> when it comes to "visibility", sure. But luckily this is open source, and >>> it's very easy to get to the source code, if someone really cares (like >>> from the Maven source artifact). That applies to core stuff implemented >> in >>> FTL as well. So, the previously mentioned advantage (that they are >>> available from a plain dependency) certainly overweights this >> disadvantage >>> (less visibility). >> >> I currently disagree here - I like the visibility aspect and it is pretty >> difficult to get rid of templates loaded from the classpath. >> > > What do you mean by getting rid of them? I hope you agree that users > shouldn't remove or modify these templates directly in the FreeMarker > Generator installation. > > What do you intend to do about the dependency problem, described above?
