A SNAPSHOT version is not public, so it's not really a release, and for internal testing you can build stuff.
Also, I don't remember right now anything super important, but there are mails where I listed things. Yeah, I'm still in debt with the docgen conversion. It kind of works, if you saw that branch. I will continue to copy the md content into it, and hopefully won't run into any more stuff that makes me add Docgen features. (Like last time I started shoveling in the Examples section, only to realize that we need to be able to insert external files, so now we don't have to copy-paste templates and such into the documentation, each time they are changed in the source code.) Though it's not strictly a blocker for any kind kind of release. On Wed, Aug 12, 2020 at 8:53 PM Siegfried Goeschl < siegfried.goes...@gmail.com> wrote: > 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 > > > > -- Best regards, Daniel Dekany
