freemarker-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Siegfried Goeschl <siegfried.goes...@gmail.com>
Subject Re: FreeMarker generator release preparations
Date Tue, 11 Aug 2020 20:57:08 GMT
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.dekany@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.goeschl@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.dekany@gmail.com> wrote:
>>> 
>>> On Mon, Aug 10, 2020 at 8:53 PM Siegfried Goeschl <
>>> siegfried.goeschl@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


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