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
