Also, I'm quite certain "templates" meant to be under "main", similarly as
"config" already is. (In case it's not just an oversight, it's because the
top-level categories under "src" ("main", "test", and "site") are the
different kind of deliverables. (OK, the test suite isn't really
deliverable, but it's a separate unit.) "templates" and "config" are both
part of the main deliverable, which is the app artifact, so they belong
under "main".)"src/scripts" doesn't look right for the same reason. As we deliver them with the app, they belong under "main". Where inside that is not that clear to me... I mean Maven doesn't really establish a convention there, but maybe unde the assembly? Or maybe there should be a main/app-home to pack all the statics under the app home (tempaltes, config, run-examples...). So that's a more like matter of preference thing, I guess. On Thu, Aug 20, 2020 at 10:17 PM Daniel Dekany <daniel.dek...@gmail.com> wrote: > We will need your signature that's here: > https://dist.apache.org/repos/dist/dev/freemarker/KEYS and > https://dist.apache.org/repos/dist/release/freemarker/KEYS, at least if > you build the release artifacts. Otherwise I'm not exactly sure how you > want to do this snapshot release thing. I think the best way to try if > releasing is working is trying to do a release, but not actually start > voting, and obviously not letting it outside the staging repo. > > I think you should merge back FREEMARKER-153 into the main branch, because > it's the development head right now. (Like, if someone wanted to add a PR, > it should be based on what's now 153, hence, that should be the master.) > > One thing I just ran into, while trying to add the rest of the docs. The > configuration/freemarker-generator.properties is found based on CLASSPATH, > while templates is found based on the "app.home" system property. I think > it would be good if bareily setting "app.home", and ensuring the the Maven > dependencies (jar-s) are found by Java makes the CLI work. I ran into this, > because to generate documentation I need to class freemarker-generator from > Maven (to capture the --help, etc.), and since the launcher scripts are > platform dependent, I directly call > org.apache.freemarker.generator.cli.Main. But I think in general that would > be a step in the right direction, if that only has minimal requirements. > > On Fri, Aug 14, 2020 at 12:22 PM Siegfried Goeschl < > siegfried.goes...@gmail.com> wrote: > >> 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 <daniel.dek...@gmail.com> 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 < >> > siegfried.goes...@gmail.com <mailto: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 <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> >> <mailto: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> >> >> <mailto: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> >> <mailto: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 >> >> > > -- > Best regards, > Daniel Dekany > -- Best regards, Daniel Dekany
