OK, no classpath loading for now. Can be done later if it will be a problem with Maven plugin or other non-CLI thing. After all, it's pretty transparent where the templates are coming from.
So, what about the reserved directory that holds all these built in templates? See earlier in this thread. That also eliminates the issue with colliding with user templates (which you listed above). That's why I brought it up actually, and for understability for the users. (I don't get why you relate name clashes with loading from jar VS from plain directory. The name clash problem happens in both cases, and modifying the installation is not an acceptable solution anyway.) Users can supply their own templates in their home directory, or maybe in the future in /etc/freemarker-generator, and again, not by replacing installed templates. (Even then, shadowing a standard template is something I would prevent. Preventing unwise users from hurting themselves is a pretty important design goal.) On Tue, Aug 11, 2020 at 9:49 PM Siegfried Goeschl < siegfried.goes...@gmail.com> wrote: > 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? > > -- Best regards, Daniel Dekany
