freemarker-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Dekany <daniel.dek...@gmail.com>
Subject Re: FreeMarker generator release preparations
Date Thu, 20 Aug 2020 20:17:29 GMT
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.goeschl@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.dekany@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.goeschl@gmail.com <mailto:siegfried.goeschl@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.goeschl@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.dekany@gmail.com
> >> <mailto:daniel.dekany@gmail.com <mailto:daniel.dekany@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.goeschl@gmail.com <mailto:siegfried.goeschl@gmail.com>
> <mailto:siegfried.goeschl@gmail.com <mailto:siegfried.goeschl@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.dekany@gmail.com
> <mailto:daniel.dekany@gmail.com>
> >> <mailto:daniel.dekany@gmail.com <mailto:daniel.dekany@gmail.com>>>
> wrote:
> >>>>>>
> >>>>>> On Mon, Aug 10, 2020 at 8:53 PM Siegfried Goeschl <
> >>>>>> siegfried.goeschl@gmail.com <mailto:siegfried.goeschl@gmail.com>
> <mailto:siegfried.goeschl@gmail.com <mailto:siegfried.goeschl@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message