Hi Daniel, Just pushed the changes
freemarker-generator -t freemarker-generator/info.ftl Thanks in advance, Siegfried Goeschl > On 11.08.2020, at 22:44, Daniel Dekany <[email protected]> wrote: > > 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 < > [email protected]> 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 <[email protected]> wrote: >>> >>> On Mon, Aug 10, 2020 at 8:53 PM Siegfried Goeschl < >>> [email protected]> 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
