Hi Daniel, Anything other things in the way for preparing a SNAPSHOT release?
Thanks in advance, Siegfried Goeschl > On 11.08.2020, at 22:57, Siegfried Goeschl <siegfried.goes...@gmail.com> > wrote: > > 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 <daniel.dek...@gmail.com >> <mailto:daniel.dek...@gmail.com>> 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 < >> siegfried.goes...@gmail.com <mailto: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 >>>> <mailto:daniel.dek...@gmail.com>> wrote: >>>> >>>> On Mon, Aug 10, 2020 at 8:53 PM Siegfried Goeschl < >>>> siegfried.goes...@gmail.com <mailto: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 >
