As far as I see, it's a case where you can know very well that there's a problem, but don't tell the user. Suppressing an error.
On Mon, Aug 24, 2020 at 8:12 PM Siegfried Goeschl < siegfried.goes...@gmail.com> wrote: > Hi Daniel, > > Please see my comments below > > Thanks in advance, > > Siegfried Goeschl > > > > > On 24.08.2020, at 13:12, Daniel Dekany <daniel.dek...@gmail.com> wrote: > > > > BTW, the example templates will need some reviewing. Something I saw a > lot > > was using foo["bar"] instead if foo.bar. That's something people used to > be > > confused about (when can they use which form), and just default to > > foo["bar"]. Thus we should use terser dotter form whenever we can, > showing > > that it's safe and good practice to do so. > > I will have a look ... > > > > > Also, I have noticed we still do the dataSources?values[0] thing. You > > didn't add anything for that case after all (or the examples are > outdated)? > > So this is probably by far the most frequent use case, where we expected > > exactly 1 data source. The problem is that if you pass in 2 sources, > > dataSources?values[0] will silently ignore the 2nd source, instead of > > failing. > > Yes, we had discussion about it ;-) > > * IMHO it is a bit of gold-plating so I did not change anything > * I tried to to implement "dataSources[0]" instead of using > "dataSources?values[0]" but I had to revert the changes to due mirroring > problems (but it is still on my todo list) > > Thanks in advance, > > Siegfried Goeschl > > > > > > > > > > On Sun, Aug 23, 2020 at 8:42 PM Siegfried Goeschl < > > siegfried.goes...@gmail.com> wrote: > > > >> Hi Daniel, > >> > >> I'm using now "app.home" system property to bootstrap the configuration > >> and merged FREEMARKER-153. > >> > >> So in theory you could rebase/merge and try to use "app.home" ... > >> > >> Thanks in advance, > >> > >> Siegfried Goeschl > >> > >> > >>> On 22.08.2020, at 19:43, Daniel Dekany <daniel.dek...@gmail.com> > wrote: > >>> > >>> Link was wrong as well: > >>> > >> > https://github.com/apache/freemarker-generator/blob/FREEMARKER-154/freemarker-generator-website/pom.xml#L85 > >>> The you see what's needed currently only to get the info.ftl output. > >>> > >>> On Sat, Aug 22, 2020 at 7:39 PM Daniel Dekany <daniel.dek...@gmail.com > > > >>> wrote: > >>> > >>>> Pf, lot of typos... so to clarify, I did solve it, it's just fragile. > >> Also > >>>> onE of the "main" artifacts is > >>>> freemarker-generator-cli-0.1.0-SNAPSHOT-app.tar.gz (so there, > >> classifier is > >>>> "app"). That's deployed to the repository, so it's a "real" artifact. > >>>> > >>>> On Sat, Aug 22, 2020 at 7:34 PM Daniel Dekany < > daniel.dek...@gmail.com> > >>>> wrote: > >>>> > >>>>> I could hack it around, the problem is that it's fragile as it is: > >>>>> > >> > https://github.com/apache/freemarker-generator/blob/FREEMARKER-154/pom.xml > >>>>> If it only needed app.home, then it would be much less fragile. (And > >> also > >>>>> easier for others to call it without the scripts. Well, OK, almost > >> nobody > >>>>> needs that... but it's cleaner overall.) > >>>>> > >>>>> There are main artifacts of different classifiers, on is "app". All > >>>>> belong to "main" from Maven's perspective. Anyway, the point is to > >> have a > >>>>> project structure that helps understanding stuff. > >>>>> > >>>>> main/app is fine with me. > >>>>> > >>>>> On Sat, Aug 22, 2020 at 10:01 AM Siegfried Goeschl < > >>>>> siegfried.goes...@gmail.com> wrote: > >>>>> > >>>>>> Hi Daniel, > >>>>>> > >>>>>> I'm mostly fine with the current directory layout > >>>>>> > >>>>>> * There is some documentation here - > >>>>>> > >> > https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html > >>>>>> * As far as Maven is concerned the main artefact is the JAR > >>>>>> * Having said that the "Appassembler Maven plugin" makes assumptions > >> as > >>>>>> well > >>>>>> * The "config" is (sort of still) there because until recently I > >>>>>> packaged the config file as part of the JAR (currently > >> FREEMARKER-153) and > >>>>>> actually had two of them :-( > >>>>>> > >>>>>> I will review my changes before merging FREEMARKER-153 into master > >> (end > >>>>>> of this week hopefully) > >>>>>> > >>>>>> I do not fully understand the problem you had with the configuration > >>>>>> when generating the docs - in the meantime you can start the Main > >> class > >>>>>> without config file > >>>>>> > >>>>>> Thanks in advance, > >>>>>> > >>>>>> Siegfried Goeschl > >>>>>> > >>>>>> > >>>>>> > >>>>>>> On 21.08.2020, at 11:59, Daniel Dekany <daniel.dek...@gmail.com> > >>>>>> wrote: > >>>>>>> > >>>>>>> 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 > >>>>>> > >>>>>> > >>>>> > >>>>> -- > >>>>> Best regards, > >>>>> Daniel Dekany > >>>>> > >>>> > >>>> > >>>> -- > >>>> Best regards, > >>>> Daniel Dekany > >>>> > >>> > >>> > >>> -- > >>> Best regards, > >>> Daniel Dekany > >> > >> > > > > -- > > Best regards, > > Daniel Dekany > > -- Best regards, Daniel Dekany
