freemarker-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Siegfried Goeschl <>
Subject Re: FreeMarker generator release preparations
Date Wed, 12 Aug 2020 18:53:35 GMT
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 <> 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 < <>>
>> 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 <
>> <>> 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
>>> 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 < <>>
>>>> On Mon, Aug 10, 2020 at 8:53 PM Siegfried Goeschl <
>>>> <>>
>>>>>> The fundamental problem with that is this. Currently, if you pull
>>>>>> freemarker-generator-cli as Maven dependency, the templates will
not be
>>>>>> available. Surely, because it's the CLI, you could say that it's
>>>>>> 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
>>>>>> plugin for example, they should be still accessible. In that  case
>>>>> only
>>>>>> have your Maven dependencies, so the templates must come from there.
>>>>>> Regarding visibility, it's a bit like with Java. Java classes are
>>> 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
>>>>>> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message