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
