Hi Daniel, Regarding SNAPSHOTs - I would be glad to see all the moving parts working, e.g. generated artefacts, Hayes, signatures and upload :-)
Thanks in advance, Siegfried Goeschl > On 13.08.2020, at 02:16, Daniel Dekany <[email protected]> wrote: > > 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 < > [email protected] <mailto:[email protected]>> 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 <[email protected]> >> 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 <[email protected] >> <mailto:[email protected] <mailto:[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] <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[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] >>>>>> <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> wrote: >>>>>> >>>>>> On Mon, Aug 10, 2020 at 8:53 PM Siegfried Goeschl < >>>>>> [email protected] <mailto:[email protected]> >>>>>> <mailto:[email protected] >>>>>> <mailto:[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 >>> >> >> > > -- > Best regards, > Daniel Dekany
