Re: Alternative to ${exp}
Saturday, March 24, 2018, 4:33:01 PM, Woonsan Ko wrote:
> Hi folks,
>
> I'd like to bring this topic again to our attention.
> It started totally my own mistake by being confused "Square bracket
> tag syntax" (since 2.3.4) with the new "Square bracket interpolation
> syntax" (since 2.3.28). [1]
> Here's my example in another thread [2]:
>
> 1: [#ftl output_format="HTML"]
> 2: [#assign a=[1,2,3]]
> 3: [="Hello"]
>
> #1 and #2 work as they are using the "Square bracket tag syntax", but
> #3 doesn't by default (unless you change the configuration to use
> "Square bracket interpolation" option).
> So, it should have been like the following for intention:
>
> 1: [#ftl output_format="HTML"]
> 2: [#assign a=[1,2,3]]
> 3: ${"Hello"}
>
> Now, I'm wondering if this kind of confusion could happen more to other
> people.
> When they use square bracket tag syntax, they might be easily doing
> the same thing for the interpolation like the first example.
>
> One possible solution could be to use mustache as the default
> alternative for interpolation like this:
>
> 1: [#ftl output_format="HTML"]
> 2: [#assign a=[1,2,3]]
> 3: {{"Hello"}}
>
> As interpolation's alternative syntax is to use mustache, it might be
> less confusing by not using the same syntax for both tags and
> interpolation.
> My old reason why avoiding mustache was, Javascript framework could
> use both '${something}' [3] and '{{something}}' together. But also if
> someones adopts mustache style JS frameworks, they might not use the
> technique like [3]. Not sure though...
After re-reading and re-thinking the thread, I'm back to the opinion
that fighting the confusion arousing from the mere coincidence that
both things are "square bracket" is the better compromise:
- While using {{...}} in output is not very frequent, when it's used
in the output, there's a quite real chance that the output also uses
${...}. A lot of languages and formats use ${...}, now including the
omnipresent JavaScript, and so ${...} will become more frequent in
web pages in the future. So, if you generate Angular pages for
example, it's quite possible that they use both... and then what
will you do?
- Using square bracket tag syntax together with square bracket
interpolation syntax makes template-templates (a template of a
template, be it FreeMarker template, JSP, etc.) easy to read, as
your visual cortex can just hunt for the [...]-s. It matters because
template-templates tend to be already messy, I guess.
BTW, I have discovered a slight drawback of [=...] while using it.
Instead of ${x} you write [=x], fine. But what do you write instead of
${x + 1}? The logical one is [=x + 1], but its spacing is ugly, so I
think it's going to be [= x + 1]. One more space. Yeah, quite a nick
picking, but just so you know about it...
> Another possible option could be to allow to change the interpolation
> syntax to square bracket automatically as well if the first [#ftl ...]
> is used like the tag syntax's automatic switching per template.
> But I'm not sure what the implication is behind about this.
Templates that did work earlier won't, which is a pretty concrete
implication. (: I wish we only had <#>+${} and [#]+[=] from the
beginning, but now we can't do that. Not in FM2 at least. Maybe we
should do that in FM3. Actually, yeah, it would be much easier if one
can just chose a "template syntax", not a "tag syntax" and an
"interpolation syntax".
> What do you think? Would my confusion be ignorable or do we need to
> think about the alternative interpolation syntax again?
It's not ignorable, but there are multiple ways of countering this. My
grand plan (: is that some people will do that oversight you did, but
they will realize pretty quickly that something is wrong (it's not the
kind of problem that can remain hidden), and then they will ask
Google, and hopefully will not be able to avoid the "notices" I stick
every place where we are talking about square brackets. How about
that?
> Kind regards,
>
> Woonsan
>
> [1]
> https://freemarker.apache.org/builds/fm2.3.28/dgui_misc_alternativesyntax.html
> [2]
> https://lists.apache.org/thread.html/2372e673c5b8bd91150f7dd43319786dda8af38acdef87cd37f09ead@%3Cdev.freemarker.apache.org%3E
> [3] https://en.wikipedia.org/wiki/String_interpolation#JavaScript
>
> On Fri, Dec 15, 2017 at 5:28 AM, Daniel Dekany <ddek...@apache.org> wrote:
>> OK, so I would go for [=exp] (see the reason told in this thread). How
>> acceptable is that guys?
>>
>>
>> Tuesday, December 5, 2017, 11:56:59 AM, Woonsan Ko wrote:
>>
>>> On Mon, Dec 4, 2017 at 10:28 AM, D
Re: Please test/review FreeMarker 2.3.28
Saturday, March 24, 2018, 3:41:59 PM, Daniel Dekany wrote:
[snip]
>> Could this local build cause a problem? (I saw differences between
>> "2.3" and "2.3-gae". See below. So I probably should have built
>> "2.3-gae" branch?)
>
> But should work, except if I screw up and forgot to push one of them,
"*Both* should work", I meant.
[snip]
>> I got: 1,2,3 [="Hello"] Hello
>> Thanks for clarification!
>
> Note that the square bracket *tag* syntax and that it can be activated
> with [#ftl] exists for a very long time.
>
> I will update the related Manual page in a minute...
Done, see:
https://freemarker.apache.org/builds/fm2.3.28/dgui_misc_alternativesyntax.html
>>> documentation. Or, it's a warning sign that we should rather use
>>> {{exp}}, as that doesn't have "square brackets" in it.
>>
>> Perhaps. ;-)
>> I recently had a chance to look around other templating libraries
>> using the mustache as I have seen people loving it.
>> I didn't like the usages there in directives. For example, {{#if
>> user}} {{user.name}} {{/if}}. It's hard for me complete the if, ending
>> with {{/if}}, which is too much. ;-)
>> But the interpolation part (e.g, {{user.name}}) seems okay to me.
>> So, yes, I'm fine with mustache expression for interpolation and it
>> might be less confusing in this specific case.
>>
>> What do others think?
>
> Let's not forget digging up the thread where it was decided. I mean,
> there are some pro/cons mentioned there.
Here's the thread I have mentioned:
https://lists.apache.org/thread.html/56ca342df0453dce04a4a949426730d7def4d3155392d5dbb10b22b3@
--
Thanks,
Daniel Dekany
Re: Please test/review FreeMarker 2.3.28
Saturday, March 24, 2018, 2:44:17 PM, Woonsan Ko wrote:
> On Sat, Mar 24, 2018 at 3:21 AM, Daniel Dekany <ddek...@apache.org> wrote:
>> Saturday, March 24, 2018, 3:13:06 AM, Woonsan Ko wrote:
>>
>>> When I tested with freemarker-2.3.28-incubating-SNAPSHOT.jar, which I
>>> built and install it to my local maven repo from the latest "2.3"
>>> branch myself, in my applications, I haven't found any regressions.
>>> My applications are rather simpler probably than others as they simply
>>> render model objects passed from request attributes through
>>> FreeMarkerServlet.
>>> But when I tried the new features and bug fixes [1], I think I found
>>> somethings (perhaps there could be my misunderstandings):
>>>
>>> 1. The template example in
>>> https://freemarker.apache.org/builds/fm2.3.28/ref_specvar.html#ref_specvar_get_optional_template
>>>
>>> <#assign optTemp = .get_optional_template('some.ftl')>
>>> <#if optTemp.exists>
>>>
>>> But if the 'some.ftl' doesn't exist, optTemp.exists fails as it's
>>> null. So I ended up changing it to this:
>>>
>>> <#assign optTemp = .get_optional_template('some.ftl')>
>>> <#if optTemp?? && optTemp.exists>
>>
>> That's bizarre. It works for me. Also for the test suite... that
>> passes there, right? (It can't even be explained by accidentally using
>> 2.3.27, as there .get_optional_template is parsing (syntax) error.)
>
> Perhaps my build might be wrong. I did the following locally to build
> fresh and install it to my local maven repo. (Yesterday, I used my
> forked/forked GitHub branch, which could have caused the issue.)
OK, I see the problem. I haven't pushed the last merge commit in the
2.3 branch... sorry! So only the 2.3-gae branch was up to date on Git.
(The linked binaries were fine though.)
> (move to a temp folder)
> $ git clone
> https://git-wip-us.apache.org/repos/asf/incubator-freemarker.git
> $ cd incubator-freemarker/
> $ git checkout 2.3
> (edit build.properties)
> $ git log --oneline | head -n 2
> edefaa2f Merge remote-tracking branch 'origin/2.3-gae' into 2.3
> 01294537 Cleaned up more lexer/parser logic ...
> $ ant clean maven-install
> (confirm the log installing the jar and pom files to my maven repo to
> compare with deployed jar later)
>
> When I tested with this today, ${.version} printed: "version:
> 2.3.28-nightly_20180324T130919Z-incubating".
>
> Could this local build cause a problem? (I saw differences between
> "2.3" and "2.3-gae". See below. So I probably should have built
> "2.3-gae" branch?)
But should work, except if I screw up and forgot to push one of them,
like now...
> Anyway, in my testing with "2.3" build, I needed optTemp?? additionally.
>
>>> 2. Square bracket syntax through ftl directive
>>>
>>> It reads, "This directive also determines if the template uses angle
>>> bracket syntax (e.g. <#include 'foo.ftl'>) or square bracket syntax
>>> (e.g. [#include 'foo.ftl']). Simply, the syntax used for this
>>> directive will be the syntax used for the whole template, regardless
>>> of the FreeMarker configuration settings." [2]
>>>
>>> I applied it to an included .ftl template like this:
>>>
>>> [#ftl output_format="HTML"]
>>> [="Hello"]
>>> ${"Hello"}
>>>
>>> It prints: [="Hello"] Hello,
>>> not: Hello ${"Hello"}
>>
>> There are two independent settings here: tag syntax and interpolation
>> syntax. It's mere coincidence that both has "square bracket" in their
>> names. [#ftl] only sets the first. I will clarify that in the
>
> I see. When I tried this now,
>
> [#ftl output_format="HTML"]
> [#assign a=[1,2,3]]
> [#list a as i]${i}[#sep],[/#list]
> [="Hello"]
> ${"Hello"}
>
> I got: 1,2,3 [="Hello"] Hello
> Thanks for clarification!
Note that the square bracket *tag* syntax and that it can be activated
with [#ftl] exists for a very long time.
I will update the related Manual page in a minute...
>> documentation. Or, it's a warning sign that we should rather use
>> {{exp}}, as that doesn't have "square brackets" in it.
>
> Perhaps. ;-)
> I recently had a chance to look around other templating libraries
> using the mustache as I have seen people loving it.
> I didn't like the usages there in directives. For example, {{#if
> user}} {{user.name}} {{/if}}. It's hard for me complet
FreeMarker has graduated to TLP!
To quote the relevant part from the ASF Board Meeting Summary of March 21, 2018: The following resolutions were passed unanimously: A. Establish the Apache FreeMarker Project (Dániel Dékány VP) So now that this uncertainty was eliminated, we can feel much more motivated to push FM ahead. We were awarded with the additional trust associated to the "Apache" brand, so let's put code behind it that fits the modern standards, by which I mean FM3. Of course, FM2 also needs to be maintained, even receive new features. But I believe FM3 is absolutely necessary for growth, adoption in new projects. It will take a while until all the "paper work" and infrastructural changes are done (https://incubator.apache.org/guides/transferring.html). But we don't have to wait for all of that to release 2.3.28 as non-incubating, so I hope that will be done sometimes next week. -- Thanks, Daniel Dekany
Re: Willing to contribute to Apache Free Marker
code so we can figure out what should/can >>>> be improved. >>>> >>>> At the moment, I haven't decided on what I want to do in this project. >>>> Still, I'm trying to understand how can I be a help to FM, so I'm open to >>>> any suggestion. >>>> >>>> I've gone through the issue[1] created by Angelo and I would love to >>>> know the opinion of others as well. My personal preference is to go with >>>> the first solution which is to "Create a custom parser". >>>> >>>> [1] https://github.com/angelozerr/freemarker-languageserver/issues/1 >>>> >>>> Regards, >>>> >>>> >>>> *Randika Navagamuwa,* >>>> >>>> *Software Engineer,* >>>> *AdroitLogic Lanka (Pvt) Ltd.* >>>> *www.rnavagamuwa.com <http://www.rnavagamuwa.com>* >>>> <https://www.linkedin.com/in/rnavagamuwa/> [image: >>>> https://www.facebook.com/rnavagamuwa] >>>> <https://www.facebook.com/rnavagamuwa> >>>> <https://twitter.com/rnavagamuwa> [image: >>>> https://plus.google.com/+RandikaNavagamuwa/] >>>> <https://plus.google.com/+RandikaNavagamuwa/> >>>> <http://github.com/rnavagamuwa> >>>> >>>> On Sat, Mar 17, 2018 at 10:00 PM, Angelo zerr <angelo.z...@gmail.com> >>>> wrote: >>>> >>>>> Hi Randika, >>>>> >>>>> If you are interested to work on the Freemarker Language Server >>>>> https://github.com/angelozerr/freemarker-languageserver, it should be >>>>> really fantastic. >>>>> >>>>> Today I have just managed to support validation (publishDiagnostics), >>>>> but >>>>> for advanced features like completion, outline, etc we must have the >>>>> capability to have a Freemarker AST even if the content of ftl is not >>>>> valid. >>>>> >>>>> I have created an issue for that >>>>> https://github.com/angelozerr/freemarker-languageserver/issues/1 Don't >>>>> hesitate to add your comment. Thanks! >>>>> >>>>> Hope you could be interested. >>>>> >>>>> Regard's Angelo >>>>> >>>>> 2018-03-17 16:57 GMT+01:00 Daniel Dekany <ddek...@apache.org>: >>>>> >>>>> > Saturday, March 17, 2018, 1:34:11 PM, Randika Navagamuwa wrote: >>>>> > >>>>> > > Hi all, >>>>> > > >>>>> > > I'm from Sri Lanka and currently, I'm working as a Senior >>>>> > Software >>>>> > > Engineer at AdroitLogic Lanka (Pvt) Ltd [1]. During my undergraduate >>>>> > > period, I've contributed to some open source projects including >>>>> Eclipse >>>>> > Che >>>>> > > [2]. >>>>> > >>>>> > Speaking of Eclipse... we had a bit of a problem with the old Eclipse >>>>> > editor plugin (at JBoss Tools), which it sparked this new one using >>>>> > LSP4J (also used by Che AFAIK; not sure how syntax highlighting parts >>>>> > works there): https://github.com/angelozerr/lsp4e-freemarker >>>>> > >>>>> > If you are interested in that, let me know. >>>>> > >>>>> > > For some time I couldn't actively participate in any open source >>>>> > > projects and I thought of getting back to it. >>>>> > > >>>>> > > After going through some Apache projects I found Free Marker >>>>> > > really interesting. I'm interested in taking part in "*FreeMarker >>>>> Spring >>>>> > > MVC integration. >>>>> > > >>>>> > > Please let me know how to contribute to this. >>>>> > >>>>> > So first of all, glad to hear that you are interested. We need that a >>>>> > lot, especially when it comes to supporting frameworks and IDE-s. >>>>> > >>>>> > Now, there are two main development branches: >>>>> > >>>>> > - FreeMarker 2: This is the one that's actually used in production, >>>>> > for 15 years or so. Be prepared for remnants of 2000-s cowboy >>>>> > coding <-;, and complications and
Re: Please test/review FreeMarker 2.3.28
Friday, March 23, 2018, 3:33:39 AM, Woonsan Ko wrote: > Great to see the real release without "incubating" mark soon! In theory it was decided 2 days ago, but I saw nothing about the board meeting so far. I guess they are overburdened with the May elections and all that. > Also ! I've just read the Change log and everything is awesome! > I'll just try out the snapshot binary tomorrow in our applications to > see if there's any regression just in case. Great, thanks! > Cheers, > > Woonsan > > > On Tue, Mar 20, 2018 at 6:39 PM, Daniel Dekany <ddek...@apache.org> wrote: >> Before we start a VOTE on releasing 2.3.28, it would be good if more >> of you can test it, or otherwise review the upcoming 2.3.28! The main >> point in this phase is to catch technical issues. >> >> If you intend to help, but won't have time for it in the coming few >> days, please indicate that, so that I know that I should wait! >> >> Change log (so far, but I don't plan to add more): >> https://freemarker.apache.org/builds/fm2.3.28/versions_2_3_28.html >> >> Binary release artifacts: >> https://dist.apache.org/repos/dist/dev/incubator/freemarker/engine/2.3.28-incubating-SNAPSHOT/binaries/ >> >> Source release artifacts: >> https://dist.apache.org/repos/dist/dev/incubator/freemarker/engine/2.3.28-incubating-SNAPSHOT/source/ >> >> The Maven artifacts are available from the Apache snaphsot repository: >> >> >> apache-snapshot-repository >> https://repository.apache.org/content/repositories/snapshots/ >> false >> true >> >> >> under the coordinates: >> >> org.freemarker >> freemarker >> 2.3.28-incubating-SNAPSHOT >> >> and for the Google App Engine compatible (GAE) version: >> >> org.freemarker >> freemarker-gae >> 2.3.28-incubating-SNAPSHOT >> >> The ASF Board will decide tomorrow (21th) if FreeMarker can graduate. >> If everything goes well, this release won't have "incubating" in its >> version number. This will be the first such release since mid 2015 >> (2.3.23). >> >> -- >> Thanks, >> Daniel Dekany >> > -- Thanks, Daniel Dekany
Please test/review FreeMarker 2.3.28
Before we start a VOTE on releasing 2.3.28, it would be good if more of you can test it, or otherwise review the upcoming 2.3.28! The main point in this phase is to catch technical issues. If you intend to help, but won't have time for it in the coming few days, please indicate that, so that I know that I should wait! Change log (so far, but I don't plan to add more): https://freemarker.apache.org/builds/fm2.3.28/versions_2_3_28.html Binary release artifacts: https://dist.apache.org/repos/dist/dev/incubator/freemarker/engine/2.3.28-incubating-SNAPSHOT/binaries/ Source release artifacts: https://dist.apache.org/repos/dist/dev/incubator/freemarker/engine/2.3.28-incubating-SNAPSHOT/source/ The Maven artifacts are available from the Apache snaphsot repository: apache-snapshot-repository https://repository.apache.org/content/repositories/snapshots/ false true under the coordinates: org.freemarker freemarker 2.3.28-incubating-SNAPSHOT and for the Google App Engine compatible (GAE) version: org.freemarker freemarker-gae 2.3.28-incubating-SNAPSHOT The ASF Board will decide tomorrow (21th) if FreeMarker can graduate. If everything goes well, this release won't have "incubating" in its version number. This will be the first such release since mid 2015 (2.3.23). -- Thanks, Daniel Dekany
Re: Willing to contribute to Apache Free Marker
Saturday, March 17, 2018, 7:07:17 PM, Randika Navagamuwa wrote: > Hi Dianel and Angelo, > > Thanks for the information. Yes, Eclipse Che uses LSP4J and I'm interested > in that, but I'm more interested in supporting frameworks and IDE-s. I've > gone through the provided link regarding FM3 but still, there are lot > things which I don't understand properly. Feel free to ask if you are stuck. > You have mentioned that Woonsan Ko has already implemented a lot of > Spring integration. I would love to take a look at his code so we > can figure out what should/can be improved. It's the freemarker-spring module in the FreeMarker 3 branch. > At the moment, I haven't decided on what I want to do in this project. > Still, I'm trying to understand how can I be a help to FM, so I'm open to > any suggestion. > > I've gone through the issue[1] created by Angelo and I would love to know > the opinion of others as well. My personal preference is to go with the > first solution which is to "Create a custom parser". > > [1] https://github.com/angelozerr/freemarker-languageserver/issues/1 > > Regards, > > > *Randika Navagamuwa,* > > *Software Engineer,* > *AdroitLogic Lanka (Pvt) Ltd.* > *www.rnavagamuwa.com <http://www.rnavagamuwa.com>* > <https://www.linkedin.com/in/rnavagamuwa/> [image: > https://www.facebook.com/rnavagamuwa] > <https://www.facebook.com/rnavagamuwa> > <https://twitter.com/rnavagamuwa> [image: > https://plus.google.com/+RandikaNavagamuwa/] > <https://plus.google.com/+RandikaNavagamuwa/> > <http://github.com/rnavagamuwa> > > On Sat, Mar 17, 2018 at 10:00 PM, Angelo zerr <angelo.z...@gmail.com> wrote: > >> Hi Randika, >> >> If you are interested to work on the Freemarker Language Server >> https://github.com/angelozerr/freemarker-languageserver, it should be >> really fantastic. >> >> Today I have just managed to support validation (publishDiagnostics), but >> for advanced features like completion, outline, etc we must have the >> capability to have a Freemarker AST even if the content of ftl is not >> valid. >> >> I have created an issue for that >> https://github.com/angelozerr/freemarker-languageserver/issues/1 Don't >> hesitate to add your comment. Thanks! >> >> Hope you could be interested. >> >> Regard's Angelo >> >> 2018-03-17 16:57 GMT+01:00 Daniel Dekany <ddek...@apache.org>: >> >> > Saturday, March 17, 2018, 1:34:11 PM, Randika Navagamuwa wrote: >> > >> > > Hi all, >> > > >> > > I'm from Sri Lanka and currently, I'm working as a Senior >> > Software >> > > Engineer at AdroitLogic Lanka (Pvt) Ltd [1]. During my undergraduate >> > > period, I've contributed to some open source projects including Eclipse >> > Che >> > > [2]. >> > >> > Speaking of Eclipse... we had a bit of a problem with the old Eclipse >> > editor plugin (at JBoss Tools), which it sparked this new one using >> > LSP4J (also used by Che AFAIK; not sure how syntax highlighting parts >> > works there): https://github.com/angelozerr/lsp4e-freemarker >> > >> > If you are interested in that, let me know. >> > >> > > For some time I couldn't actively participate in any open source >> > > projects and I thought of getting back to it. >> > > >> > > After going through some Apache projects I found Free Marker >> > > really interesting. I'm interested in taking part in "*FreeMarker >> Spring >> > > MVC integration. >> > > >> > > Please let me know how to contribute to this. >> > >> > So first of all, glad to hear that you are interested. We need that a >> > lot, especially when it comes to supporting frameworks and IDE-s. >> > >> > Now, there are two main development branches: >> > >> > - FreeMarker 2: This is the one that's actually used in production, >> > for 15 years or so. Be prepared for remnants of 2000-s cowboy >> > coding <-;, and complications and restrictions for keeping backward >> > compatibility. >> > >> > The Spring support was made very long ago by someone who, I don't >> > remember ever talked to the FM developers (I was already around in >> > that times). My brief interactions with it has shown that it's not >> > very good, and it's quite abandoned. Now, the main problem is that >> > it's at Spring, not here. So I'm not sure if writing patches to them >> >
Re: Moving JBoss FreeMarker IDE (Eclipse plugin) to the ASF?
Saturday, March 17, 2018, 12:43:35 PM, Angelo zerr wrote: > 2018-03-17 8:29 GMT+01:00 Daniel Dekany <ddek...@apache.org>: > >> Saturday, March 17, 2018, 2:58:12 AM, Angelo zerr wrote: >> >> > Hi all, >> > >> > If you wish to install lsp4e freemarker, I suggest you that you read >> > https://github.com/angelozerr/lsp4e-freemarker#installation >> > >> > There is now an update site that I have tested with Eclipse Photon M6 (I >> > suggest you that you use it). >> >> Installation on Photon M6 indicates less problems than on Eclipse >> Oxygen (it has no problem with the jface.text dependency, but it can't >> install the requested version of the "Generic and Extensible Text >> Editor" - see at the bottom [*]), but the plugin still doesn't work >> after installation: >> > > It's not a problem. Please don't install Eclipse BlueSky, only > lsp4e-freemarker. I have added the HTML TextMate grammar in the > lsp4e-grammar to have HTML syntax coloration without BlueSky. > i > I have created an issue with BlueSky > https://github.com/mickaelistria/eclipse-bluesky/issues/63 > > >> >> - If I open test.ftl, then Eclipse shows "Initialize Language Server >> for test.ftl" in the lower right corner, with the progress bar >> animation, and that goes on forever. Thus there's no LSP4E related >> functionality in the editor. >> >> - Syntax highlighting is not happening (text color is just black >> everywhere). "text.html.ftl" is present in >> Windows/Preferences/TextMate/Grammar. It even works for in the >> Preview text area there, though if I click away from it to another >> grammar, and back, then it won't be colored anymore until I restart >> Eclipse. >> > > It seems that it's a problem with content type. If you install only > lsp4e-freemarker in a new fresh Eclipse Photon M6, it should work ( I have > tested on Windows). I have started by only installing lsp4e-freemarker, yet the problems were already there. > I think it should be better to discuss about this problem in > https://github.com/angelozerr/lsp4e-freemarker/issues to avoid disturbing > Freemarker mailing list, no? OK, I will create an issue. >> I have tried both installing lsp4e-freemarker and BlueSky first, but >> it made no difference. (I have also tried installing from the update >> site specified, instead of from the local build.) >> > > If you install only lsp4e-freemarker in a new fresh Eclipse Photon M6, is > it working? > >> >> Couple of questions: >> >> - What's the future of BlueSky? Development seems to be slow or even >> stalled, while the plugin seems to be in early stage. >> > > I suggest you that you post your question at > https://github.com/mickaelistria/eclipse-bluesky/issues > >> >> - Any hope to do additional coloring over what TextMate does when >> AST-related information arrives to LSP4E? (Will be mostly useful in >> FM3.) >> > > Yes it's possible to do that like JDT does but it means that Freemarker > Language Server returns Freemarker AST even if AST is broken (tolerant > parser).I'm afraid that we can use the FMParser which is too strict. > > I have created an issue for that at > https://github.com/angelozerr/freemarker-languageserver/issues/1 with my > plan. If we can work together about thi stopic, it should really cool, but > IMHO, I think we should simplify the Freemarker AST because tolerant parser > is hard to implement and if we can use LSP4j structure directly, it should > be better. My idea is to implement this tolerant parser like VSCode with > HTML Language server. > > But if you think it's possible to use FMParser, I'm totally aware. I think > we should continue this discussion at > https://github.com/angelozerr/freemarker-languageserver/issues/1 > > >> c >> *: The "Generic and Extensible Text Editor" installation issue on Photon >> M6: >> >> Your original request has been modified. >> "Generic and Extensible Text Editor" is already installed, so an >> update will be performed instead. >> Cannot complete the install because of a conflicting dependency. >> Software being installed: Generic and Extensible Text Editor >> 1.1.0.v20180316-0841 (org.eclipse.ui.genericeditor 1.1.0.v20180316-0841) >> Software currently installed: Eclipse IDE for Java EE Developers >> 4.8.0.20180315-1215 (epp.package.jee 4.8.0.20180315-1215) >> Only one of the following can be installed at once: >> Generic and Extensible Text Editor 1.1.0.v20171212-0
Re: Willing to contribute to Apache Free Marker
Saturday, March 17, 2018, 1:34:11 PM, Randika Navagamuwa wrote: > Hi all, > > I'm from Sri Lanka and currently, I'm working as a Senior Software > Engineer at AdroitLogic Lanka (Pvt) Ltd [1]. During my undergraduate > period, I've contributed to some open source projects including Eclipse Che > [2]. Speaking of Eclipse... we had a bit of a problem with the old Eclipse editor plugin (at JBoss Tools), which it sparked this new one using LSP4J (also used by Che AFAIK; not sure how syntax highlighting parts works there): https://github.com/angelozerr/lsp4e-freemarker If you are interested in that, let me know. > For some time I couldn't actively participate in any open source > projects and I thought of getting back to it. > > After going through some Apache projects I found Free Marker > really interesting. I'm interested in taking part in "*FreeMarker Spring > MVC integration. > > Please let me know how to contribute to this. So first of all, glad to hear that you are interested. We need that a lot, especially when it comes to supporting frameworks and IDE-s. Now, there are two main development branches: - FreeMarker 2: This is the one that's actually used in production, for 15 years or so. Be prepared for remnants of 2000-s cowboy coding <-;, and complications and restrictions for keeping backward compatibility. The Spring support was made very long ago by someone who, I don't remember ever talked to the FM developers (I was already around in that times). My brief interactions with it has shown that it's not very good, and it's quite abandoned. Now, the main problem is that it's at Spring, not here. So I'm not sure if writing patches to them is the better, or starting over here. Though I'm certain that the last is much more fun, and you have more freedom to figure out the best approach to bring FM2 features and Spring together. (OTOH that will lead to FM support being removed from Spring, which is quite a loss in visibility... but we go for what's best technically.) If you need new FM features during that (and certainly you will, if you are creative about it), I can do that if you find the FM2 internals scary (which would be understandable). - FreeMarker 3: You can read about it here: https://cwiki.apache.org/confluence/display/FREEMARKER/FreeMarker+3 So it's much more rewarding to work with, except that nobody uses it yet... Furthermore, Woonsan Ko (a PPMC member here) has implemented a lot of the Spring integration already, as you will find. I know there are parts missing, even trickier parts (like i10n messages that are outputFormat aware). Not sure if he wants them for himself (after all, those are the fun parts), or if he needs help elsewhere. Woonsan? Also, generating e-mail in Spring seems to become more and more important compared to generating web pages. Just in case you are interested in polishing that application as well. But really, find the a part that you think you will enjoy. > Someone who know both well should keep an eye on this, > improving it where necessary.*" which I found here [3] under "*Improve > framework integration*". > > [1] https://www.adroitlogic.com/ > [2] https://www.eclipse.org/che/ > [3] https://freemarker.apache.org/contribute.html > > Regards, > > > *Randika Navagamuwa,* > > *Senior Software Engineer,* > *AdroitLogic Lanka (Pvt) Ltd.* > *www.rnavagamuwa.com <http://www.rnavagamuwa.com>* > <https://www.linkedin.com/in/rnavagamuwa/> [image: > https://www.facebook.com/rnavagamuwa] > <https://www.facebook.com/rnavagamuwa> > <https://twitter.com/rnavagamuwa> [image: > https://plus.google.com/+RandikaNavagamuwa/] > <https://plus.google.com/+RandikaNavagamuwa/> > <http://github.com/rnavagamuwa> -- Thanks, Daniel Dekany
Re: LSP for FreeMarker Was: Moving JBoss FreeMarker IDE (Eclipse plugin) to the ASF?
Friday, March 16, 2018, 11:12:40 AM, Angelo zerr wrote:
>> I couldn't actually try it yet, as my lsp4e-freemarker build fails
>
> The installation is a little complex, I think the better thing is that I
> provide an update site. Please let me a little time for that.
>
> Please note too that if you install
> https://github.com/mickaelistria/eclipse-bluesky you will benefit with
> advanced completion with HTML, CSS, JS too with the ftl.
>
> I will add a demo in my github for that.
Thanks, great!
BTW, I have retweeted you on https://twitter.com/freemarker. Hope you
don't mind.
> Regard's Angelo
>
> 2018-03-16 11:06 GMT+01:00 Daniel Dekany <ddek...@apache.org>:
>
>> Friday, March 16, 2018, 9:21:49 AM, Angelo zerr wrote:
>>
>> > Hi Daniel,
>> >
>> > Here the project https://github.com/angelozerr/lsp4e-freemarker which is
>> > based on the basic Freemarker Language Server
>> > https://github.com/angelozerr/freemarker-languageserver (which could be
>> > consumed too in VSCode) which supports only validation for the moment.
>> >
>> > Hope you will like it.
>>
>> I couldn't actually try it yet, as my lsp4e-freemarker build fails
>> with:
>>
>> Could not resolve target platform specification artifact
>> org.eclipse.lsp4e-freemarker:target-platform:target:0.1.0-SNAPSHOT
>>
>> What's supposed to generate and install that artifact? (Surely I have
>> near 0 investment in Eclipse plugin development; it seems to be its
>> own little universe with Tycho and all.)
>>
>> I guess to generate an "update site" (p2 repo or whatever the correct
>> term is) a Maven module with eclipse-repository
>> will have to be added.
>>
>> Otherwise so far so good, but of course the question will be if how
>> flexible this setup is. Especially the syntax highlighting can be
>> tricky, as FreeMarker templates my use various syntax permutations
>> (<#...> VS [#...], ${...} VS [=...]), then the static text part can be
>> HTLM or XML or something else. So I wonder how that can be handled.
>> Not to mention syntax auto-detection from the [#ftl] header. In any
>> case, developing a TextMate syntax for a few permutations might be
>> useful, as TextMate and VSCode users can use it as well.
>>
>> > Regard's Angelo
>> >
>> > 2018-03-15 22:00 GMT+01:00 Daniel Dekany <ddek...@apache.org>:
>> >
>> >> Thursday, March 15, 2018, 1:58:31 PM, Angelo zerr wrote:
>> >>
>> >> > Ok thanks Daniel for your answer.
>> >> >
>> >> > I will try to create a github project with my POC which provides:
>> >> >
>> >> > * syntax coloration for Freemarker by using TextMate
>> >> > * validation by using a basic Freemarker Language Server (based on
>> >> lsp4j)
>> >> > which should work with Eclipse, VSCode, etc
>> >>
>> >> Sounds like a great start!
>> >>
>> >> > 2018-03-14 22:34 GMT+01:00 Daniel Dekany <ddek...@apache.org>:
>> >> >
>> >> >> Wednesday, March 14, 2018, 4:41:36 PM, Angelo zerr wrote:
>> >> >>
>> >> >> > Hi all,
>> >> >> >
>> >> >> > Do you want that I create a new eclipse plugin with Freemarker
>> based
>> >> on
>> >> >> tm4e
>> >> >> >
>> >> >> > Here the result with syntax coloration:
>> >> >>
>> >> >> Seems to me that the image was removed by the mailing list. But
>> >> >> otherwise of course it's good if we have it started, however I can't
>> >> >> promise that it will be picked up and continued by someone. Surely I
>> >> >> will check it out though.
>> >> >>
>> >> >> > Regard's Angelo
>> >> >> >
>> >> >> >
>> >> >> > 2018-03-14 12:20 GMT+01:00 Jacopo Cappellato <
>> >> >> jacopo.cappell...@gmail.com>:
>> >> >> > On Tue, Mar 13, 2018 at 4:47 PM, Daniel Dekany <ddek...@apache.org
>> >
>> >> >> wrote:
>> >> >> >
>> >> >> >> [...]
>> >> >> >> It's our turn. I'm really just waiting to hear if the other PPMC
>> >> >> >> members think that this should be attempted (like, if we want that
>> >> >> >> code at all), then I will ask ASF Legal.
>> >> >> >>
>> >> >> >>
>> >> >> > I don't feel much comfortable in commenting on license/legal stuff
>> >> >> because
>> >> >> > of my lack of confidence on the subject
>> >> >> > However I think that we can start by stating our interest in
>> accepting
>> >> >> the
>> >> >> > codebase donation from RedHat/JBoss.
>> >> >> > Then we could figure out the exact steps that need to be followed
>> by
>> >> them
>> >> >> > and by us (trying to minimize the workload n their part as much as
>> >> >> > possible) and then we will decide if it is a feasible plan.
>> >> >> >
>> >> >> > Jacopo
>> >> >> >
>> >> >>
>> >> >> --
>> >> >> Thanks,
>> >> >> Daniel Dekany
>> >> >>
>> >> >>
>> >>
>> >> --
>> >> Thanks,
>> >> Daniel Dekany
>> >>
>> >>
>>
>> --
>> Thanks,
>> Daniel Dekany
>>
>>
--
Thanks,
Daniel Dekany
Re: LSP for FreeMarker Was: Moving JBoss FreeMarker IDE (Eclipse plugin) to the ASF?
Friday, March 16, 2018, 9:21:49 AM, Angelo zerr wrote:
> Hi Daniel,
>
> Here the project https://github.com/angelozerr/lsp4e-freemarker which is
> based on the basic Freemarker Language Server
> https://github.com/angelozerr/freemarker-languageserver (which could be
> consumed too in VSCode) which supports only validation for the moment.
>
> Hope you will like it.
I couldn't actually try it yet, as my lsp4e-freemarker build fails
with:
Could not resolve target platform specification artifact
org.eclipse.lsp4e-freemarker:target-platform:target:0.1.0-SNAPSHOT
What's supposed to generate and install that artifact? (Surely I have
near 0 investment in Eclipse plugin development; it seems to be its
own little universe with Tycho and all.)
I guess to generate an "update site" (p2 repo or whatever the correct
term is) a Maven module with eclipse-repository
will have to be added.
Otherwise so far so good, but of course the question will be if how
flexible this setup is. Especially the syntax highlighting can be
tricky, as FreeMarker templates my use various syntax permutations
(<#...> VS [#...], ${...} VS [=...]), then the static text part can be
HTLM or XML or something else. So I wonder how that can be handled.
Not to mention syntax auto-detection from the [#ftl] header. In any
case, developing a TextMate syntax for a few permutations might be
useful, as TextMate and VSCode users can use it as well.
> Regard's Angelo
>
> 2018-03-15 22:00 GMT+01:00 Daniel Dekany <ddek...@apache.org>:
>
>> Thursday, March 15, 2018, 1:58:31 PM, Angelo zerr wrote:
>>
>> > Ok thanks Daniel for your answer.
>> >
>> > I will try to create a github project with my POC which provides:
>> >
>> > * syntax coloration for Freemarker by using TextMate
>> > * validation by using a basic Freemarker Language Server (based on
>> lsp4j)
>> > which should work with Eclipse, VSCode, etc
>>
>> Sounds like a great start!
>>
>> > 2018-03-14 22:34 GMT+01:00 Daniel Dekany <ddek...@apache.org>:
>> >
>> >> Wednesday, March 14, 2018, 4:41:36 PM, Angelo zerr wrote:
>> >>
>> >> > Hi all,
>> >> >
>> >> > Do you want that I create a new eclipse plugin with Freemarker based
>> on
>> >> tm4e
>> >> >
>> >> > Here the result with syntax coloration:
>> >>
>> >> Seems to me that the image was removed by the mailing list. But
>> >> otherwise of course it's good if we have it started, however I can't
>> >> promise that it will be picked up and continued by someone. Surely I
>> >> will check it out though.
>> >>
>> >> > Regard's Angelo
>> >> >
>> >> >
>> >> > 2018-03-14 12:20 GMT+01:00 Jacopo Cappellato <
>> >> jacopo.cappell...@gmail.com>:
>> >> > On Tue, Mar 13, 2018 at 4:47 PM, Daniel Dekany <ddek...@apache.org>
>> >> wrote:
>> >> >
>> >> >> [...]
>> >> >> It's our turn. I'm really just waiting to hear if the other PPMC
>> >> >> members think that this should be attempted (like, if we want that
>> >> >> code at all), then I will ask ASF Legal.
>> >> >>
>> >> >>
>> >> > I don't feel much comfortable in commenting on license/legal stuff
>> >> because
>> >> > of my lack of confidence on the subject
>> >> > However I think that we can start by stating our interest in accepting
>> >> the
>> >> > codebase donation from RedHat/JBoss.
>> >> > Then we could figure out the exact steps that need to be followed by
>> them
>> >> > and by us (trying to minimize the workload n their part as much as
>> >> > possible) and then we will decide if it is a feasible plan.
>> >> >
>> >> > Jacopo
>> >> >
>> >>
>> >> --
>> >> Thanks,
>> >> Daniel Dekany
>> >>
>> >>
>>
>> --
>> Thanks,
>> Daniel Dekany
>>
>>
--
Thanks,
Daniel Dekany
Re: Moving JBoss FreeMarker IDE (Eclipse plugin) to the ASF?
Thursday, March 15, 2018, 1:58:31 PM, Angelo zerr wrote: > Ok thanks Daniel for your answer. > > I will try to create a github project with my POC which provides: > > * syntax coloration for Freemarker by using TextMate > * validation by using a basic Freemarker Language Server (based on lsp4j) > which should work with Eclipse, VSCode, etc Sounds like a great start! > 2018-03-14 22:34 GMT+01:00 Daniel Dekany <ddek...@apache.org>: > >> Wednesday, March 14, 2018, 4:41:36 PM, Angelo zerr wrote: >> >> > Hi all, >> > >> > Do you want that I create a new eclipse plugin with Freemarker based on >> tm4e >> > >> > Here the result with syntax coloration: >> >> Seems to me that the image was removed by the mailing list. But >> otherwise of course it's good if we have it started, however I can't >> promise that it will be picked up and continued by someone. Surely I >> will check it out though. >> >> > Regard's Angelo >> > >> > >> > 2018-03-14 12:20 GMT+01:00 Jacopo Cappellato < >> jacopo.cappell...@gmail.com>: >> > On Tue, Mar 13, 2018 at 4:47 PM, Daniel Dekany <ddek...@apache.org> >> wrote: >> > >> >> [...] >> >> It's our turn. I'm really just waiting to hear if the other PPMC >> >> members think that this should be attempted (like, if we want that >> >> code at all), then I will ask ASF Legal. >> >> >> >> >> > I don't feel much comfortable in commenting on license/legal stuff >> because >> > of my lack of confidence on the subject >> > However I think that we can start by stating our interest in accepting >> the >> > codebase donation from RedHat/JBoss. >> > Then we could figure out the exact steps that need to be followed by them >> > and by us (trying to minimize the workload n their part as much as >> > possible) and then we will decide if it is a feasible plan. >> > >> > Jacopo >> > >> >> -- >> Thanks, >> Daniel Dekany >> >> -- Thanks, Daniel Dekany
Re: Moving JBoss FreeMarker IDE (Eclipse plugin) to the ASF?
Thursday, March 15, 2018, 5:31:31 PM, Jaime Garza wrote: > Isn’t the license for tm4e eclipse license? It is not apache. Is that an > issue? That's not a problem. A binary under EPL 1.0, or even EPL 2.0, can be packaged with an Apache product. See https://www.apache.org/legal/resolved.html#category-b. Furthermore in our case it's only part of the binary distribution, not the source distribution (as it's only an external dependency there, together with unavoidable EPL licensed things like Tycho). >> On Mar 15, 2018, at 5:58 AM, Angelo zerr <angelo.z...@gmail.com> wrote: >> >> Ok thanks Daniel for your answer. >> >> I will try to create a github project with my POC which provides: >> >> * syntax coloration for Freemarker by using TextMate >> * validation by using a basic Freemarker Language Server (based on lsp4j) >> which should work with Eclipse, VSCode, etc >> >> 2018-03-14 22:34 GMT+01:00 Daniel Dekany <ddek...@apache.org>: >> >>> Wednesday, March 14, 2018, 4:41:36 PM, Angelo zerr wrote: >>> >>>> Hi all, >>>> >>>> Do you want that I create a new eclipse plugin with Freemarker based on >>> tm4e >>>> >>>> Here the result with syntax coloration: >>> >>> Seems to me that the image was removed by the mailing list. But >>> otherwise of course it's good if we have it started, however I can't >>> promise that it will be picked up and continued by someone. Surely I >>> will check it out though. >>> >>>> Regard's Angelo >>>> >>>> >>>> 2018-03-14 12:20 GMT+01:00 Jacopo Cappellato < >>> jacopo.cappell...@gmail.com>: >>>> On Tue, Mar 13, 2018 at 4:47 PM, Daniel Dekany <ddek...@apache.org> >>> wrote: >>>> >>>>> [...] >>>>> It's our turn. I'm really just waiting to hear if the other PPMC >>>>> members think that this should be attempted (like, if we want that >>>>> code at all), then I will ask ASF Legal. >>>>> >>>>> >>>> I don't feel much comfortable in commenting on license/legal stuff >>> because >>>> of my lack of confidence on the subject >>>> However I think that we can start by stating our interest in accepting >>> the >>>> codebase donation from RedHat/JBoss. >>>> Then we could figure out the exact steps that need to be followed by them >>>> and by us (trying to minimize the workload n their part as much as >>>> possible) and then we will decide if it is a feasible plan. >>>> >>>> Jacopo >>>> >>> >>> -- >>> Thanks, >>> Daniel Dekany >>> >>> > > -- Thanks, Daniel Dekany
Re: Moving JBoss FreeMarker IDE (Eclipse plugin) to the ASF?
Wednesday, March 14, 2018, 12:20:26 PM, Jacopo Cappellato wrote: > On Tue, Mar 13, 2018 at 4:47 PM, Daniel Dekany <ddek...@apache.org> wrote: > >> [...] >> It's our turn. I'm really just waiting to hear if the other PPMC >> members think that this should be attempted (like, if we want that >> code at all), then I will ask ASF Legal. >> >> > I don't feel much comfortable in commenting on license/legal stuff because > of my lack of confidence on the subject :-( > However I think that we can start by stating our interest in accepting the > codebase donation from RedHat/JBoss. It was already stated, near the end of the thread at the JBoss Tools list. OK, it was just me stating it, but that's enough for them. > Then we could figure out the exact steps that need to be followed by them > and by us (trying to minimize the workload n their part as much as > possible) and then we will decide if it is a feasible plan. So we are at that phase right now. I really just want to know if the PPMC likes the idea of bringing yet another related product over. If so, we should ask ASF Legal, right? > Jacopo -- Thanks, Daniel Dekany
Re: Moving JBoss FreeMarker IDE (Eclipse plugin) to the ASF?
Tuesday, March 13, 2018, 5:26:10 PM, Jacques Le Roux wrote: [snip] >>>>> However, nothing in your email indicates that RedHat has any >>>>> interest in donating the tool to the ASF. >>>> Nick Boldt was positive about the idea, and he has CC-ed to some >>>> others as well (some are legal guys I presume), and also it was on >>>> jbosstools-dev (a public list), and so far there was no negative >>>> reactions, except that they don't want much work with this. So, if >>>> this is to progress anywhere, I believe first we have to tell them >>>> what exactly they had to do, and then they can make up their minds. >>>> Actually, they are waiting for me to tell if ASF wants this at all, >>>> and how. >>> Do you mean the 'individual contributors' by them? >> I mean the guys working at RedHat / JBoss Tools. > Then it should be easier than I thought, they are still all > employees of RedHat? I guess not but the number of people having > left RedHat must be less than 8 and so it could be easier than > expected No, I just said above that by "they" in "they are waiting" I meant the JBoss Tools developers (they are RedHat employees). Nothing has changed since I have simply counted the unique e-mail addresses from the commits and reported the numbers here. -- Thanks, Daniel Dekany
Re: Moving JBoss FreeMarker IDE (Eclipse plugin) to the ASF?
Tuesday, March 13, 2018, 2:44:14 PM, Woonsan Ko wrote:
> On Sun, Mar 11, 2018 at 3:34 PM, Daniel Dekany <ddek...@apache.org> wrote:
>> Sunday, March 11, 2018, 5:22:39 PM, Ralph Goers wrote:
>>
>>> If RedHat took ownership of the tool then they should be able to
>>> take care of changing the license and sending an SGA to the ASF.
>>
>> In the case of FreeMarker Online *we* have changed the headers after
>> the PR from Kenshoo (the contributor) was merged. But in the case of
>> FreeMarker IDE it's much less obvious (to me at least) if they own the
>> thing fully ("Red Hat Middleware, LLC, and individual contributors"),
>> so better push that step on them? Is that what you mean?
> I'm not a lawyer, but whether Red Hat owns fully or partially, if they
> don't agree, I don't think we can simply move it to ASF.
They had no objection. But they can't tell if they are willing to do
the transfer until we tell them what exactly that involves. The less
work it is for them, the more likely it is that they will be nice and
do the thing, instead of just saying "well, fork it, the license
allows that" (which is correct, only then it can't be done at the ASF,
or so I assume so at least).
>>> However, nothing in your email indicates that RedHat has any
>>> interest in donating the tool to the ASF.
>>
>> Nick Boldt was positive about the idea, and he has CC-ed to some
>> others as well (some are legal guys I presume), and also it was on
>> jbosstools-dev (a public list), and so far there was no negative
>> reactions, except that they don't want much work with this. So, if
>> this is to progress anywhere, I believe first we have to tell them
>> what exactly they had to do, and then they can make up their minds.
>> Actually, they are waiting for me to tell if ASF wants this at all,
>> and how.
> Do you mean the 'individual contributors' by them?
I mean the guys working at RedHat / JBoss Tools.
> I'm afraid that ASF cannot give a good direction to them as the
> 'owner's should decide what to do themselves first. We can just say
> we're willing to host the project if the 'owner's willing to do
> donate though.
It's our turn. I'm really just waiting to hear if the other PPMC
members think that this should be attempted (like, if we want that
code at all), then I will ask ASF Legal.
> Regards,
>
> Woonsan
>
>>
>>> Short of that your only real option is to fork it to GitHub. You
>>> would have to leave the existing code as LGPL but anything new you
>>> add could use any license you want.
>>
>> That will happen if it can't come here.
>>
>>> Another option would be to look at the functionality of the tool and
>>> create something similar without using any of the code. Of course,
>>> that is a lot more work.
>>
>> Yeah, but I'm afraid that's unlikely to happen... Or, anyone wants to
>> write nice fresh and modern Eclipse plugin, certainly based on the
>> Eclipse LSP and TextMate syntax highlight plugins? If someone says
>> that he will reach a release within a few months, then users can just
>> survive on my personal fork until that...
>>
>>> Ralph
>>>
>>>> On Mar 9, 2018, at 11:03 AM, Jacques Le Roux
>>>> <jacques.le.r...@les7arts.com> wrote:
>>>>
>>>> Le 09/03/2018 à 16:59, Daniel Dekany a écrit :
>>>>> I was hasty here... as some people use multiple e-mail addresses, it's
>>>>> actually "only" 19 contributors, out of which 11 is/was at RedHat.
>>>> So it's only 8 persons to reach since RedHat seems OK. That sounds doable
>>>> :)
>>>>
>>>> Jacques
>>
>> --
>> Thanks,
>> Daniel Dekany
>>
>
--
Thanks,
Daniel Dekany
Re: Proposal for FREEMARKER-84: More flexible handlig of missing templates
Over .get_optional_template(name[, options]),
(https://freemarker.apache.org/builds/fm2.3.28/ref_specvar.html#ref_specvar_get_optional_template)
I have also added:
- .caller_template_name (https://issues.apache.org/jira/browse/FREEMARKER-83)
https://freemarker.apache.org/builds/fm2.3.28/ref_specvar.html#ref_specvar_caller_template_name
- ?absolute_template_name (you will soon see the connection...)
https://freemarker.apache.org/builds/fm2.3.28/ref_builtins_expert.html#ref_builtin_absolute_template_name
In
https://freemarker.apache.org/builds/fm2.3.28/ref_builtins_expert.html#ref_builtin_absolute_template_name
there's an example where all three are used together:
<#--
<@smileyInclude name /> behaves like <#include name>, but prints a "(:"
before the
template, or prints "):" instead if the template is missing.
Note that just like with #include, if name is relative, it's resolved based
on the
directory of the caller template, not of the template that defines this
macro. As
.get_optional_template resolves relative names based on the current
template, we
had to convert the name to an absolute name based on the caller template
before
passing it to it.
-->
<#macro smileyInclude name>
<#local t = .get_optional_template(
name?absolute_template_name(.caller_template_name))>
<#if t.exists>
(:
<@t.include />
<#else>
):
Any opinions?
Wednesday, February 28, 2018, 8:57:06 PM, Daniel Dekany wrote:
> .get_optional_template(name[, options]) now implemented in the 2.3-gae
> and 2.3 branches. Testing/feedback is welcome!
>
> See commit:
> https://github.com/apache/incubator-freemarker/commit/51c2476621809d8f4183f23e894be0106cabe810
>
> You can find some examples in the tests:
> https://github.com/apache/incubator-freemarker/blob/2.3-gae/src/test/java/freemarker/core/GetOptionalTemplateTest.java
>
>
> Sunday, February 11, 2018, 10:02:30 PM, Daniel Dekany wrote:
>
>> See the RFE here:
>> https://issues.apache.org/jira/browse/FREEMARKER-84
>>
>> As you see, the first consensus was introducing `.last_include_found`,
>> but it has two problems:
>>
>> * Sometimes it happens that if, and only if the template exists then
>> you want to do (usually print) something *before* it. Problem is, by
>> the time you know that from `.last_include_found`, it's too late, as
>> the template was already processed.
>>
>> * Like many global state variables in general, this can lead to some
>> confusing edge cases and hard-to-follow code. Like, if `#include`
>> throws an exception, which is then handled by the user with
>> `#attempt`/`#recover`, then `.last_include_found` may or may not be
>> updated, as perhaps we haven't yet reached the point where it can be
>> told if the template exists. (Consider an expression evaluation
>> error in the `#include` parameter, or an I/O error due to which we
>> can't access the template directory). Also there are some public
>> `include` methods in the `Environment` API, but they can't set this
>> variable, as they return a `Template`, and the variable must be set
>> after the `Template` was processed, unless the template was missing.
>> (If you can't figure out why it must be done that way, that proves
>> again how tricky this is... think about includes inside includes.)
>>
>> So, I propose the solution below. Maybe somewhat difficult to grasp
>> first, but it meant to be used rarely, and mostly by "experts"...
>> Let's hope SO and examples in the Manual will help people though. (-;
>>
>> Introduce a new special variable (see
>> https://freemarker.apache.org/docs/ref_specvar.html) called
>> "get_optional_template", which is a TemplateMethodModelEx with these
>> parameters:
>>
>> 1. template name (maybe a relative path, resolved as #include/#import
>> does it) 2. A hash that can have the following keys: "parse",
>> "encoding" (similarly to
>> https://freemarker.apache.org/docs/ref_directive_include.html#ref.directive.include).
>>
>> Example method call (the `.` prefix is the special variable reference
>> syntax):
>>
>> <#assign t = .get_optional_template("foo.ftl", { 'encoding': 'utf-8' })>
>>
>> The method returns a hash (`t` above) that contains the following keys:
>>
>> - "include": directive (or missing); `<@t.include />` has similar
>> effect as `<#include "foo.ftl">`
>>
>> - "import": method (or missing); returns a namespace. `<#assign f =
>> t.import()>` has si
Re: Moving JBoss FreeMarker IDE (Eclipse plugin) to the ASF?
Friday, March 9, 2018, 4:50:47 PM, Daniel Dekany wrote: > Friday, March 9, 2018, 3:25:35 PM, Jacques Le Roux wrote: > >> Le 09/03/2018 à 13:56, Daniel Dekany a écrit : >>> Surely that >>> possibility is a major feature of these OS licenses... but of course >>> we can't do that here at the ASF (or, I presume so). >> I think the contrary, the ASL2 is permissive not the LGPL 2.1 which >> is copyleft. > > I didn't imply anything like that. What I meant is that you can fork > FreeMarker IDE whenever you wish, as the license allows that. But we > can't do it at the ASF, and that was new to at least some of them. > >> That's my concern for the others "individual contributors". > > Same here. > > There are around 30 committers involved during the 12 years at RedHat, > about half of them are (or was) RedHat employees according the e-mail > addresses. I was hasty here... as some people use multiple e-mail addresses, it's actually "only" 19 contributors, out of which 11 is/was at RedHat. > Before that, the plugin was originally created by Joe > Hudson (https://sourceforge.net/projects/freemarker-ide/). Hopefully > he was working alone. > >> How to be sure they agree about giving their rights to the ASF? >> It's OK for us if RedHat does the job, else we need to do it near the others >> "individual contributors" >> >> Jacques >> >> > -- Thanks, Daniel Dekany
Re: Moving JBoss FreeMarker IDE (Eclipse plugin) to the ASF?
Friday, March 9, 2018, 3:25:35 PM, Jacques Le Roux wrote: > Le 09/03/2018 à 13:56, Daniel Dekany a écrit : >> Surely that >> possibility is a major feature of these OS licenses... but of course >> we can't do that here at the ASF (or, I presume so). > I think the contrary, the ASL2 is permissive not the LGPL 2.1 which > is copyleft. I didn't imply anything like that. What I meant is that you can fork FreeMarker IDE whenever you wish, as the license allows that. But we can't do it at the ASF, and that was new to at least some of them. > That's my concern for the others "individual contributors". Same here. There are around 30 committers involved during the 12 years at RedHat, about half of them are (or was) RedHat employees according the e-mail addresses. Before that, the plugin was originally created by Joe Hudson (https://sourceforge.net/projects/freemarker-ide/). Hopefully he was working alone. > How to be sure they agree about giving their rights to the ASF? > It's OK for us if RedHat does the job, else we need to do it near the others > "individual contributors" > > Jacques > > -- Thanks, Daniel Dekany
Re: Moving JBoss FreeMarker IDE (Eclipse plugin) to the ASF?
Friday, March 9, 2018, 11:56:19 AM, Jacques Le Roux wrote: > Le 09/03/2018 à 10:32, Daniel Dekany a écrit : >>> So I think "FreeMarker IDE" should be brought over to the ASF, >>> similarly as FreeMarker-Online was. Also the Eclipse update "site" >>> should be hosted on ASF infrastructure. I have started a discussion to >>> explore this possibility, and so far it seems it's fine on their side: >>> >>> http://lists.jboss.org/pipermail/jbosstools-dev/2018-March/subject.html >>> >>> The code is under EPL, >> Wrong, sorry... It's under LGPL 2.1 (and the copyright holder is >> RedHat "and individual contributors"), at least on most source files. >> >> I have suggested at JBoss Tools that if they sign CCLA and then make a >> PR to a repo at ASF that we create for this product, that way >> contributing the whole source code to the ASF, then we can replace the >> license headers etc. I have indicated that this is just my personal >> understanding. So, will that work? We did the same with "FreeMarker >> Online". >> > Hi Daniel, > > I believe it depends on RedHat "and individual contributors" good wills. > Maybe easier for RedHat than "individual contributors" depending how RedHat > handles that part. > Contrary to ASL2, for LGPL 2.1 I don't know, we might need help from legal if > RedHat can't tell. Yeah, I'm worried about these too. They are much more relaxed about these matters apparently. Like some of them thought I could simply fork in an ASF repo, and they need not even know about it. Surely that possibility is a major feature of these OS licenses... but of course we can't do that here at the ASF (or, I presume so). Anybody has anything to add, before we ask ASF Legal? > Jacques -- Thanks, Daniel Dekany
Re: Moving JBoss FreeMarker IDE (Eclipse plugin) to the ASF?
Wednesday, March 7, 2018, 5:07:49 PM, Daniel Dekany wrote: > The only Eclipse plugin in reasonable state for editing FreeMarker > templates is "FreeMarker IDE", which is part of the JBoss Tools > project. See the top entry at > https://freemarker.apache.org/editors.html, and also > https://github.com/jbosstools/jbosstools-freemarker. > > However, RedHat has deprecated and now removed the "FreeMarker IDE" > plugin from JBoss Tools and Devstudio. See: > https://stackoverflow.com/questions/49072160/why-is-freemarker-ide-in-eclipse-oxygen-jboss-tools-4-5-2-final-deprecated > https://issues.jboss.org/browse/JBIDE-25736 > > So I think "FreeMarker IDE" should be brought over to the ASF, > similarly as FreeMarker-Online was. Also the Eclipse update "site" > should be hosted on ASF infrastructure. I have started a discussion to > explore this possibility, and so far it seems it's fine on their side: > > http://lists.jboss.org/pipermail/jbosstools-dev/2018-March/subject.html > > The code is under EPL, Wrong, sorry... It's under LGPL 2.1 (and the copyright holder is RedHat "and individual contributors"), at least on most source files. I have suggested at JBoss Tools that if they sign CCLA and then make a PR to a repo at ASF that we create for this product, that way contributing the whole source code to the ASF, then we can replace the license headers etc. I have indicated that this is just my personal understanding. So, will that work? We did the same with "FreeMarker Online". > but of course they should "contribute" the code > the ASF where we can replace the license with ASL2, and rename the > packages. > > Technically, "FreeMarker IDE" is independent of the rest of JBoss > Tools, we only had to substitute org.jboss.tools:parent (as it's not > in the Maven Central, it's not an acceptable dependency IMO). Also, tests depend on jbosstools-base and jbosstools-locus, which aren't available in Maven Central either. (They are in JCenter, but outdated, compared to http://repository.jboss.org/nexus/content/groups/public/) > What do you think? Will the ASF be fine with bringing over yet another > FreeMarker related project? Do you think it's good to do? > > My opinion is that the more control we have over such products, the > easier it is to ensure that they remain maintained and available to > the users. > -- Thanks, Daniel Dekany
LSP for FreeMarker Was: Moving JBoss FreeMarker IDE (Eclipse plugin) to the ASF?
Thursday, March 8, 2018, 9:26:03 AM, Angelo zerr wrote: >> > tm4e and lsp4e follow the same idea than VSCode: >> > >> > * manage syntax coloration with a textmate grammar. >> > * manage completion, hover, etc with LSP >> > >> > tm4e and lsp4e are 2 distinct projects so you cannot use some information >> > coming from lsp4e (some kind of AST) in tm4e. >> >> I belive it's natural that these two things (heavy weight parsing and >> a faster one for coloring) are executed independently. (FreeMarker IDE >> does that as well.) > > > Yes. The benefit to use tm4e si that you can share the work of syntax > coloring with textmate and it works with VSCode, WebStorm, Eclipse, Atom, > etc > > >> So far so good. But when the heavy weight parser >> catches up, it should apply the extra visuals. Many traditional >> plugins work like that, I believe (semantic coloring used to lag >> behind basic coloring in Eclipse's Java editor for example). >> > > Ok I understand what you mean, for that. Perhaps you could use > > `textDocument/documentSymbol` > > > https://github.com/Microsoft/language-server-protocol/blob/gh-pages/specification.md This is certainly not critical for a FreeMarker editor, but what I was getting at is that even though you (eventually) get the required information from the LSP, the textmate grammar plugin must not interfere with utilizing it for coloring. Maybe it doesn't, I don't know... had to find a plugin that already does that (tm4e combined with coloring based on LSP output) to know. >> > * for syntax coloration with texmate, you can inject textmate grammar >> (ex: >> > Freemarker) in an existing textmate grammar (ex: HTML). I have that for >> > TypeScript file >> > which can contains angular syntax in their @Component/template. >> > * for completion, etc (LSP) I think you can apply several language >> server >> > for the same kind of file. So if you open an HTML file, it could execute >> > the existing HTML language server et the Freemarker language server. >> >> You mean, maybe, the LSP that understand FreeMarker kind of cuts out >> the FreeMarker constructs and passed down the now purely HTML content >> to the HTML LSP, and then combines the results? >> > > I mean that Freemarker language server manage completion only for > Freemarker (not for HTML tag) and when you open an HTML file > there will have HTML language server and Freemarker language server which > will work together but without having dependency. > > * the HTML language server will provide completion only for HTML, css and > javascript > * the Freemarker language server will provide completion only for > Freemarker. > > I think if we have a Freemarker language server, we could consume it in > https://github.com/mickaelistria/eclipse-bluesky which provides > syntax coloring for HTML, JavaScript, TypeScript, CSS, etc (by using tm4e) > and completion for HTML, JavaScript, TypeScript, CSS, etc > (by using lsp4e). > > It will be easy to have a good Freemarker editor (which will support too > mix with HTML) if we have a Freemarker language server. Won't it be a problem though that a template is not in general valid HTML? That's why I was talking about removing FM pieces first. Anyway, I don't want to make the impression that I hope to tackle this myself, because I don't. I'm happy if I manage to mature FM3 fast enough, while also maintaining FM2... Those are the things that barely anyone can pick up. Developing the Eclipse plugin is perfect for others to jump in. (And so is improving try.freemarker.org.) >> Are the working plugins that actually do this? >> >> >> > And it could work for other editor which supports LSP like VSCode, >> >> > WebStorm, etc >> >> > >> >> > I think you (the question is who?) should spend your time with LSP >> >> > Freemarker Server. It's an hard work but it will work with a lot of >> >> > Editor/IDE. >> >> > >> >> > Regard's Angelo >> >> > >> >> > 2018-03-07 20:23 GMT+01:00 Taher Alkhateeb < >> slidingfilame...@gmail.com>: >> >> > >> >> >> Great idea. Love to help if I can >> >> >> >> >> >> On Mar 7, 2018 7:08 PM, "Daniel Dekany" <ddek...@apache.org> wrote: >> >> >> >> >> >> > The only Eclipse plugin in reasonable state for editing FreeMarker >> >> >> > templates is "FreeMarker IDE", which is part of the JBoss Tools >> >> >> > project. See t
Re: Moving JBoss FreeMarker IDE (Eclipse plugin) to the ASF?
Thursday, March 8, 2018, 6:45:33 AM, Angelo zerr wrote: >> >> >> I have looked at these briefly when you mentioned LSP, but two >> question aren't yet clear to me: >> >> - Can tm4e leverage information provided by lsp4e to do semantical >> highlighting? (This will be relevant only for FM3 though, like for >> coloring data-model variable references differently than "local" >> variable references.) >> > > A first I would like clarify something: LSP doesn't take care of syntax > coloration. > > tm4e and lsp4e follow the same idea than VSCode: > > * manage syntax coloration with a textmate grammar. > * manage completion, hover, etc with LSP > > tm4e and lsp4e are 2 distinct projects so you cannot use some information > coming from lsp4e (some kind of AST) in tm4e. I belive it's natural that these two things (heavy weight parsing and a faster one for coloring) are executed independently. (FreeMarker IDE does that as well.) So far so good. But when the heavy weight parser catches up, it should apply the extra visuals. Many traditional plugins work like that, I believe (semantic coloring used to lag behind basic coloring in Eclipse's Java editor for example). > tm4e support syntax coloration (and starts supporting language > configuration configured with a JSON file for matching bracket, etc) > with a textmate grammar. I'm not an expert with textmate grammar (uses of > advanced regexp), but you can manage the "local" variable I think > because in textmate grammar you have a "scope" context. > > If you install tm4e https://github.com/eclipse/tm4e#install, you can > register the Freemarker textmate grammar > https://github.com/dcortes92/vs-freemarker/blob/master/syntaxes/ftl.tmLanguage > (with Window / Preferences -> TextMate / Grammar) and you should have > Freemarker syntax coloration > > >> >> - Can we leverage some existing HTML/JS/CSS editor functionality with this? >> I mean something like in >> https://github.com/angelozerr/eclipse-wtp-freemarker. (By far the >> most often request for "FreeMarker IDE" is to do HTML syntax >> highlighting, but then I'm sure HTML auto-completion etc. will >> follow.) >> > > It's a very good question:): > > * for syntax coloration with texmate, you can inject textmate grammar (ex: > Freemarker) in an existing textmate grammar (ex: HTML). I have that for > TypeScript file > which can contains angular syntax in their @Component/template. > * for completion, etc (LSP) I think you can apply several language server > for the same kind of file. So if you open an HTML file, it could execute > the existing HTML language server et the Freemarker language server. You mean, maybe, the LSP that understand FreeMarker kind of cuts out the FreeMarker constructs and passed down the now purely HTML content to the HTML LSP, and then combines the results? Are the working plugins that actually do this? >> > And it could work for other editor which supports LSP like VSCode, >> > WebStorm, etc >> > >> > I think you (the question is who?) should spend your time with LSP >> > Freemarker Server. It's an hard work but it will work with a lot of >> > Editor/IDE. >> > >> > Regard's Angelo >> > >> > 2018-03-07 20:23 GMT+01:00 Taher Alkhateeb <slidingfilame...@gmail.com>: >> > >> >> Great idea. Love to help if I can >> >> >> >> On Mar 7, 2018 7:08 PM, "Daniel Dekany" <ddek...@apache.org> wrote: >> >> >> >> > The only Eclipse plugin in reasonable state for editing FreeMarker >> >> > templates is "FreeMarker IDE", which is part of the JBoss Tools >> >> > project. See the top entry at >> >> > https://freemarker.apache.org/editors.html, and also >> >> > https://github.com/jbosstools/jbosstools-freemarker. >> >> > >> >> > However, RedHat has deprecated and now removed the "FreeMarker IDE" >> >> > plugin from JBoss Tools and Devstudio. See: >> >> > https://stackoverflow.com/questions/49072160/why-is- >> >> > freemarker-ide-in-eclipse-oxygen-jboss-tools-4-5-2-final-deprecated >> >> > https://issues.jboss.org/browse/JBIDE-25736 >> >> > >> >> > So I think "FreeMarker IDE" should be brought over to the ASF, >> >> > similarly as FreeMarker-Online was. Also the Eclipse update "site" >> >> > should be hosted on ASF infrastructure. I have started a discussion to >> >> > explore this possibil
Re: Moving JBoss FreeMarker IDE (Eclipse plugin) to the ASF?
Wednesday, March 7, 2018, 8:23:18 PM, Taher Alkhateeb wrote: > Great idea. Love to help if I can Sure, any help is welcome. If this happens, there will be a lot of things to do: - Package/artifact renaming (re-branding), get rid of the org.jboss parent artifact, replace license headers, reach the point where the Apache Rat report contains no problems. - Figure out how to ensure that the plugin works on a range of Eclipse versions. JBoss Tools has a separate repository for each major Eclipse versions (Mars, Neon, Oxygen, etc.). However in practice I have found that "FreeMarker IDE" builds for never Eclipses work fine on a much older Eclipse. So I'm hoping that we will not need to complicate things that much. Maybe we just have to run tests on the oldest and newest supported Eclipse versions. (How to do that of course need to be figured out and documented.) - Set up infrastructure. I guess it's not much, as we might as well just generate the "site" locally with Maven and manually upload it to https://freemarker.apache.org/eclipse-plugin/. (The process need to be documented of course.) - Create an Eclipse Market place entry (haven't checked yet what that takes). - Clean up code. This plugin is a mess even compared to FM2. (; - Fix glitches, add new features... > On Mar 7, 2018 7:08 PM, "Daniel Dekany" <ddek...@apache.org> wrote: > >> The only Eclipse plugin in reasonable state for editing FreeMarker >> templates is "FreeMarker IDE", which is part of the JBoss Tools >> project. See the top entry at >> https://freemarker.apache.org/editors.html, and also >> https://github.com/jbosstools/jbosstools-freemarker. >> >> However, RedHat has deprecated and now removed the "FreeMarker IDE" >> plugin from JBoss Tools and Devstudio. See: >> https://stackoverflow.com/questions/49072160/why-is- >> freemarker-ide-in-eclipse-oxygen-jboss-tools-4-5-2-final-deprecated >> https://issues.jboss.org/browse/JBIDE-25736 >> >> So I think "FreeMarker IDE" should be brought over to the ASF, >> similarly as FreeMarker-Online was. Also the Eclipse update "site" >> should be hosted on ASF infrastructure. I have started a discussion to >> explore this possibility, and so far it seems it's fine on their side: >> >> http://lists.jboss.org/pipermail/jbosstools-dev/2018-March/subject.html >> >> The code is under EPL, but of course they should "contribute" the code >> the ASF where we can replace the license with ASL2, and rename the >> packages. >> >> Technically, "FreeMarker IDE" is independent of the rest of JBoss >> Tools, we only had to substitute org.jboss.tools:parent (as it's not >> in the Maven Central, it's not an acceptable dependency IMO). >> >> What do you think? Will the ASF be fine with bringing over yet another >> FreeMarker related project? Do you think it's good to do? >> >> My opinion is that the more control we have over such products, the >> easier it is to ensure that they remain maintained and available to >> the users. >> >> -- >> Thanks, >> Daniel Dekany -- Thanks, Daniel Dekany
Re: Moving JBoss FreeMarker IDE (Eclipse plugin) to the ASF?
Thursday, March 8, 2018, 12:14:20 AM, Woonsan Ko wrote: > On Wed, Mar 7, 2018 at 11:07 AM, Daniel Dekany <ddek...@apache.org> wrote: >> The only Eclipse plugin in reasonable state for editing FreeMarker >> templates is "FreeMarker IDE", which is part of the JBoss Tools >> project. See the top entry at >> https://freemarker.apache.org/editors.html, and also >> https://github.com/jbosstools/jbosstools-freemarker. >> >> However, RedHat has deprecated and now removed the "FreeMarker IDE" >> plugin from JBoss Tools and Devstudio. See: >> https://stackoverflow.com/questions/49072160/why-is-freemarker-ide-in-eclipse-oxygen-jboss-tools-4-5-2-final-deprecated >> https://issues.jboss.org/browse/JBIDE-25736 >> >> So I think "FreeMarker IDE" should be brought over to the ASF, >> similarly as FreeMarker-Online was. Also the Eclipse update "site" >> should be hosted on ASF infrastructure. I have started a discussion to >> explore this possibility, and so far it seems it's fine on their side: >> >> http://lists.jboss.org/pipermail/jbosstools-dev/2018-March/subject.html >> >> The code is under EPL, but of course they should "contribute" the code >> the ASF where we can replace the license with ASL2, and rename the >> packages. >> >> Technically, "FreeMarker IDE" is independent of the rest of JBoss >> Tools, we only had to substitute org.jboss.tools:parent (as it's not >> in the Maven Central, it's not an acceptable dependency IMO). >> >> What do you think? Will the ASF be fine with bringing over yet another >> FreeMarker related project? Do you think it's good to do? > I don't think there's any issue by adding a *subproject* in a top > level project as many others do. It would be like freemarker-online-tester, so it's a separate repo but controlled by the FreeMarker project. From this though we will need to do official releases (with VOTE etc.), unlike from the other "subprojects". > I found a very similar example: > - http://directory.apache.org/studio/installation-in-eclipse.html > > And, they maintain the update site at > http://directory.apache.org/studio/update. > > I guess we can do the same thing (as a subproject under FreeMarker) if > RedHat is willing to contribute. > > Regards, > > Woonsan > >> >> My opinion is that the more control we have over such products, the >> easier it is to ensure that they remain maintained and available to >> the users. >> >> -- >> Thanks, >> Daniel Dekany >> > -- Thanks, Daniel Dekany
Re: Moving JBoss FreeMarker IDE (Eclipse plugin) to the ASF?
Wednesday, March 7, 2018, 10:08:45 PM, Angelo zerr wrote: > Hi Daniel, > > We have already spoken about that, but IMHO I think Freemarker should > provide an LSP server. Yeah, they mentioned it over JBoss as well, when I brought the transfer up now. However, right now we should ensure continually. Developing a new plugin will take time, and it's not known who, if anyone will do it. "FreeMarker IDE", however ugly it is, exists right now. > After that it will be easy to have > > * good completion, hover, etc by using Eclipse lsp4e > <https://projects.eclipse.org/projects/technology.lsp4e> > * have syntax coloration with textmate by using tm4e > <https://github.com/eclipse/tm4e> I have looked at these briefly when you mentioned LSP, but two question aren't yet clear to me: - Can tm4e leverage information provided by lsp4e to do semantical highlighting? (This will be relevant only for FM3 though, like for coloring data-model variable references differently than "local" variable references.) - Can we leverage some existing HTML/JS/CSS editor functionality with this? I mean something like in https://github.com/angelozerr/eclipse-wtp-freemarker. (By far the most often request for "FreeMarker IDE" is to do HTML syntax highlighting, but then I'm sure HTML auto-completion etc. will follow.) > And it could work for other editor which supports LSP like VSCode, > WebStorm, etc > > I think you (the question is who?) should spend your time with LSP > Freemarker Server. It's an hard work but it will work with a lot of > Editor/IDE. > > Regard's Angelo > > 2018-03-07 20:23 GMT+01:00 Taher Alkhateeb <slidingfilame...@gmail.com>: > >> Great idea. Love to help if I can >> >> On Mar 7, 2018 7:08 PM, "Daniel Dekany" <ddek...@apache.org> wrote: >> >> > The only Eclipse plugin in reasonable state for editing FreeMarker >> > templates is "FreeMarker IDE", which is part of the JBoss Tools >> > project. See the top entry at >> > https://freemarker.apache.org/editors.html, and also >> > https://github.com/jbosstools/jbosstools-freemarker. >> > >> > However, RedHat has deprecated and now removed the "FreeMarker IDE" >> > plugin from JBoss Tools and Devstudio. See: >> > https://stackoverflow.com/questions/49072160/why-is- >> > freemarker-ide-in-eclipse-oxygen-jboss-tools-4-5-2-final-deprecated >> > https://issues.jboss.org/browse/JBIDE-25736 >> > >> > So I think "FreeMarker IDE" should be brought over to the ASF, >> > similarly as FreeMarker-Online was. Also the Eclipse update "site" >> > should be hosted on ASF infrastructure. I have started a discussion to >> > explore this possibility, and so far it seems it's fine on their side: >> > >> > http://lists.jboss.org/pipermail/jbosstools-dev/2018-March/subject.html >> > >> > The code is under EPL, but of course they should "contribute" the code >> > the ASF where we can replace the license with ASL2, and rename the >> > packages. >> > >> > Technically, "FreeMarker IDE" is independent of the rest of JBoss >> > Tools, we only had to substitute org.jboss.tools:parent (as it's not >> > in the Maven Central, it's not an acceptable dependency IMO). >> > >> > What do you think? Will the ASF be fine with bringing over yet another >> > FreeMarker related project? Do you think it's good to do? >> > >> > My opinion is that the more control we have over such products, the >> > easier it is to ensure that they remain maintained and available to >> > the users. >> > >> > -- >> > Thanks, >> > Daniel Dekany >> > >> > >> -- Thanks, Daniel Dekany
Moving JBoss FreeMarker IDE (Eclipse plugin) to the ASF?
The only Eclipse plugin in reasonable state for editing FreeMarker templates is "FreeMarker IDE", which is part of the JBoss Tools project. See the top entry at https://freemarker.apache.org/editors.html, and also https://github.com/jbosstools/jbosstools-freemarker. However, RedHat has deprecated and now removed the "FreeMarker IDE" plugin from JBoss Tools and Devstudio. See: https://stackoverflow.com/questions/49072160/why-is-freemarker-ide-in-eclipse-oxygen-jboss-tools-4-5-2-final-deprecated https://issues.jboss.org/browse/JBIDE-25736 So I think "FreeMarker IDE" should be brought over to the ASF, similarly as FreeMarker-Online was. Also the Eclipse update "site" should be hosted on ASF infrastructure. I have started a discussion to explore this possibility, and so far it seems it's fine on their side: http://lists.jboss.org/pipermail/jbosstools-dev/2018-March/subject.html The code is under EPL, but of course they should "contribute" the code the ASF where we can replace the license with ASL2, and rename the packages. Technically, "FreeMarker IDE" is independent of the rest of JBoss Tools, we only had to substitute org.jboss.tools:parent (as it's not in the Maven Central, it's not an acceptable dependency IMO). What do you think? Will the ASF be fine with bringing over yet another FreeMarker related project? Do you think it's good to do? My opinion is that the more control we have over such products, the easier it is to ensure that they remain maintained and available to the users. -- Thanks, Daniel Dekany
Re: [FM3] Basic treatment of null VS missing
Tuesday, March 6, 2018, 3:59:22 AM, Woonsan Ko wrote: > On Sat, Mar 3, 2018 at 11:22 AM, Daniel Dekany <ddek...@apache.org> wrote: >> Below I propose a solution for the basic treatment of null VS >> "missing" in FM3. Please tell me what you think! >> >> The way FM2 deals with null-s has quite severe limitations (and >> glitches). The root of the problems is that null and missing is the >> same for the template language. It's not aware of the concept of null; >> for example a variable has either non-null value, or the variable is >> considered to be nonexistent. So <#assign x = obj.m()> fails when >> obj.m() returns null, for the same reason <#assign x = noSuchVariable> >> does. (Note that even if we store null into x on the implementation >> level, reading x will fall back to higher scopes to find an x there, >> instead of returning null.) Another problem is with >> macro/function/method arguments; f(noSuchVariable) will not fail if f >> provides a default for the parameter (as in <#function f(x=0)>), on >> the basis that noSuchVariable is missing, so the parameter was >> practically omitted. Not good, as thus we have suppressed an error >> that tells us that there's no noSuchVariable. Also, if in f you want >> to call a obj.javaMethod(x), where x is the parameter of f, and you >> want to allow x to be null, because obj.javaMethod(x) allows that, you >> can't. Because, if you don't provide a default, f(m.willReturnNull()) >> will be an error for using a null/missing value for a required >> parameter, and if you do provide a default, then since null is not a >> thing in the template language, you can't specify null as the default >> value of the parameter. >> >> So, here's my plan for FM3. >> >> The template language will know null, and it's different that from >> "missing". I think so far everyone who has used FM2 heavily will >> agree. >> >> On the API and implementation level we will have a singleton, >> TemplateNullModel.INSTANCE, that stands for things that do exist but >> has null value, while a plain null value indicates that the thing is >> missing. For example, Environment.getVariable(name), >> TempateHashModel.get(key), and TemplateSequenceModel.get(index) >> returns null if the subvariable is missing, and >> TemplateNullModel.INSTANCE if it's present but stores a null value. >> Also in TemplateDirectiveModel and TemplateFunctionModel the >> `TemplateModel[] args` argument of execute(...) will contain null if >> the argument was omitted on the caller side (like in f() the 1st >> parameter is omitted), but TemplateNullModel.INSTANCE if it the >> argument was present, but has null value on the template language >> level (like in f(null) or f(obj.willReturnNull())). >> >> The above can be confusing, as null on the template language level is >> TemplateNullModel.INSTANCE on the API level, and null on the API level >> is "missing" on the template language level... So when I write null, >> pay attention to if it's null on the template language level, or null >> on the API/implementation level. > > Could it be an option to use either TemplateModel.NULL_VALUE or > TemplateModel.MISSING_VALUE, whether in Environment.getVariable(name) > or in TemplateCallableModel#...)? > It might be more readable if doable. > I guess there should be quite a change even with > TemplateNullModel.INSTANCE or null in CallableUtils.java (e.g, > #getOptionalStringArgument(...)) as it should be determined how to > handle null or missing value there. While using TemplateModel.MISSING_VALUE in place of null indeed makes the source code and some API-s easier to understand, it has some performance implications, so I'm not sure if we want to pay that, given that 99% of the users never call or implement API-s that are affected by this decision. If you use null to indicate missing value, then you can utilize that Java initializes arrays of reference types with null-s. Like consider an argument list array for a callables. If you use MISSING_VALUE, then for each invocation, you have to fill that array with MISSING_VALUE in a loop (or need a logic that sets the omitted parameters to MISSING_VALUE at least). That's after Java has already, and unavoidably, has initialized the array with null-s for you. (You had some directives with lot of optional parameters, so I guess you feel the pain.) Also, Map.get naturally returns null for missing items, so you don't have to add `if (v == null) v = TemplateModel.MISSING_VALUE);` (or worse, actually add MISSING_VALUE-s to a Map), which can come handy at some places. Also, `v == null` is, maybe, some times, a tiny bit fast
Re: [FM3] Basic treatment of null VS missing
or now, it suffice knowing that #var declares a variable
in a certain scope, and typically you will also initialize it there
explicitly, like <#var x = 1>. But sometimes you got a situation like:
<#var x> <#-- We don't know x yet, we just widen its scope -->
<@someVarScope>
...
<#set x = 123> <#-- Now we know x -->
...
${x} <#-- x is still in scope -->
>> It's hard to evaluate the above if you don't known how the
>> null/missing handler operators
>> (https://freemarker.apache.org/docs/dgui_template_exp.html#dgui_template_exp_missing)
>> will react to "missing". That was touched in
>> https://lists.apache.org/thread.html/f520220aefc5064030f8674a1cd482b6469797ff74ad2bdd3c0a1b9c@,
>> but going into details would derail discussion. But the basic idea is
>> that exp!default only handles null, not "missing". Why? Let's say you
>> write ${user.realNaem!'Not provided'}. As you see you expect the
>> realName to be null, and also you managed to write realNaem instead of
>> realName (a typo). If exp!default handles "missing", then this mistake
>> is hidden by it, while if it only handles null then you get an error
>> (as there's no getRealNaem() method in that bean) as desirable.
>
> Makes sense.
>
>> Now, there are some rough edges in this idea, like what if you write
>> user.phoneNumber, and while getPhoneNumber() dies exists in class
>> EmployeeUser, it doesn't exist in CustomerUser... so in case user in
>> the data-model is a customer, ${user.phoneNumber!'Not provided'} will
>> not save you. If that can't be addressed on the data-model level (like
>> abstract class User is annotated with @ValidPropertyNamesFrom({
>> EmployeeUser.class, CustomerUser.class })), there's the possibility
>> that there will be something like exp!!default that handless both null
>> and "missing", or that the right compromise will be if exp!default
>> handle both after all. But, I can proceed without deciding this part
>> right now.
>
> Maybe in that situation you would use a bean wrapper that maps
> non-existent keys to null instead of missing.
You could. Like if the data model itself (the root) used to be Map,
and you switch to using a bean, it's likely that you want to do that,
although probably only for that single bean.
>> Another interesting aspect is parameter defaults in macro/function.
>> Clearly, an argument that's "missing" is immediately an error (unlike
>> in FM2), so defaults are irrelevant in that case. But what will happen
>> if you have <#function f(x=0)>, and then you do f(null)? The parameter
>> was not omitted, so will x be 0 or null? I think parameters should
>> have an attribute that tells if it should accept null-s or not (kind
>> of like "not null" constraint in databases). If we accept that idea,
>> then the answer to the question is that if x has a "not null"
>> constraint then x will be 0, but if x is nullable then x will be null
>> in the example case (because the default value is not applied). BTW, I
>> believe the best would be if macro/function parameters by default has
>> "not null" constraint, and you explicitly indicate if want to allow
>> null-s (e.g. `<#function f(x{nullable}=0)>`).
>
> ok
>
> — Denis.
>
>> --
>> Thanks,
>> Daniel Dekany
--
Thanks,
Daniel Dekany
Re: Proposal for FREEMARKER-84: More flexible handlig of missing templates
.get_optional_template(name[, options]) now implemented in the 2.3-gae
and 2.3 branches. Testing/feedback is welcome!
See commit:
https://github.com/apache/incubator-freemarker/commit/51c2476621809d8f4183f23e894be0106cabe810
You can find some examples in the tests:
https://github.com/apache/incubator-freemarker/blob/2.3-gae/src/test/java/freemarker/core/GetOptionalTemplateTest.java
Sunday, February 11, 2018, 10:02:30 PM, Daniel Dekany wrote:
> See the RFE here:
> https://issues.apache.org/jira/browse/FREEMARKER-84
>
> As you see, the first consensus was introducing `.last_include_found`,
> but it has two problems:
>
> * Sometimes it happens that if, and only if the template exists then
> you want to do (usually print) something *before* it. Problem is, by
> the time you know that from `.last_include_found`, it's too late, as
> the template was already processed.
>
> * Like many global state variables in general, this can lead to some
> confusing edge cases and hard-to-follow code. Like, if `#include`
> throws an exception, which is then handled by the user with
> `#attempt`/`#recover`, then `.last_include_found` may or may not be
> updated, as perhaps we haven't yet reached the point where it can be
> told if the template exists. (Consider an expression evaluation
> error in the `#include` parameter, or an I/O error due to which we
> can't access the template directory). Also there are some public
> `include` methods in the `Environment` API, but they can't set this
> variable, as they return a `Template`, and the variable must be set
> after the `Template` was processed, unless the template was missing.
> (If you can't figure out why it must be done that way, that proves
> again how tricky this is... think about includes inside includes.)
>
> So, I propose the solution below. Maybe somewhat difficult to grasp
> first, but it meant to be used rarely, and mostly by "experts"...
> Let's hope SO and examples in the Manual will help people though. (-;
>
> Introduce a new special variable (see
> https://freemarker.apache.org/docs/ref_specvar.html) called
> "get_optional_template", which is a TemplateMethodModelEx with these
> parameters:
>
> 1. template name (maybe a relative path, resolved as #include/#import
> does it) 2. A hash that can have the following keys: "parse",
> "encoding" (similarly to
> https://freemarker.apache.org/docs/ref_directive_include.html#ref.directive.include).
>
> Example method call (the `.` prefix is the special variable reference syntax):
>
> <#assign t = .get_optional_template("foo.ftl", { 'encoding': 'utf-8' })>
>
> The method returns a hash (`t` above) that contains the following keys:
>
> - "include": directive (or missing); `<@t.include />` has similar
> effect as `<#include "foo.ftl">`
>
> - "import": method (or missing); returns a namespace. `<#assign f =
> t.import()>` has similar effect as `<#import 'foo.ftl' as f>`
>
> - "exists": boolean; returns if the template was found.
>
> The method call loads the target template eagerly, i.e., it won't wait
> until `t.include`, `t.exist` etc. is actually used.
>
> Note that the hash is returned even if the template wasn't found (but
> then it won't contain "include" and "import", and "exists" will be
> `false`). If some other error occurs, like an I/O error other than a
> "template not found", or the template has invalid syntax, it will
> throw exception (just like #include).
>
> Use cases:
>
> - `#include` with fallback templates or fallback macro (note how we
> can use the `exp!defaultExp` operator):
>
> <@.get_optional_template('foo.ftl')
> !.get_optional_template('bar.ftl').include
> !defaultMacro />
>
> - Doing something before `#include` if the template exists:
>
> <#assign t = .get_optional_template('foo.ftl')>
> <#if t.exists>
> Do before existing template
> <@t.include />
>
>
> Opinions?
>
--
Thanks,
Daniel Dekany
Re: Started graduation resolution DISCUSS on general@incubator.a.o
Thanks Jacopo! If the board will accept the resolution on 21st of March, we can at last get rid of that discouraging "-incubating" from the Maven artifact version, so we should release 2.3.28 quickly. So if anyone wants certain featuers/fixes to be in, time to bring it up. (I will very certainly add at least .get_optional_template by then, and [=exp].) Though it's not clear from https://incubator.apache.org/guides/graduation.html#graduating_to_a_top_level_project if after the board decision when can we actually do a non-incubating release. Pretty much immediately? Thursday, February 22, 2018, 2:10:51 PM, Jacopo Cappellato wrote: > The vote is now closed and it was successful! > While this is not the final step in the graduation process, and we will > have to wait until the 21st of March for the ASF Board to ratify the > resolution to establish the project, it is indeed an important step and > achievement: we got 12 positive binding votes from Incubator PMC members > and no negative votes. Congratulations to the community! > > I am going to wait for a few days before submitting the resolution to the > next Board meeting agenda. > > Kind regards, > > Jacopo > > > On Tue, Feb 6, 2018 at 6:42 PM, Daniel Dekany <ddek...@apache.org> wrote: > >> I have started the resolution DISCUSS thread on the >> general@incubator.a.o. PPMC members please follow the discussion, and >> chime in if necessary! >> >> -- >> Thanks, >> Daniel Dekany -- Thanks, Daniel Dekany
Re: Proposal for FREEMARKER-84: More flexible handlig of missing templates
Saturday, February 17, 2018, 11:56:43 AM, Jacques Le Roux wrote: > Hi, > > I must say it's much easier for me to understand Jacopo's solution. That's not really a solution though, rather a work around that works in some cases, but not in others. Jacopo basically says, as far as I see, that we don't have to make FreeMarker even bigger only to address such a rare use case. > But I'm currently not a Freemarker heavy user, so maybe for those > users an integrated syntax is better. > > When I think about it, I had once to use Freemarker heavily for a > small CMS creation. And then indeed I think having > .get_optional_template would have > been a plus. Because it's not a workaround, it's more flexible and allows > more. > > To be frank I was not aware of the special variables and the syntax > is not easy, but all in all I think it's worth it. > > Jacques > > > Le 16/02/2018 à 08:04, Daniel Dekany a écrit : >> Some more opinions guys? Especially as we got one opinion against the >> feature. >> >> >> Tuesday, February 13, 2018, 9:59:41 AM, Daniel Dekany wrote: >> >>> Tuesday, February 13, 2018, 9:28:18 AM, Jacopo Cappellato wrote: >>> >>>> For less common use cases like this my preference is to defer the >>>> implementation to the template developer rather than adding complexity to >>>> the language. >>>> If I understand the use case that originated this request, something >>>> similar could be achieved with a simple trick like the following: >>>> 1) the calling code would be: >>>> <#include "possibly-missing-template.ftl" ignore_missing=true> >>>> <#if !processed??> >>>> The template was not found or processed! >>>> >>>> 2) somewhere in possibly-missing-template.ftl (i.e. at the bottom of it) we >>>> add an assign directive like: >>>> <#assign processed=true> >>>> >>>> There are some cons to this approach (the most relevant one is that the >>>> referenced template has to contain the #assign directive) but FM users >>>> could live with this approach and in the meantime we could try to get their >>>> feedback to better understand how much this requirement is desired to >>>> justify a change to the codebase. >>> The need for optional includes is something that was brought up for >>> several times during the years. It's mostly needed for some custom >>> fallback logic as far as I can tell. (While there's #include >>> ignore_missing=true for a while, it doesn't let you to take some extra >>> action depending on if the template is missing.) >>> >>> As of it's important enough to add a new feature of this weight (which >>> low, as it's just yet another special variable, no new directive or >>> syntax): It's a template language, and in that context >>> including/importing other templates is probably an important enough >>> topic to warrant some extras. >>> >>>> Jacopo >>>> >>>> On Sun, Feb 11, 2018 at 10:02 PM, Daniel Dekany <ddek...@apache.org> wrote: >>>> >>>>> See the RFE here: >>>>> https://issues.apache.org/jira/browse/FREEMARKER-84 >>>>> >>>>> As you see, the first consensus was introducing `.last_include_found`, >>>>> but it has two problems: >>>>> >>>>> * Sometimes it happens that if, and only if the template exists then >>>>>you want to do (usually print) something *before* it. Problem is, by >>>>>the time you know that from `.last_include_found`, it's too late, as >>>>>the template was already processed. >>>>> >>>>> * Like many global state variables in general, this can lead to some >>>>>confusing edge cases and hard-to-follow code. Like, if `#include` >>>>>throws an exception, which is then handled by the user with >>>>>`#attempt`/`#recover`, then `.last_include_found` may or may not be >>>>>updated, as perhaps we haven't yet reached the point where it can be >>>>>told if the template exists. (Consider an expression evaluation >>>>>error in the `#include` parameter, or an I/O error due to which we >>>>>can't access the template directory). Also there are some public >>>>>`include` methods in the `Environment` API, but they can't set this >>>>>variable, as they return a `Template`, and the variable must be set
Re: Proposal for FREEMARKER-84: More flexible handlig of missing templates
Some more opinions guys? Especially as we got one opinion against the
feature.
Tuesday, February 13, 2018, 9:59:41 AM, Daniel Dekany wrote:
> Tuesday, February 13, 2018, 9:28:18 AM, Jacopo Cappellato wrote:
>
>> For less common use cases like this my preference is to defer the
>> implementation to the template developer rather than adding complexity to
>> the language.
>> If I understand the use case that originated this request, something
>> similar could be achieved with a simple trick like the following:
>> 1) the calling code would be:
>> <#include "possibly-missing-template.ftl" ignore_missing=true>
>> <#if !processed??>
>> The template was not found or processed!
>>
>> 2) somewhere in possibly-missing-template.ftl (i.e. at the bottom of it) we
>> add an assign directive like:
>> <#assign processed=true>
>>
>> There are some cons to this approach (the most relevant one is that the
>> referenced template has to contain the #assign directive) but FM users
>> could live with this approach and in the meantime we could try to get their
>> feedback to better understand how much this requirement is desired to
>> justify a change to the codebase.
>
> The need for optional includes is something that was brought up for
> several times during the years. It's mostly needed for some custom
> fallback logic as far as I can tell. (While there's #include
> ignore_missing=true for a while, it doesn't let you to take some extra
> action depending on if the template is missing.)
>
> As of it's important enough to add a new feature of this weight (which
> low, as it's just yet another special variable, no new directive or
> syntax): It's a template language, and in that context
> including/importing other templates is probably an important enough
> topic to warrant some extras.
>
>> Jacopo
>>
>> On Sun, Feb 11, 2018 at 10:02 PM, Daniel Dekany <ddek...@apache.org> wrote:
>>
>>> See the RFE here:
>>> https://issues.apache.org/jira/browse/FREEMARKER-84
>>>
>>> As you see, the first consensus was introducing `.last_include_found`,
>>> but it has two problems:
>>>
>>> * Sometimes it happens that if, and only if the template exists then
>>> you want to do (usually print) something *before* it. Problem is, by
>>> the time you know that from `.last_include_found`, it's too late, as
>>> the template was already processed.
>>>
>>> * Like many global state variables in general, this can lead to some
>>> confusing edge cases and hard-to-follow code. Like, if `#include`
>>> throws an exception, which is then handled by the user with
>>> `#attempt`/`#recover`, then `.last_include_found` may or may not be
>>> updated, as perhaps we haven't yet reached the point where it can be
>>> told if the template exists. (Consider an expression evaluation
>>> error in the `#include` parameter, or an I/O error due to which we
>>> can't access the template directory). Also there are some public
>>> `include` methods in the `Environment` API, but they can't set this
>>> variable, as they return a `Template`, and the variable must be set
>>> after the `Template` was processed, unless the template was missing.
>>> (If you can't figure out why it must be done that way, that proves
>>> again how tricky this is... think about includes inside includes.)
>>>
>>> So, I propose the solution below. Maybe somewhat difficult to grasp
>>> first, but it meant to be used rarely, and mostly by "experts"...
>>> Let's hope SO and examples in the Manual will help people though. (-;
>>>
>>> Introduce a new special variable (see
>>> https://freemarker.apache.org/docs/ref_specvar.html) called
>>> "get_optional_template", which is a TemplateMethodModelEx with these
>>> parameters:
>>>
>>> 1. template name (maybe a relative path, resolved as #include/#import
>>> does it) 2. A hash that can have the following keys: "parse",
>>> "encoding" (similarly to
>>> https://freemarker.apache.org/docs/ref_directive_include.
>>> html#ref.directive.include).
>>>
>>> Example method call (the `.` prefix is the special variable reference
>>> syntax):
>>>
>>> <#assign t = .get_optional_template("foo.ftl", { 'encoding': 'utf-8' })>
>>>
>>> The method returns a hash (`t` above) that contains the following keys:
>>>
>>> - "include": di
Re: Proposal for FREEMARKER-84: More flexible handlig of missing templates
Tuesday, February 13, 2018, 9:28:18 AM, Jacopo Cappellato wrote:
> For less common use cases like this my preference is to defer the
> implementation to the template developer rather than adding complexity to
> the language.
> If I understand the use case that originated this request, something
> similar could be achieved with a simple trick like the following:
> 1) the calling code would be:
> <#include "possibly-missing-template.ftl" ignore_missing=true>
> <#if !processed??>
> The template was not found or processed!
>
> 2) somewhere in possibly-missing-template.ftl (i.e. at the bottom of it) we
> add an assign directive like:
> <#assign processed=true>
>
> There are some cons to this approach (the most relevant one is that the
> referenced template has to contain the #assign directive) but FM users
> could live with this approach and in the meantime we could try to get their
> feedback to better understand how much this requirement is desired to
> justify a change to the codebase.
The need for optional includes is something that was brought up for
several times during the years. It's mostly needed for some custom
fallback logic as far as I can tell. (While there's #include
ignore_missing=true for a while, it doesn't let you to take some extra
action depending on if the template is missing.)
As of it's important enough to add a new feature of this weight (which
low, as it's just yet another special variable, no new directive or
syntax): It's a template language, and in that context
including/importing other templates is probably an important enough
topic to warrant some extras.
> Jacopo
>
> On Sun, Feb 11, 2018 at 10:02 PM, Daniel Dekany <ddek...@apache.org> wrote:
>
>> See the RFE here:
>> https://issues.apache.org/jira/browse/FREEMARKER-84
>>
>> As you see, the first consensus was introducing `.last_include_found`,
>> but it has two problems:
>>
>> * Sometimes it happens that if, and only if the template exists then
>> you want to do (usually print) something *before* it. Problem is, by
>> the time you know that from `.last_include_found`, it's too late, as
>> the template was already processed.
>>
>> * Like many global state variables in general, this can lead to some
>> confusing edge cases and hard-to-follow code. Like, if `#include`
>> throws an exception, which is then handled by the user with
>> `#attempt`/`#recover`, then `.last_include_found` may or may not be
>> updated, as perhaps we haven't yet reached the point where it can be
>> told if the template exists. (Consider an expression evaluation
>> error in the `#include` parameter, or an I/O error due to which we
>> can't access the template directory). Also there are some public
>> `include` methods in the `Environment` API, but they can't set this
>> variable, as they return a `Template`, and the variable must be set
>> after the `Template` was processed, unless the template was missing.
>> (If you can't figure out why it must be done that way, that proves
>> again how tricky this is... think about includes inside includes.)
>>
>> So, I propose the solution below. Maybe somewhat difficult to grasp
>> first, but it meant to be used rarely, and mostly by "experts"...
>> Let's hope SO and examples in the Manual will help people though. (-;
>>
>> Introduce a new special variable (see
>> https://freemarker.apache.org/docs/ref_specvar.html) called
>> "get_optional_template", which is a TemplateMethodModelEx with these
>> parameters:
>>
>> 1. template name (maybe a relative path, resolved as #include/#import
>> does it) 2. A hash that can have the following keys: "parse",
>> "encoding" (similarly to
>> https://freemarker.apache.org/docs/ref_directive_include.
>> html#ref.directive.include).
>>
>> Example method call (the `.` prefix is the special variable reference
>> syntax):
>>
>> <#assign t = .get_optional_template("foo.ftl", { 'encoding': 'utf-8' })>
>>
>> The method returns a hash (`t` above) that contains the following keys:
>>
>> - "include": directive (or missing); `<@t.include />` has similar
>> effect as `<#include "foo.ftl">`
>>
>> - "import": method (or missing); returns a namespace. `<#assign f =
>> t.import()>` has similar effect as `<#import 'foo.ftl' as f>`
>>
>> - "exists": boolean; returns if the template was found.
>>
>> The method call loads the target template eagerly, i.e., it won't wait
>> until `t.include`, `t.exist
Re: Proposal for FREEMARKER-84: More flexible handlig of missing templates
Monday, February 12, 2018, 12:52:26 AM, jpr...@seznam.cz wrote: > Opinion: > > It seems reasonable. As you suggested, it also seems a little advanced in > style for most cases. > It's very flexible, a bit verbose for common use, a bit of a learning curve > for template author. > > I would prefer a shorter name, like ".get_template". Isn't it up to the > template author to decide if the template is optional and what to do if it's > not found? If it's not optional, then using this new method is (almost) useless, as you can just use #include or #import. Also note that we have a problem with handling a returned null, so I went for something that's more like Optional in Java 8, that is, always returning a non-object that has a property to check if it represents something or nothing. > It seems that, from an author's perspective, all we're doing here > is deciding whether to throw an exception when the template is not found (or > include nothing if ignore_missing is set) or to let the author handle the > situation his own way. Yes. > For me it might eliminate the need to provide Java support for default > templates, something that is on my list to build. So it's a useful addition, > if not super pretty. > > > Other thoughts... > > The first thing that came to mind to ask whether it's practical to also use > existing freemarker idiom. <#list> has similar use scenarios related to > present, missing, alternate output. > > Sketchy conceptual example... > > <#include path,options> > Stuff you want to output only if include is successful. > <#included> > Maybe more stuff to output for successful includes. > <#else> > Stuff you want to do if include failed, for whatever reason. > > > I guess a problem with this is that <#include> is currently expected to be a > self closing element with no content, and since ftl does not appear to use > or require self closing elements like <#include/> it would be a pain to > interpret whether <#include> has content or not. Exactly. It's also not very good for the user (and for tooling). > Forcing it to have content or include a closing tag would be a big > breaking change. Is that the reasoning you would apply to this > question? Not only that. The problem is with the case where you need to do something before the inclusion if the template exists. For that, above you had to introduce a new directive, #included, which is pretty a "heavy" solution for an otherwise quite language-agonistic problem. I mean, in any usual programming language you do something like `Template tOrNull = cfg.getTemplate(blah, allowMissing=true)`, then if the result is non-null, do the include/import with some API using that earlier returned Template. Pretty basic thing, no special statement was needed. The solution proposed by me does the same, except that in FTL we have to: - Fight the inability of assigning null to a target variable (hence it's a hash). (FM3: This will be solved there.) - Fight the inability to call advanced FreeMarker API-s on a Template object from a template (which is fine), but hence it's a hash again, so it can contain those "utilities". - Face how strange the special-variable syntax is (initial dot). BTW, we have the same problem with https://issues.apache.org/jira/browse/FREEMARKER-86 (FM3: This syntax has to go, especially as it also leads to ambiguities, as in the case `maybeNull!.someProp`.) > Is Freemarker's approach to self-closing elements like <#include> likely to > change in Freemarker 3? There's no such plan for the default (HTML-ish) syntax at least. > I didn't see anything about that in a quick review of the web page > on FM3. Maybe you don't even think of these directives as elements. > For a user familiar with HTML or XML it's hard to think of them > otherwise. Yes, that was the intention. I never liked that though. But I intend to remain true to the idea of the original authors anyway. However, I will want to play with an alternative syntax, one that doesn't pretend to be similar to HTML while it's actually not similar at all. Something that a feels bit like WebMacro syntax. -- Thanks, Daniel Dekany
Proposal for FREEMARKER-84: More flexible handlig of missing templates
See the RFE here:
https://issues.apache.org/jira/browse/FREEMARKER-84
As you see, the first consensus was introducing `.last_include_found`,
but it has two problems:
* Sometimes it happens that if, and only if the template exists then
you want to do (usually print) something *before* it. Problem is, by
the time you know that from `.last_include_found`, it's too late, as
the template was already processed.
* Like many global state variables in general, this can lead to some
confusing edge cases and hard-to-follow code. Like, if `#include`
throws an exception, which is then handled by the user with
`#attempt`/`#recover`, then `.last_include_found` may or may not be
updated, as perhaps we haven't yet reached the point where it can be
told if the template exists. (Consider an expression evaluation
error in the `#include` parameter, or an I/O error due to which we
can't access the template directory). Also there are some public
`include` methods in the `Environment` API, but they can't set this
variable, as they return a `Template`, and the variable must be set
after the `Template` was processed, unless the template was missing.
(If you can't figure out why it must be done that way, that proves
again how tricky this is... think about includes inside includes.)
So, I propose the solution below. Maybe somewhat difficult to grasp
first, but it meant to be used rarely, and mostly by "experts"...
Let's hope SO and examples in the Manual will help people though. (-;
Introduce a new special variable (see
https://freemarker.apache.org/docs/ref_specvar.html) called
"get_optional_template", which is a TemplateMethodModelEx with these
parameters:
1. template name (maybe a relative path, resolved as #include/#import
does it) 2. A hash that can have the following keys: "parse",
"encoding" (similarly to
https://freemarker.apache.org/docs/ref_directive_include.html#ref.directive.include).
Example method call (the `.` prefix is the special variable reference syntax):
<#assign t = .get_optional_template("foo.ftl", { 'encoding': 'utf-8' })>
The method returns a hash (`t` above) that contains the following keys:
- "include": directive (or missing); `<@t.include />` has similar
effect as `<#include "foo.ftl">`
- "import": method (or missing); returns a namespace. `<#assign f =
t.import()>` has similar effect as `<#import 'foo.ftl' as f>`
- "exists": boolean; returns if the template was found.
The method call loads the target template eagerly, i.e., it won't wait
until `t.include`, `t.exist` etc. is actually used.
Note that the hash is returned even if the template wasn't found (but
then it won't contain "include" and "import", and "exists" will be
`false`). If some other error occurs, like an I/O error other than a
"template not found", or the template has invalid syntax, it will
throw exception (just like #include).
Use cases:
- `#include` with fallback templates or fallback macro (note how we
can use the `exp!defaultExp` operator):
<@.get_optional_template('foo.ftl')
!.get_optional_template('bar.ftl').include
!defaultMacro />
- Doing something before `#include` if the template exists:
<#assign t = .get_optional_template('foo.ftl')>
<#if t.exists>
Do before existing template
<@t.include />
Opinions?
--
Thanks,
Daniel Dekany
Re: [RESULT][VOTE] Graduate Apache FreeMarker Project from Incubator to TLP
Friday, February 9, 2018, 2:07:54 PM, Jacques Le Roux wrote: > Le 08/02/2018 à 22:30, Daniel Dekany a écrit : >> Monday, February 5, 2018, 9:38:57 AM, Jacques Le Roux wrote: >> >>> Le 04/02/2018 à 10:08, Daniel Dekany a écrit : >>>>> BTW is Freemarker providing a RAT report? >>>> `ant rat` generates one locally. It contains quite a few false alarms, >>>> but I have only used it for manual checking. It's not published >>>> anywhere. >>>> >>> Hi Daniel, >>> >>> You can remove false alarms using a rat-excludes.txt placed in the root. >> That's undocumented, or at least I can't find it in the documentation >> of Rat. Despite that, I have tried it with the latest stable (0.12, >> from 07-Jun-2016... suspicious), but it had no effect. So for now it >> will be Ant's good old fileset excludes. > That's also a good solution for now indeed > > Jacques I have externalized them to a "rat-excludes" file (purely using Ant fileset fatures). Now we have no more false alarms. I have also excluded archives and binaries, so checking if we have new problematic files will be easy, as everything but Standards and Notes must be 0 in the report. (I have also updated https://freemarker.apache.org/committer-howto.html#making-releases point 6 accordingly.) -- Thanks, Daniel Dekany
Re: [RESULT][VOTE] Graduate Apache FreeMarker Project from Incubator to TLP
Monday, February 5, 2018, 9:38:57 AM, Jacques Le Roux wrote: > Le 04/02/2018 à 10:08, Daniel Dekany a écrit : >>> BTW is Freemarker providing a RAT report? >> `ant rat` generates one locally. It contains quite a few false alarms, >> but I have only used it for manual checking. It's not published >> anywhere. >> > Hi Daniel, > > You can remove false alarms using a rat-excludes.txt placed in the root. That's undocumented, or at least I can't find it in the documentation of Rat. Despite that, I have tried it with the latest stable (0.12, from 07-Jun-2016... suspicious), but it had no effect. So for now it will be Ant's good old fileset excludes. > Jacques > -- Thanks, Daniel Dekany
Started graduation resolution DISCUSS on general@incubator.a.o
I have started the resolution DISCUSS thread on the general@incubator.a.o. PPMC members please follow the discussion, and chime in if necessary! -- Thanks, Daniel Dekany
Re: [RESULT][VOTE] Graduate Apache FreeMarker Project from Incubator to TLP
Tuesday, February 6, 2018, 7:59:54 AM, Daniel Dekany wrote: > This was a question. Somebody knows how to do this? Maybe from > somebody who's in the IPMC those field are editable? > > Anyway, at this point, I will start that voting when I get to there, > regardless of this... I mean, the resolution DISCUSS, not the voting... > Tuesday, February 6, 2018, 6:23:22 AM, Ralph Goers wrote: > >> I am confused. Who are we waiting for to do what? >> >> Ralph >> >>> On Feb 3, 2018, at 4:39 AM, Daniel Dekany <ddek...@apache.org> wrote: >>> >>> Good! (And sounds like communication is lacking on the other side...) >>> Now you aren't red on >>> https://whimsy.apache.org/roster/ppmc/freemarker#reporting. >>> >>> There are two other red items though, and I have to admit that I don't >>> know where does it get that false information from: >>> >>> * No Release Yet/Missing ASF Copyright Headers on Source Code >>> * No Release Yet/Binary has licensing issues >>> >>> Do we still miss some project meta info file somewhere? Where are >>> these Whimsy-related things documented? Are we supposed to care at >>> all? >>> >>> I have just checked https://whimsy.apache.org/roster/ppmc/ofbiz... >>> well guys, you don't even have Software Grant and IP Clearance. So I >>> guess this Whimsy thing is still in early stage... or OFBiz needs a >>> good lawyer. (-; >>> >>> >>> Friday, February 2, 2018, 11:02:38 PM, David E Jones wrote: >>> >>>> It looks like this is now taken care of (user jonesde now on the IPMC >>>> list): >>>> >>>> http://home.apache.org/phonebook.html?ctte=incubator >>>> >>>> -David >>>> >>>> >>>> On Wed, Jan 31, 2018 at 9:23 PM, Sergio Fernández <wik...@apache.org> >>>> wrote: >>>> >>>>> Please David, engage again with private@incubator.a.o to see what's going >>>>> on. I don't recall your issue been discussed, but I may missed it. >>>>> >>>>> On Jan 30, 2018 06:39, "Daniel Dekany" <ddek...@apache.org> wrote: >>>>> >>>>>> Monday, January 29, 2018, 7:16:21 PM, David E Jones wrote: >>>>>> >>>>>>> On Mon, Jan 29, 2018 at 8:59 AM, Daniel Dekany <ddek...@apache.org> >>>>>> wrote: >>>>>>> >>>>>>>> Monday, January 29, 2018, 4:35:38 PM, Sergio Fernández wrote: >>>>>>>> >>>>>>>>> Great, Daniel! >>>>>>>>> >>>>>>>>> Let's move to the next step and open the vote at >>>>> general@incubator.a.o >>>>>>>> ;-) >>>>>>>> >>>>>>>> David has started discussing the issue with his Mentor status on Jan >>>>>>>> 24. I'm waiting for that to be resolved. Not sure if there's any >>>>>>>> progress. David, did they answer? Because then that wasn't CC-ed to >>>>>>>> the private list. >>>>>>> >>>>>>> >>>>>>> I got a reply from John D. Ament on Jan 24th saying he was sending >>>>>> notice, >>>>>>> but I haven't seen anything since and not sure if I should even expect >>>>>> any >>>>>>> sort of email notification or if it's something I'd have to hunt around >>>>>> for >>>>>>> or follow up on. >>>>>>> >>>>>>> FWIW I'm not on the Incubator PMC list yet (my ASF username is >>>>>> 'jonesde'): >>>>>>> >>>>>>> http://people.apache.org/phonebook.html?pmc=incubator >>>>>>> >>>>>>> I also don't know if my failure to respond to John's email in June will >>>>>>> cause any issues, or in general what to expect with all this so I >>>>> really >>>>>>> can't say much. >>>>>> >>>>>> If the process is like here, they have vote (at least 3 days), then >>>>>> wait for 3 days so the board can veto the decision, and only then mail >>>>>> you... I hope they have started the process. If they won't report back >>>>>> in a few days, it would be good if you ask them. >>>>>> >>>>>>> -David >>>>>> >>>>>> -- >>>>>> Thanks, >>>>>> Daniel Dekany >>>>>> >>>>>> >>>>> >>> >>> -- >>> Thanks, >>> Daniel Dekany >>> >>> >> >> >> > -- Thanks, Daniel Dekany
Re: [RESULT][VOTE] Graduate Apache FreeMarker Project from Incubator to TLP
Sunday, February 4, 2018, 11:00:08 AM, David E Jones wrote: > On Sat, Feb 3, 2018 at 11:29 PM, Jacques Le Roux < > jacques.le.r...@les7arts.com> wrote: > >> Hi Daniel, >> >> For OFBiz I don't understand why >> >> # No Software Grant and No IP Clearance Filed >> >> I guess David, Andrew and the ASF cleared this aspect when we graduated >> > > The OFBiz graduation was about a decade ago, I doubt the meta data for > older podlings like is kept up to date. A lot has changed at the ASF since > then, many of the tools around now didn't exist either. > > -David Just to be 100% clear, I was kidding with OFBiz having IP issues... Anyway, guys, where do I edit those fields on Whimsy? I don't have proper rights? Or is there some structured file in some repo somewhere? Am I blind? Meanwhile, I have checked 3 *recently* successfully graduated projects: https://whimsy.apache.org/roster/ppmc/trafodion - Red, like us, still alive! https://whimsy.apache.org/roster/ppmc/impala - Not red https://whimsy.apache.org/roster/ppmc/juneau - Not red I thought maybe, just maybe, the secret is in the DOAP file, but nor Impala nor Juneau have a DOAP file (which is interesting). And the project status file (like https://svn.apache.org/repos/asf/incubator/public/trunk/content/projects/freemarker.xml) is unstructured. -- Thanks, Daniel Dekany
Re: [RESULT][VOTE] Graduate Apache FreeMarker Project from Incubator to TLP
Good! (And sounds like communication is lacking on the other side...) Now you aren't red on https://whimsy.apache.org/roster/ppmc/freemarker#reporting. There are two other red items though, and I have to admit that I don't know where does it get that false information from: * No Release Yet/Missing ASF Copyright Headers on Source Code * No Release Yet/Binary has licensing issues Do we still miss some project meta info file somewhere? Where are these Whimsy-related things documented? Are we supposed to care at all? I have just checked https://whimsy.apache.org/roster/ppmc/ofbiz... well guys, you don't even have Software Grant and IP Clearance. So I guess this Whimsy thing is still in early stage... or OFBiz needs a good lawyer. (-; Friday, February 2, 2018, 11:02:38 PM, David E Jones wrote: > It looks like this is now taken care of (user jonesde now on the IPMC list): > > http://home.apache.org/phonebook.html?ctte=incubator > > -David > > > On Wed, Jan 31, 2018 at 9:23 PM, Sergio Fernández <wik...@apache.org> wrote: > >> Please David, engage again with private@incubator.a.o to see what's going >> on. I don't recall your issue been discussed, but I may missed it. >> >> On Jan 30, 2018 06:39, "Daniel Dekany" <ddek...@apache.org> wrote: >> >> > Monday, January 29, 2018, 7:16:21 PM, David E Jones wrote: >> > >> > > On Mon, Jan 29, 2018 at 8:59 AM, Daniel Dekany <ddek...@apache.org> >> > wrote: >> > > >> > >> Monday, January 29, 2018, 4:35:38 PM, Sergio Fernández wrote: >> > >> >> > >> > Great, Daniel! >> > >> > >> > >> > Let's move to the next step and open the vote at >> general@incubator.a.o >> > >> ;-) >> > >> >> > >> David has started discussing the issue with his Mentor status on Jan >> > >> 24. I'm waiting for that to be resolved. Not sure if there's any >> > >> progress. David, did they answer? Because then that wasn't CC-ed to >> > >> the private list. >> > > >> > > >> > > I got a reply from John D. Ament on Jan 24th saying he was sending >> > notice, >> > > but I haven't seen anything since and not sure if I should even expect >> > any >> > > sort of email notification or if it's something I'd have to hunt around >> > for >> > > or follow up on. >> > > >> > > FWIW I'm not on the Incubator PMC list yet (my ASF username is >> > 'jonesde'): >> > > >> > > http://people.apache.org/phonebook.html?pmc=incubator >> > > >> > > I also don't know if my failure to respond to John's email in June will >> > > cause any issues, or in general what to expect with all this so I >> really >> > > can't say much. >> > >> > If the process is like here, they have vote (at least 3 days), then >> > wait for 3 days so the board can veto the decision, and only then mail >> > you... I hope they have started the process. If they won't report back >> > in a few days, it would be good if you ask them. >> > >> > > -David >> > >> > -- >> > Thanks, >> > Daniel Dekany >> > >> > >> -- Thanks, Daniel Dekany
Re: Contributions?
Wednesday, January 31, 2018, 8:02:30 AM, jpr...@seznam.cz wrote: > Freemarker has been quite helpful in the medical documents product I am > working on. > > Is there an issue you would recommend for a new contributor who wants to > learn the code? > > Two issues interest me in particular: > Java 8 Time Support > Debugging and testing tools for people who write templates. There's a list of ideas on https://freemarker.apache.org/contribute.html. Java 8 time API support is one of them. Though it's far from the easiest thing to do, you can always give it a try. > Also not clear on whether it's better to contribute to Freemarker 2 or 3. Depends on what your goal/motivation is. - If you want to use your work in a product in the foreseeable future, then FM 2 is the only option. (However, anything that goes into 2 should be forward ported to 3, at least eventually.) - If you rather want to help FM's long term future, or want to hack/learn something in general, like solve some interesting problems, then FM3 it is. 3 is already cleaner than 2, and there are no backward compatibility constraints (which is a big problem in 2), more space for innovation, so it's a much more satisfying branch to work on. But 3 won't yield a production-ready release any time soon. The most important changes in the template language wasn't even started yet. > Thanks -- Thanks, Daniel Dekany
Re: [RESULT][VOTE] Graduate Apache FreeMarker Project from Incubator to TLP
Monday, January 29, 2018, 7:16:21 PM, David E Jones wrote: > On Mon, Jan 29, 2018 at 8:59 AM, Daniel Dekany <ddek...@apache.org> wrote: > >> Monday, January 29, 2018, 4:35:38 PM, Sergio Fernández wrote: >> >> > Great, Daniel! >> > >> > Let's move to the next step and open the vote at general@incubator.a.o >> ;-) >> >> David has started discussing the issue with his Mentor status on Jan >> 24. I'm waiting for that to be resolved. Not sure if there's any >> progress. David, did they answer? Because then that wasn't CC-ed to >> the private list. > > > I got a reply from John D. Ament on Jan 24th saying he was sending notice, > but I haven't seen anything since and not sure if I should even expect any > sort of email notification or if it's something I'd have to hunt around for > or follow up on. > > FWIW I'm not on the Incubator PMC list yet (my ASF username is 'jonesde'): > > http://people.apache.org/phonebook.html?pmc=incubator > > I also don't know if my failure to respond to John's email in June will > cause any issues, or in general what to expect with all this so I really > can't say much. If the process is like here, they have vote (at least 3 days), then wait for 3 days so the board can veto the decision, and only then mail you... I hope they have started the process. If they won't report back in a few days, it would be good if you ask them. > -David -- Thanks, Daniel Dekany
Re: [FM3] Question on CallPlace#executeNestedContent(...)
Monday, January 29, 2018, 11:20:02 PM, Woonsan Ko wrote:
> Hi,
>
> While implementing @form.errors directive (migrated from spring
> form:errors taglib), I ended up adding 'messages' nested parameter
> like the following example:
>
> <@form.errors '*'; messages>
> <#list messages as message>
> ${message}
>
>
>
> As spring's form:errors jsp tag allows default rendering when there's
> no nested body content, I found the following example doesn't look
> very convenient. With 'messages' omitted, I got a template exception.
>
> <@form.errors 'firstName'; messages /> # rendering the default error
> info markups..
>
> So, I wonder if there's a way to omit the 'messages' nested parameter.
> The javadocs of CallPlace#getNestedContentParameterCount() and
> #executeNestedContent() say about the possibility with less nested
> parameters somehow, but I can't figure out how to make it flexible in
> the directive.
>
> Please let me know if you have any hints.
I suppose nested content is allowed exactly if there's a nested
content argument (like `; message`). So you can decide if there's a
nested content argument with
CallPlace.getNestedContentParameterCount(), and if there isn't, then
you don't call CallPlace.executeNestedContent (but check if
CallPlace.hasNestedContent() returns `true`, in which case throw a
TemplateException that explains the problem), otherwise you call
CallPlace.executeNestedContent with 1 nested content argument.
Not sure if I'm missing something here. If not, what was the missing
piece? That information should be added to the API docs.
> Regards,
>
> Woonsan
--
Thanks,
Daniel Dekany
Re: [RESULT][VOTE] Graduate Apache FreeMarker Project from Incubator to TLP
Monday, January 29, 2018, 4:35:38 PM, Sergio Fernández wrote: > Great, Daniel! > > Let's move to the next step and open the vote at general@incubator.a.o ;-) David has started discussing the issue with his Mentor status on Jan 24. I'm waiting for that to be resolved. Not sure if there's any progress. David, did they answer? Because then that wasn't CC-ed to the private list. > On Jan 27, 2018 12:31, "Daniel Dekany" <ddek...@apache.org> wrote: > >> Vote on the podling mailing list on the Apache FreeMarker Project >> Resolution (graduate FreeMarker to TLP) passed with the following >> results: 4 "+1" votes from IPMC members (also 3 "+1" from other PPMC >> members, and 2 "+1" from non-members), no "0" votes, no "-1" votes. >> Thus, a similar graduation vote will be soon follow (within days >> hopefully) on gene...@incubator.apache.org. >> >> The votes were: >> Jacopo Cappellato +1 (binding) >> Jacques Le Roux +1 (binding) >> Ralph Goers +1 (binding) >> Sergio Fernández +1 (binding) >> Dániel Dékány +1 non-binding PPMC >> David E Jones +1 non-binding PPMC >> Woonsan Ko +1 non-binding PPMC >> Barrie Selack +1 non-binding non-PPMC >> Piyush Mor +1 non-binding non-PPMC >> >> Thank you for your participation! >> >> The initial vote mail that contains the Resolution: >> https://lists.apache.org/thread.html/e85c72b2a7644005ff44d144e08807 >> 362e0461a5f854a1f691a960db@%3Cdev.freemarker.apache.org%3E >> >> Vote mails: >> https://lists.apache.org/thread.html/4021085e88c35ea254e4a15e7320f1 >> bf3d09a5562913edbd7c00d0c6@%3Cdev.freemarker.apache.org%3E >> https://lists.apache.org/thread.html/07d6cff8f5616459d41bf8a6c77c17 >> 332c6783b137e1b23132bcb6f3@%3Cdev.freemarker.apache.org%3E >> https://lists.apache.org/thread.html/d2852a2cad7b1e46e50cd0ee377020 >> 9acfbce761799378a822c23bb3@%3Cdev.freemarker.apache.org%3E >> https://lists.apache.org/thread.html/d7c03d0cce4741f502f06ed591b9f9 >> a1180cf79d5473e200d7ee8d6a@%3Cdev.freemarker.apache.org%3E >> https://lists.apache.org/thread.html/e9da0c97bed4ea27f17aae46f98382 >> 8079574a9b6dc517d4080010ea@%3Cdev.freemarker.apache.org%3E >> https://lists.apache.org/thread.html/8af3367437eda9fb5839a02b7a7746 >> 146ad8df23847c807a1e34f6bf@%3Cdev.freemarker.apache.org%3E >> https://lists.apache.org/thread.html/9709c8d5fc7feb953503d201f3cb0a >> 94eb6140cfc707fe71596102f3@%3Cdev.freemarker.apache.org%3E >> https://lists.apache.org/thread.html/2d91983f12c38fb4b3eb3f973c9d80 >> 0142ea50627515bb871a5dfe1c@%3Cdev.freemarker.apache.org%3E >> https://lists.apache.org/thread.html/3dfbe985c1a68e7fcfe77d34385e3b >> f5ef0766b4239d0a22bf528810@%3Cdev.freemarker.apache.org%3E >> >> -- >> Thanks, >> Daniel Dekany >> >> -- Thanks, Daniel Dekany
[RESULT][VOTE] Graduate Apache FreeMarker Project from Incubator to TLP
Vote on the podling mailing list on the Apache FreeMarker Project Resolution (graduate FreeMarker to TLP) passed with the following results: 4 "+1" votes from IPMC members (also 3 "+1" from other PPMC members, and 2 "+1" from non-members), no "0" votes, no "-1" votes. Thus, a similar graduation vote will be soon follow (within days hopefully) on gene...@incubator.apache.org. The votes were: Jacopo Cappellato +1 (binding) Jacques Le Roux +1 (binding) Ralph Goers +1 (binding) Sergio Fernández +1 (binding) Dániel Dékány +1 non-binding PPMC David E Jones +1 non-binding PPMC Woonsan Ko +1 non-binding PPMC Barrie Selack +1 non-binding non-PPMC Piyush Mor +1 non-binding non-PPMC Thank you for your participation! The initial vote mail that contains the Resolution: https://lists.apache.org/thread.html/e85c72b2a7644005ff44d144e08807362e0461a5f854a1f691a960db@%3Cdev.freemarker.apache.org%3E Vote mails: https://lists.apache.org/thread.html/4021085e88c35ea254e4a15e7320f1bf3d09a5562913edbd7c00d0c6@%3Cdev.freemarker.apache.org%3E https://lists.apache.org/thread.html/07d6cff8f5616459d41bf8a6c77c17332c6783b137e1b23132bcb6f3@%3Cdev.freemarker.apache.org%3E https://lists.apache.org/thread.html/d2852a2cad7b1e46e50cd0ee3770209acfbce761799378a822c23bb3@%3Cdev.freemarker.apache.org%3E https://lists.apache.org/thread.html/d7c03d0cce4741f502f06ed591b9f9a1180cf79d5473e200d7ee8d6a@%3Cdev.freemarker.apache.org%3E https://lists.apache.org/thread.html/e9da0c97bed4ea27f17aae46f983828079574a9b6dc517d4080010ea@%3Cdev.freemarker.apache.org%3E https://lists.apache.org/thread.html/8af3367437eda9fb5839a02b7a7746146ad8df23847c807a1e34f6bf@%3Cdev.freemarker.apache.org%3E https://lists.apache.org/thread.html/9709c8d5fc7feb953503d201f3cb0a94eb6140cfc707fe71596102f3@%3Cdev.freemarker.apache.org%3E https://lists.apache.org/thread.html/2d91983f12c38fb4b3eb3f973c9d800142ea50627515bb871a5dfe1c@%3Cdev.freemarker.apache.org%3E https://lists.apache.org/thread.html/3dfbe985c1a68e7fcfe77d34385e3bf5ef0766b4239d0a22bf528810@%3Cdev.freemarker.apache.org%3E -- Thanks, Daniel Dekany
Re: compress vs. pre/code
Friday, January 26, 2018, 4:37:57 PM, Riehemann, Michael wrote:
> Hi Freemarker Devs,
>
> I'm not sure if this is a bug or feature request about the compress directive.
>
> Example:
>
> <#compress>
>
>
>
> #maybe a code example
> With 4 whitespaces in every line
>
>
>
>
> Problem:
> The whitespace in the Tag is removed and will change the
> layout of it. Same for . This is bad for code examples and
> breaks the concept of and . Since we always use
> <#compress> in our outer template, you never have a change to avoid it.
>
> Ideas:
> 1. Fix it as a bug and skip and in compress.
> 2. Add a new feature like <#nocompress/>
>
> What do you think?
FreeMarker doesn't try to interpret the static content. It doesn't
know what HTML is. It's just not that kind of template engine. So that
leaves us with idea 2. But, I think a 3rd one would be the best. As
#compress is just Writer filter basically (it doesn't remove
whitespace during the parsing phase), you just need a more
intelligent, HTML-aware FilterWriter. Especially as you do this for all
templates, can't you just pass a such Writer to Template.process? Then
the templates aren't polluted with that boilerplate. (If some templates
doesn't need it, something like <#ftl attributes = { 'compress': false }>
could be used.)
> -Michael Riehemann
--
Thanks,
Daniel Dekany
Re: Test fails with locale using comma as decimal separator
Thanks! (Please close the PR.) Monday, January 22, 2018, 4:08:27 PM, Mauricio Nuñez wrote: > Tested! It's working now without my patch. > > Regards! > > > > 2018-01-22 11:46 GMT-03:00 Daniel Dekany <ddek...@apache.org>: > >> Good catch, however, I rather fix this kind of problem at its root, >> and initialize the locale to en_US, and also the time zone etc., for >> all "templatesuite" tests (see my commit). Can you confirm that now >> the test passes without your patch? >> >> >> Monday, January 22, 2018, 2:16:08 PM, Mauricio Nuñez wrote: >> >> > Hi! >> > >> > I've created a PR ( 1 line ). >> > With my local setup ( es_CL ) , the test suite is reporting an error. >> > My approach is to define a fixed locale for that test execution. >> > >> > https://github.com/apache/incubator-freemarker/pull/43 >> > >> > Regards, >> > >> > Mauricio >> >> -- >> Thanks, >> Daniel Dekany >> >> -- Thanks, Daniel Dekany
Re: Test fails with locale using comma as decimal separator
Good catch, however, I rather fix this kind of problem at its root, and initialize the locale to en_US, and also the time zone etc., for all "templatesuite" tests (see my commit). Can you confirm that now the test passes without your patch? Monday, January 22, 2018, 2:16:08 PM, Mauricio Nuñez wrote: > Hi! > > I've created a PR ( 1 line ). > With my local setup ( es_CL ) , the test suite is reporting an error. > My approach is to define a fixed locale for that test execution. > > https://github.com/apache/incubator-freemarker/pull/43 > > Regards, > > Mauricio -- Thanks, Daniel Dekany
Re: Status file date issues
Thanks for the feedback! I say we will wait. Monday, January 22, 2018, 7:46:23 AM, David E Jones wrote: > My apologies, I'm way overloaded right now and will be for at least the > next couple of days. If this can't wait a few more days I'd say just remove > me from the mentor list, but I'll get to it by mid-week. > > -David > > > On Fri, Jan 19, 2018 at 2:11 AM, Jacques Le Roux < > jacques.le.r...@les7arts.com> wrote: > >> Le 19/01/2018 à 07:54, Jacopo Cappellato a écrit : >> >>> Daniel Dekany <ddek...@apache.org> wrote: >>>>> >>>> So, David, can >>> >>>> you join the IPMC? I know, it's annoying and all, but rule are rules. >>>> >>>> David, since you are an ASF member you can simply send an email to the >>> general@incubator list asking to be added to the IPMC. >>> >>> Jacopo >>> >>> David, >> >> You can easily remove yourself from IPMC after if you want, you just need >> to send a request email :) >> >> Jacques >> >> -- Thanks, Daniel Dekany
Re: Status file date issues
Thursday, January 18, 2018, 5:20:23 PM, Jacopo Cappellato wrote: > On Thu, Jan 18, 2018 at 4:59 PM, Daniel Dekany <ddek...@apache.org> wrote: > >> Can someone help with this? Especially, Jacopo, do you have the record >> for some events here (see the "date" column of the tables): >> >> http://incubator.apache.org/projects/freemarker.html >> >> I have added some months ago a few dates, like "2015-10-07 (or >> earlier)". That I guess will not be good enough on the >> general@incubator list (and if we are lucky, for the Board). > > > I don't have the exact dates but I am confident that what you have entered > will be fine: the status page is a useful document to get a quick overview > of the status of the project but nothing more than this. Um... OK. (Or, let that be the biggest problem.) >> Also, I >> have just filled "Add all active committers in the STATUS file" to >> 2015-07-06, based on the SVN commit log of freemarker.xml, while >> "Check that all active committers have submitted a contributors >> agreement" still says "2015-10-07 (or earlier)". Was that initial SVN >> commit done after the contributor aggrements were checked done? > > > Yes, I think you are correct. Since then, all new committers have been > invited only after receiving the ICLA so there is no need to update that > date. No, that means that "Check that all active committers have submitted a contributors agreement" should be modified to "2015-07-06 (or earlier)". >> Does >> "STATUS file" refer to freemarker.xml at all? >> > > Yes, it is the document itself; we have just to make sure that the list in > it is accurate; this is what we have listed in the status page: > > Mentors > jacopoc Jacopo Cappellato > jfclere Jean-Frederic Clere > jonesde David E. Jones > rgoers Ralph Goers > wikier Sergio Fernández > > Committers > ddekany Dániel Dékány > edendramis Evangelia Dendramis > jleroux Jacques Le Roux > nanlei Nan Lei > woonsan Woonsan Ko It's not, as David E. Jones can't be a Mentor as far as he's not an IPMC member. I don't want to generate problems here, but I have seen some signs that tells me that some IPMC members will most certainly express their concerns (and might build a case on it). So, David, can you join the IPMC? I know, it's annoying and all, but rule are rules. >> Yeah, I know, very exciting... ;) but need to be done. >> > > Yeah... excited to be here :-) I think the document is good to go. > > Jacopo > > >> >> -- >> Thanks, >> Daniel Dekany >> >> -- Thanks, Daniel Dekany
Status file date issues
Can someone help with this? Especially, Jacopo, do you have the record for some events here (see the "date" column of the tables): http://incubator.apache.org/projects/freemarker.html I have added some months ago a few dates, like "2015-10-07 (or earlier)". That I guess will not be good enough on the general@incubator list (and if we are lucky, for the Board). Also, I have just filled "Add all active committers in the STATUS file" to 2015-07-06, based on the SVN commit log of freemarker.xml, while "Check that all active committers have submitted a contributors agreement" still says "2015-10-07 (or earlier)". Was that initial SVN commit done after the contributor aggrements were checked done? Does "STATUS file" refer to freemarker.xml at all? Yeah, I know, very exciting... ;) but need to be done. -- Thanks, Daniel Dekany
Re: [VOTE] Graduate Apache FreeMarker Project from Incubator to TLP
+1 non-binding PPMC Saturday, January 13, 2018, 10:31:41 AM, Daniel Dekany wrote: > Dear FreeMarker Community Members, > > Following the discussion on this list > (dev@freemarker.incubator.apache.org) on graduating the Apache > FreeMarker Project from Incubation to a Top Level Project, I start > this voting thread. > > Project status information: > - Status page: http://incubator.apache.org/projects/freemarker.html > - Project Maturity Model: > > https://cwiki.apache.org/confluence/display/FREEMARKER/Apache+FreeMarker+Project+Maturity+Model > > Please vote on the Apache FreeMarker Project resolution that is found > at the bottom of this mail. > > [ ] +1 Graduate Apache FreeMarker from the Incubator. > [ ] +0 No opinion > [ ] -1 Don't graduate Apache FreeMarker from the Incubator (please >provide the reason) > > The vote is open for a minimum of 72 hours. Please don't hesitate to > indicate if you need more time to check graduation requirements. In > order to succeed, 3 positive votes from PPMC members, and no vetoes > from PPMC member are required. > > If this VOTE succeeds, a similar VOTE will be started on the > gene...@incubator.apache.org mailing list. If that succeeds, a > resolution will be included in the next Apache Board Meeting. > > Thanks all for your participation > Daniel Dekany > > --- > > Establish the Apache FreeMarker Project > > WHEREAS, the Board of Directors deems it to be in the best > interests of the Foundation and consistent with the > Foundation's purpose to establish a Project Management > Committee charged with the creation and maintenance of > open-source software, for distribution at no charge to > the public, related to a template engine. > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management > Committee (PMC), to be known as the "Apache FreeMarker Project", > be and hereby is established pursuant to Bylaws of the > Foundation; and be it further > > RESOLVED, that the Apache FreeMarker Project be and hereby is > responsible for the creation and maintenance of software > related to a template engine, and be it further > > RESOLVED, that the office of "Vice President, Apache FreeMarker" be > and hereby is created, the person holding such office to > serve at the direction of the Board of Directors as the chair > of the Apache FreeMarker Project, and to have primary responsibility > for management of the projects within the scope of > responsibility of the Apache FreeMarker Project; and be it further > > RESOLVED, that the persons listed immediately below be and > hereby are appointed to serve as the initial members of the > Apache FreeMarker Project: > > * Dániel Dékány <ddek...@apache.org> > * David E. Jones <jone...@apache.org> > * Jacopo Cappellato <jaco...@apache.org> > * Jacques Le Roux <jler...@apache.org> > * Nan Lei <nan...@apache.org> > * Sergio Fernández<wik...@apache.org> > * Woonsan Ko <woon...@apache.org> > > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Dániel Dékány > be appointed to the office of Vice President, Apache FreeMarker, > to serve in accordance with and subject to the direction of the > Board of Directors and the Bylaws of the Foundation until > death, resignation, retirement, removal or disqualification, > or until a successor is appointed; and be it further > > RESOLVED, that the Apache FreeMarker Project be and hereby > is tasked with the migration and rationalization of the Apache > Incubator FreeMarker podling; and be it further > > RESOLVED, that all responsibilities pertaining to the Apache > Incubator FreeMarker podling encumbered upon the Apache Incubator > Project are hereafter discharged. > > -- Thanks, Daniel Dekany
[VOTE] Graduate Apache FreeMarker Project from Incubator to TLP
Dear FreeMarker Community Members, Following the discussion on this list (dev@freemarker.incubator.apache.org) on graduating the Apache FreeMarker Project from Incubation to a Top Level Project, I start this voting thread. Project status information: - Status page: http://incubator.apache.org/projects/freemarker.html - Project Maturity Model: https://cwiki.apache.org/confluence/display/FREEMARKER/Apache+FreeMarker+Project+Maturity+Model Please vote on the Apache FreeMarker Project resolution that is found at the bottom of this mail. [ ] +1 Graduate Apache FreeMarker from the Incubator. [ ] +0 No opinion [ ] -1 Don't graduate Apache FreeMarker from the Incubator (please provide the reason) The vote is open for a minimum of 72 hours. Please don't hesitate to indicate if you need more time to check graduation requirements. In order to succeed, 3 positive votes from PPMC members, and no vetoes from PPMC member are required. If this VOTE succeeds, a similar VOTE will be started on the gene...@incubator.apache.org mailing list. If that succeeds, a resolution will be included in the next Apache Board Meeting. Thanks all for your participation Daniel Dekany --- Establish the Apache FreeMarker Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software, for distribution at no charge to the public, related to a template engine. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the "Apache FreeMarker Project", be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache FreeMarker Project be and hereby is responsible for the creation and maintenance of software related to a template engine, and be it further RESOLVED, that the office of "Vice President, Apache FreeMarker" be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache FreeMarker Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache FreeMarker Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache FreeMarker Project: * Dániel Dékány <ddek...@apache.org> * David E. Jones <jone...@apache.org> * Jacopo Cappellato <jaco...@apache.org> * Jacques Le Roux <jler...@apache.org> * Nan Lei <nan...@apache.org> * Sergio Fernández<wik...@apache.org> * Woonsan Ko <woon...@apache.org> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Dániel Dékány be appointed to the office of Vice President, Apache FreeMarker, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the Apache FreeMarker Project be and hereby is tasked with the migration and rationalization of the Apache Incubator FreeMarker podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator FreeMarker podling encumbered upon the Apache Incubator Project are hereafter discharged.
Re: Resolution draft for graduation, members
I will add Nan Lei to the members on the Resolution, if you agree. While he didn't commit since the translation for 2.3.23 was donated, he might finds time to update it in the future. (He will be a Committer, not a PMC member, most certainly.) Other than that, I assume the proposed membership and chair won't change for now. We can these before the vote in general@i.a.o anyway. Monday, January 8, 2018, 5:24:02 PM, Jacques Le Roux wrote: > I agree with this description. Another important aspect is to keep > focused on the project, not miss anything about it and be ready to answer to > the > board and other outsiders. > > That's why I think Daniel is the best person for this role at this > moment, when the project is just starting. > > Because he not only knows the project better than anyone else, but > he is also ready to deliver not only code and advices but also administrative > tasks > as he already well proved. > > Jacques > > > Le 08/01/2018 à 16:58, Ralph Goers a écrit : >> Please remember that the role of PMC chair doesn’t have much to do with how >> much you commit or perform other project tasks. As you will see at >> https://www.apache.org/dev/pmc.html#chair >> <https://www.apache.org/dev/pmc.html#chair> the role is more secretarial >> than anything else. There should be no expectation that the PMC chair is the >> “leader” of the project although they do have responsibilities that other >> PMC members do not. That said, if a PMC chair is indisposed another PMC >> member should be ready to submit the board report in their absence. >> >> You should not be thinking of the PMC chair as being the person who most >> “deserves” it, but the person who has the time to participate in the other >> mailing lists and perform the tasks of the job. >> >> Ralph >> >>> On Jan 8, 2018, at 2:18 AM, Taher Alkhateeb <slidingfilame...@gmail.com> >>> wrote: >>> >>> I'm not highly involved in this project but I thought I'd make a comment >>> from my brief experience. Daniel to me seems to be a heavy duty lifter. I >>> was surprised at how fast he got features and code committed. In addition I >>> think he has a clear vision for the project and its roadmap. He is open to >>> ideas and cares about the project and wants to build a community. To me >>> this makes him a good candidate. >>> >>> I am not the most active here so I apologize if my comments are out of >>> place. Just my 2 cents. >>> >>> Cheers, >>> >>> Taher Alkhateeb >>> >>> On Jan 8, 2018 12:06 PM, "Daniel Dekany" <ddek...@apache.org> wrote: >>> >>> Monday, January 8, 2018, 6:30:33 AM, Ralph Goers wrote: >>> >>>> You would probably be better served by having someone else >>>> volunteer to be PMC chair. My reasoning for that is exactly for the >>>> same reason you put yourself there. You are the most active >>>> committer and obviously aren’t going anywhere. Having someone else >>>> be chair insures that someone else is staying fairly involved in the >>>> activities of the project, even if they aren’t the most active >>>> committer. You need at least 3 active PMC members so use any >>>> opportunity you can to make sure you stay above that mark. >>> Since it's a voluntarily position, let's see who wants that >>> responsibility. Guys, anyone wants to be a PMC chair if the project >>> graduates? >>> >>>> Ralph >>>> >>>>> On Jan 7, 2018, at 1:08 PM, David E Jones <d...@dejc.com> wrote: >>>>> >>>>> Looks good Daniel, may it be resolved! >>>>> >>>>> -David >>>>> >>>>> On Fri, Jan 5, 2018 at 1:08 PM, Daniel Dekany <ddek...@apache.org> wrote: >>>>> >>>>>> Here's the Resolution you will vote on (at least that's my plan) in >>>>>> the graduation VOTE here on the poddling list. Anyone sees any >>>>>> oversight in it? >>>>>> >>>>>> As of the list of project members, I have listed everyone who said >>>>>> that he/she intends to stay so far. Anyone else? In the current list, >>>>>> everyone intends to be in the PMC as well. >>>>>> >>>>>> About the "be appointed to the office of Vice President" thing. Who >>>>>> should be it? I have written there myself for now, as I'm by far the >>>>>> most involved with the project. But
Re: Resolution draft for graduation, members
Monday, January 8, 2018, 6:30:33 AM, Ralph Goers wrote: > You would probably be better served by having someone else > volunteer to be PMC chair. My reasoning for that is exactly for the > same reason you put yourself there. You are the most active > committer and obviously aren’t going anywhere. Having someone else > be chair insures that someone else is staying fairly involved in the > activities of the project, even if they aren’t the most active > committer. You need at least 3 active PMC members so use any > opportunity you can to make sure you stay above that mark. Since it's a voluntarily position, let's see who wants that responsibility. Guys, anyone wants to be a PMC chair if the project graduates? > Ralph > >> On Jan 7, 2018, at 1:08 PM, David E Jones <d...@dejc.com> wrote: >> >> Looks good Daniel, may it be resolved! >> >> -David >> >> On Fri, Jan 5, 2018 at 1:08 PM, Daniel Dekany <ddek...@apache.org> wrote: >> >>> Here's the Resolution you will vote on (at least that's my plan) in >>> the graduation VOTE here on the poddling list. Anyone sees any >>> oversight in it? >>> >>> As of the list of project members, I have listed everyone who said >>> that he/she intends to stay so far. Anyone else? In the current list, >>> everyone intends to be in the PMC as well. >>> >>> About the "be appointed to the office of Vice President" thing. Who >>> should be it? I have written there myself for now, as I'm by far the >>> most involved with the project. But maybe someone else fits that role >>> better. I don't fancy titles, no offense taken in that case. >>> >>> And, as always... if you can, please check if we miss any formal >>> requirements for graduation! >>> >>> >>> >>> Establish the Apache FreeMarker Project >>> >>> WHEREAS, the Board of Directors deems it to be in the best >>> interests of the Foundation and consistent with the >>> Foundation's purpose to establish a Project Management >>> Committee charged with the creation and maintenance of >>> open-source software, for distribution at no charge to >>> the public, related to a template engine. >>> >>> NOW, THEREFORE, BE IT RESOLVED, that a Project Management >>> Committee (PMC), to be known as the "Apache FreeMarker Project", >>> be and hereby is established pursuant to Bylaws of the >>> Foundation; and be it further >>> >>> RESOLVED, that the Apache FreeMarker Project be and hereby is >>> responsible for the creation and maintenance of software >>> related to a template engine, and be it further >>> >>> RESOLVED, that the office of "Vice President, Apache FreeMarker" be >>> and hereby is created, the person holding such office to >>> serve at the direction of the Board of Directors as the chair >>> of the Apache FreeMarker Project, and to have primary responsibility >>> for management of the projects within the scope of >>> responsibility of the Apache FreeMarker Project; and be it further >>> >>> RESOLVED, that the persons listed immediately below be and >>> hereby are appointed to serve as the initial members of the >>> Apache FreeMarker Project: >>> >>> * Dániel Dékány <ddek...@apache.org> >>> * David E. Jones <jone...@apache.org> >>> * Jacopo Cappellato <jaco...@apache.org> >>> * Jacques Le Roux <jler...@apache.org> >>> * Sergio Fernández<wik...@apache.org> >>> * Woonsan Ko <woon...@apache.org> >>> >>> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Dániel Dékány >>> be appointed to the office of Vice President, Apache FreeMarker, >>> to serve in accordance with and subject to the direction of the >>> Board of Directors and the Bylaws of the Foundation until >>> death, resignation, retirement, removal or disqualification, >>> or until a successor is appointed; and be it further >>> >>> RESOLVED, that the Apache FreeMarker Project be and hereby >>> is tasked with the migration and rationalization of the Apache >>> Incubator FreeMarker podling; and be it further >>> >>> RESOLVED, that all responsibilities pertaining to the Apache >>> Incubator FreeMarker podling encumbered upon the Apache Incubator >>> Project are hereafter discharged. >>> >>> -- >>> Thanks, >>> Daniel Dekany >>> >>> > > > -- Thanks, Daniel Dekany
Re: try.freemarker.apache.org instead of try.freemarker.org?
Greg commented on the request: try.freemarker.apache.org now works, and is propagated. Since that hostname maps to your VM, the certificate to be used for try.freemarker.apache.org will need to be hosted/operated by your VM. Infra's current policy for project VMs is to use LetsEncrypt for certificates. [~pono] will get you set up with that. Wednesday, January 3, 2018, 11:34:32 PM, Jacques Le Roux wrote: > Good, Greg closed INFRA-15476 > > Jacques > > Le 03/01/2018 à 21:23, Daniel Dekany a écrit : >> I'm "a bit" late with this, but I have created the issue for it: >> https://issues.apache.org/jira/servicedesk/agent/INFRA/issue/INFRA-15775 >> >> >> Friday, December 15, 2017, 1:57:04 PM, Daniel Dekany wrote: >> >>> To summarize, the opininos were (whether we should switch to >>> try.freemarker.apache.org): >>> - Daniel Dekany: We better not risk not doing this >>> - Jacopo Cappellato: Agrees with me (above) in this >>> - Jacques Le Roux: No opinion was expressed, but it's technically fine >>> - Ralph Goers: It's certainly not necessary to do >>> >>> So, unless someone has more to add, I will ask this from Infra in the >>> coming days... just to be on the safe side. >>> >>> Wednesday, November 29, 2017, 6:38:05 PM, Ralph Goers wrote: >>> >>>> The difference is that try.freemarker.org >>>> <http://try.freemarker.org/> is a companion site. So long as the >>>> main site is freemarker.apache.org I don’t think anyone will complain >>>> about a companion site. >>>> >>>> Ralph >>>> >>>>> On Nov 29, 2017, at 8:33 AM, Jacques Le Roux >>>>> <jacques.le.r...@les7arts.com> wrote: >>>>> >>>>> Hi Ralph, >>>>> >>>>> IIRW openoffice.org is an exception. There are others, when the domain >>>>> was well established before entering the incubator, subversion.org comes >>>>> to mind. >>>>> >>>>> IMO freemarker.org was well established before entering the incubator but >>>>> not try.freemarker.apache.org which is quite recent. Hence maybe some >>>>> caution needed... >>>>> >>>>> My 2 cts >>>>> >>>>> Jacques >>>>> >>>>> >>>>> Le 29/11/2017 à 14:55, Ralph Goers a écrit : >>>>>> Personally, I don’t see why there should be a problem as long as >>>>>> try.freemarker.org <http://try.freemarker.org/> is an Apache controlled >>>>>> domain. You aren’t the only project that has a vanity domain. See >>>>>> www.openoffice.org <http://www.openoffice.org/> as an example. >>>>>> >>>>>> Ralph >>>>>> >>>>>>> On Nov 29, 2017, at 1:51 AM, Daniel Dekany <ddek...@apache.org> wrote: >>>>>>> >>>>>>> Just as a reminder, I'm planning to request try.freemarker.apache.org, >>>>>>> from Infra and then redirect try.freemarker.org to it, because I'm >>>>>>> worried that the IPMC will dislike that we use try.freemarker.org as >>>>>>> the canonical address of the online template tester. It will also use >>>>>>> https and a LetsEncrypt certificate (we can't use the *.apache.org >>>>>>> cert on a VM). >>>>>>> >>>>>>> BTW, using a sub-sub domains is a bit extreme. I'm not aware of any >>>>>>> gotchas in out case, but if anyone is aware some, like LetsEncrypt >>>>>>> doesn't support them or something, please stop me! (Also, as this way >>>>>>> we will receive the cookies of freemarker.apache.org, but certainly we >>>>>>> will able to cope with that, if it ever causes a problem.) >>>>>>> >>>>>>> Any comments? And do you (especially PPMC members) agree? >>>>>>> >>>>>>> -- >>>>>>> Thanks, >>>>>>> Daniel Dekany >>>>>>> >>>>>>> >>>>> > -- Thanks, Daniel Dekany
Re: freemarker.org is gone...
OK, it works again. They switched nameservers, it was a transient. Sunday, January 7, 2018, 1:30:35 PM, Daniel Dekany wrote: > It's unknown host now, and hence try.freemarker.org is as well. I have > opened an Infra issue for it. Let's hope it's just accidental and will > be resolved. > > https://issues.apache.org/jira/servicedesk/agent/INFRA/issue/INFRA-15800 > -- Thanks, Daniel Dekany
Re: [FM3] Continuing Spring MVC Form Directives Support
Thanks! Note that I have committed some related JavaDoc improvements. Saturday, January 6, 2018, 5:38:51 AM, Woonsan Ko wrote: > On Fri, Jan 5, 2018 at 3:31 PM, Daniel Dekany <ddek...@apache.org> wrote: >> Friday, January 5, 2018, 8:34:42 PM, Woonsan Ko wrote: >> >>> On Thu, Jan 4, 2018 at 6:13 PM, Daniel Dekany <ddek...@apache.org> wrote: >>>> Thursday, January 4, 2018, 9:01:24 PM, Woonsan Ko wrote: >>>> >>>> [snip] >>>>>> Maybe, instead of >>>>>> SomeSuperTemplateDirectiveModel.NAMED_ARGS_ENTRY_LIST, your could >>>>>> just expose ARGS_LAYOUT, and get the highest named argument index >>>>>> from that. Then NAMED_ARGS_ENTRY_LIST need not exist at all >>>>>> (especially as a List instead of as an array), unless I miss >>>>>> something there. >>>>> >>>>> I change the list to array and mark it as private, exposing >>>>> ARGS_LAYOUT only, as you suggested. Now, it's cleaner. >>>>> As the Entry array of parent directive class needs to be prepended to >>>>> the predefinedNamedArgumentsMap (StringToIndexMap) in the child, I >>>>> added StringToIndexMap#getInputEntries(). Hope it should be fine. >>>> >>>> I believe the concatenated Entry[] array shouldn't be constructed in >>>> the custom directive (with _ArrayUtils.addAll and getInputEntries()) >>>> on the first place. Such low level things could be pushed on >>>> StringToIndexMap. StringToIndexMap could have a constructor method >>>> like `of(StringToIndexMap inherited, Entry... additionalEntries)`. >>>> This constructs a concatenated Entry[] internally (see >>>> StringToIndexMap.checkIndexRange to see how to traverse all inherited >>>> entries efficiently), and calls `of(Entry... entries)` with it. Now >>>> the need for `inputEntries` is gone as well. In the custom directive >>>> you just call this new overload of `StringToIndexMap.of`, instead of >>>> the usual `StringToIndexMap.of`. So it looks almost the same as when >>>> there's no named parameter inheritance. >>> >>> Yes. That's where I was a bit doubtful in the first place, I fixed it >>> based on your suggestion. >> >> Small thing, but in the new `of` method you could get away just with a >> single array, without creating a List and the converting it back to an >> array. > > Nice catch! > >> >>>> Also, I think NAMED_ARGS_ENTRIES can be removed; you can just call >>>> `StringToIndexMap.of` directly in the ArgumentArrayLayout.create >>>> parameter. >>> >>> Done as well. >>> >>>> >>>> I wonder if you should just move getLastPredefinedNamedArgumentIndex() >>>> into ArgumentArrayLayout. Or if not, into CallableUtils at least. The >>>> problem is not specific to Spring after all. >>> >>> Due to the assumption described in the javadoc, I moved it to >>> CallableUtils. All the callable implementation could understand the >>> assumptions. >> >> Couldn't it simply give the correct result for all possible >> ArgumentArrayLayout, instead of assuming things though? Also, now that >> I'm thinking about it, it should rather be >> getPredefinedNamedArgumentsEndIndex, with an exclusive end, otherwise >> it will be strange when there are 0 predefined named arguments. > > You're right. I overlooked the javadoc of ArgumentArrayLayout#create() > for the predefinedNamedArgumentsMap param which has already contained > the hint. > And, yes, ArgumentArrayLyaout#getPredefinedNamedArgumentsEndIndex() is better. > I pushed two commits to fix those. > > Thanks, > > Woonsan > >> >>> Cheers, >>> >>> Woonsan >>> >>>> >>>>>>> - spring:* tags are mapped to "spring.*" models, whereas form:* tags >>>>>>> are mapped to "spring.form.*" models. I didn't want to expose "form" >>>>>>> model separately in a higher level. I found out it's convenient to >>>>>>> write <#assign form=spring.form /> in order to use <@form.input .../> >>>>>>> instead of <@spring.form.input .../>. >>>>>> >>>>>> While that's the theoretically correct way, I think people will either >>>>>> end up starting the templates with <#assign form=spring.form />, or >>>>>> dislike FreeMarker for forcing
Resolution draft for graduation, members
Here's the Resolution you will vote on (at least that's my plan) in the graduation VOTE here on the poddling list. Anyone sees any oversight in it? As of the list of project members, I have listed everyone who said that he/she intends to stay so far. Anyone else? In the current list, everyone intends to be in the PMC as well. About the "be appointed to the office of Vice President" thing. Who should be it? I have written there myself for now, as I'm by far the most involved with the project. But maybe someone else fits that role better. I don't fancy titles, no offense taken in that case. And, as always... if you can, please check if we miss any formal requirements for graduation! Establish the Apache FreeMarker Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software, for distribution at no charge to the public, related to a template engine. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the "Apache FreeMarker Project", be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache FreeMarker Project be and hereby is responsible for the creation and maintenance of software related to a template engine, and be it further RESOLVED, that the office of "Vice President, Apache FreeMarker" be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache FreeMarker Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache FreeMarker Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache FreeMarker Project: * Dániel Dékány <ddek...@apache.org> * David E. Jones <jone...@apache.org> * Jacopo Cappellato <jaco...@apache.org> * Jacques Le Roux <jler...@apache.org> * Sergio Fernández<wik...@apache.org> * Woonsan Ko <woon...@apache.org> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Dániel Dékány be appointed to the office of Vice President, Apache FreeMarker, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the Apache FreeMarker Project be and hereby is tasked with the migration and rationalization of the Apache Incubator FreeMarker podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator FreeMarker podling encumbered upon the Apache Incubator Project are hereafter discharged. -- Thanks, Daniel Dekany
Re: [FM3] Continuing Spring MVC Form Directives Support
Thursday, January 4, 2018, 9:01:24 PM, Woonsan Ko wrote: [snip] >> Maybe, instead of >> SomeSuperTemplateDirectiveModel.NAMED_ARGS_ENTRY_LIST, your could >> just expose ARGS_LAYOUT, and get the highest named argument index >> from that. Then NAMED_ARGS_ENTRY_LIST need not exist at all >> (especially as a List instead of as an array), unless I miss >> something there. > > I change the list to array and mark it as private, exposing > ARGS_LAYOUT only, as you suggested. Now, it's cleaner. > As the Entry array of parent directive class needs to be prepended to > the predefinedNamedArgumentsMap (StringToIndexMap) in the child, I > added StringToIndexMap#getInputEntries(). Hope it should be fine. I believe the concatenated Entry[] array shouldn't be constructed in the custom directive (with _ArrayUtils.addAll and getInputEntries()) on the first place. Such low level things could be pushed on StringToIndexMap. StringToIndexMap could have a constructor method like `of(StringToIndexMap inherited, Entry... additionalEntries)`. This constructs a concatenated Entry[] internally (see StringToIndexMap.checkIndexRange to see how to traverse all inherited entries efficiently), and calls `of(Entry... entries)` with it. Now the need for `inputEntries` is gone as well. In the custom directive you just call this new overload of `StringToIndexMap.of`, instead of the usual `StringToIndexMap.of`. So it looks almost the same as when there's no named parameter inheritance. Also, I think NAMED_ARGS_ENTRIES can be removed; you can just call `StringToIndexMap.of` directly in the ArgumentArrayLayout.create parameter. I wonder if you should just move getLastPredefinedNamedArgumentIndex() into ArgumentArrayLayout. Or if not, into CallableUtils at least. The problem is not specific to Spring after all. >>> - spring:* tags are mapped to "spring.*" models, whereas form:* tags >>> are mapped to "spring.form.*" models. I didn't want to expose "form" >>> model separately in a higher level. I found out it's convenient to >>> write <#assign form=spring.form /> in order to use <@form.input .../> >>> instead of <@spring.form.input .../>. >> >> While that's the theoretically correct way, I think people will either >> end up starting the templates with <#assign form=spring.form />, or >> dislike FreeMarker for forcing them to write "spring.form" again and >> again. Then it's better just to expose "form" directly. > > Makes sense. I updated that. > >> >>> - The other (remaining) tasks seem to be relatively more >>> straightforward: other inputs, button, textarea, select, etc. >> >> Something I have noticed that the Spring JSP taglib uses >> all-lower-case convention for attributes, like "onselect" instead of >> "onSelect". That's alien from FreeMarker 3, and from modern Java and >> JavaScript conventions too. So it might be worth it to change that. >> Then we should make error message generation more intelligent in >> freemarker-core, so that it tells you the correct parameter name >> automatically if only the case differs. > > I guess Spring decided to use the same default HTML attribute names, > with an exception for non-HTML attributes such as "cssErrorClass" or > conflicting names such as "cssClass". > - https://www.w3.org/TR/html4/index/attributes.html You are right. Let's leave it that way then. > This principle seems fine to me, and I guess Spring MVC devs might > prefer the original style for html attributes. > >> >>> I'll probably merge the PR by myself in a day or two and continue with >>> other directives while being willing to hear any feedback and >>> suggestions. >> >> BTW, especially in this part where you are the main author, I surely >> don't expect you to "stage" a change before merging, so just go ahead >> whenever you feel like it. (The added delay just increase the chance >> of conflicts.) > > OK. > > Thanks again, Thank you! > Woonsan > >> >>> Kind regards, >>> >>> Woonsan >>> >> >> -- >> Thanks, >> Daniel Dekany >> > -- Thanks, Daniel Dekany
Re: Please check and sign off our Podling Report for January!
Wednesday, January 3, 2018, 11:48:21 AM, Jacques Le Roux wrote: > Hi Daniel, > > It seems only mentors are required to sign off the report: > https://incubator.apache.org/guides/ppmc.html#podling_status_reports Eh... sorry, I mean Mentors, not PPMC members. > Jacques > > > Le 02/01/2018 à 18:04, Daniel Dekany a écrit : >> PPMC members who did not yet read and signed off our report, but have >> planned to do it, please go ahead (till Wed, January 03)! >> >> >> Wednesday, December 27, 2017, 10:34:17 PM, Daniel Dekany wrote: >> >>> Dear PPMC members! >>> >>> Please read the draft of our report on >>> https://wiki.apache.org/incubator/January2018, and tell if you agree >>> and what would you change! >>> >>> Then, when the deadline (Wed, January 03) is close, please also sign >>> it off, if you agree. >>> >>> A problem I have noticed that from the original template David E. >>> Jones was missing. I have added him back, as he's a Mentor as far as I >>> know, even if not an Incubato comitter. Maybe I shouldn't have for >>> that reason. David also red on our status page, and is not listed as a >>> Mentor, at https://whimsy.apache.org/roster/ppmc/freemarker, saying >>> "not listed as an incubator committer". But he is listed as a mentor >>> on http://incubator.apache.org/projects/freemarker.html. I guess this >>> should be resolved. Like he should be an Incubator committer I guess. >>> > > -- Thanks, Daniel Dekany
Re: Please check and sign off our Podling Report for January!
PPMC members who did not yet read and signed off our report, but have planned to do it, please go ahead (till Wed, January 03)! Wednesday, December 27, 2017, 10:34:17 PM, Daniel Dekany wrote: > Dear PPMC members! > > Please read the draft of our report on > https://wiki.apache.org/incubator/January2018, and tell if you agree > and what would you change! > > Then, when the deadline (Wed, January 03) is close, please also sign > it off, if you agree. > > A problem I have noticed that from the original template David E. > Jones was missing. I have added him back, as he's a Mentor as far as I > know, even if not an Incubato comitter. Maybe I shouldn't have for > that reason. David also red on our status page, and is not listed as a > Mentor, at https://whimsy.apache.org/roster/ppmc/freemarker, saying > "not listed as an incubator committer". But he is listed as a mentor > on http://incubator.apache.org/projects/freemarker.html. I guess this > should be resolved. Like he should be an Incubator committer I guess. > -- Thanks, Daniel Dekany
Re: Please check and sign off our Podling Report for January!
Thursday, December 28, 2017, 10:56:38 PM, David E Jones wrote: > In the issues paragraph it currently says 'is a grooving problem', should > that be 'is a growing problem'? Thanks, fixed that. > I'm not sure what to say about my Mentor status without being on the IPMC, > ie don't know if that is a policy change since FreeMarker entered the > incubator, or if has been that way for a longer time, either way this is > the first time for me participating in incubation as a mentor. > > Anyway, I'll sign the report just as I have for past reports... > > -David > > > On Wed, Dec 27, 2017 at 1:34 PM, Daniel Dekany <ddek...@apache.org> wrote: > >> Dear PPMC members! >> >> Please read the draft of our report on >> https://wiki.apache.org/incubator/January2018, and tell if you agree >> and what would you change! >> >> Then, when the deadline (Wed, January 03) is close, please also sign >> it off, if you agree. >> >> A problem I have noticed that from the original template David E. >> Jones was missing. I have added him back, as he's a Mentor as far as I >> know, even if not an Incubato comitter. Maybe I shouldn't have for >> that reason. David also red on our status page, and is not listed as a >> Mentor, at https://whimsy.apache.org/roster/ppmc/freemarker, saying >> "not listed as an incubator committer". But he is listed as a mentor >> on http://incubator.apache.org/projects/freemarker.html. I guess this >> should be resolved. Like he should be an Incubator committer I guess. >> >> -- >> Thanks, >> Daniel Dekany >> >> -- Thanks, Daniel Dekany
Re: Please check and sign off our Podling Report for January!
Thursday, December 28, 2017, 8:10:46 AM, Jacopo Cappellato wrote: > It looks great to me, thank you Daniel.The only change I would do is to add > Woonsan also in the section: "When were the last committers or PPMC members > elected?". OK, I have added him. > Jacopo > > On Wed, Dec 27, 2017 at 10:34 PM, Daniel Dekany <ddek...@apache.org> wrote: > >> Dear PPMC members! >> >> Please read the draft of our report on >> https://wiki.apache.org/incubator/January2018, and tell if you agree >> and what would you change! >> >> Then, when the deadline (Wed, January 03) is close, please also sign >> it off, if you agree. >> >> A problem I have noticed that from the original template David E. >> Jones was missing. I have added him back, as he's a Mentor as far as I >> know, even if not an Incubato comitter. Maybe I shouldn't have for >> that reason. David also red on our status page, and is not listed as a >> Mentor, at https://whimsy.apache.org/roster/ppmc/freemarker, saying >> "not listed as an incubator committer". But he is listed as a mentor >> on http://incubator.apache.org/projects/freemarker.html. I guess this >> should be resolved. Like he should be an Incubator committer I guess. >> >> -- >> Thanks, >> Daniel Dekany >> >> -- Thanks, Daniel Dekany
Please check and sign off our Podling Report for January!
Dear PPMC members! Please read the draft of our report on https://wiki.apache.org/incubator/January2018, and tell if you agree and what would you change! Then, when the deadline (Wed, January 03) is close, please also sign it off, if you agree. A problem I have noticed that from the original template David E. Jones was missing. I have added him back, as he's a Mentor as far as I know, even if not an Incubato comitter. Maybe I shouldn't have for that reason. David also red on our status page, and is not listed as a Mentor, at https://whimsy.apache.org/roster/ppmc/freemarker, saying "not listed as an incubator committer". But he is listed as a mentor on http://incubator.apache.org/projects/freemarker.html. I guess this should be resolved. Like he should be an Incubator committer I guess. -- Thanks, Daniel Dekany
Re: Podling Report Reminder - January 2018
I have upload a draft. It's a draft though, so in case someone will want changes in it, delay signing off as far as you can. Wednesday, December 27, 2017, 4:10:11 AM, Sergio Fernández wrote: > Any volunteer for reporting this time? Since we're starting the graduation > process, it's a good tiime to inform both IPMC and Board about our > intentions. > > I'll be on vacations from Friday 29th. So, even if I could get online for > signing the report afterwards, I'd prefer to leave it done before if > possible. > > On Dec 23, 2017 14:49, <johndam...@apache.org> wrote: > >> Dear podling, >> >> This email was sent by an automated system on behalf of the Apache >> Incubator PMC. It is an initial reminder to give you plenty of time to >> prepare your quarterly board report. >> >> The board meeting is scheduled for Wed, 17 January 2018, 10:30 am PDT. >> The report for your podling will form a part of the Incubator PMC >> report. The Incubator PMC requires your report to be submitted 2 weeks >> before the board meeting, to allow sufficient time for review and >> submission (Wed, January 03). >> >> Please submit your report with sufficient time to allow the Incubator >> PMC, and subsequently board members to review and digest. Again, the >> very latest you should submit your report is 2 weeks prior to the board >> meeting. >> >> Thanks, >> >> The Apache Incubator PMC >> >> Submitting your Report >> >> -- >> >> Your report should contain the following: >> >> * Your project name >> * A brief description of your project, which assumes no knowledge of >> the project or necessarily of its field >> * A list of the three most important issues to address in the move >> towards graduation. >> * Any issues that the Incubator PMC or ASF Board might wish/need to be >> aware of >> * How has the community developed since the last report >> * How has the project developed since the last report. >> * How does the podling rate their own maturity. >> >> This should be appended to the Incubator Wiki page at: >> >> https://wiki.apache.org/incubator/January2018 >> >> Note: This is manually populated. You may need to wait a little before >> this page is created from a template. >> >> Mentors >> --- >> >> Mentors should review reports for their project(s) and sign them off on >> the Incubator wiki page. Signing off reports shows that you are >> following the project - projects that are not signed may raise alarms >> for the Incubator PMC. >> >> Incubator PMC >> -- Thanks, Daniel Dekany
Re: Attempting graduation?
Wednesday, December 20, 2017, 9:31:19 AM, Jacopo Cappellato wrote: > The very next steps should be: > 1) run a vote in this list to make sure the community is happy to graduate; > see "Community Graduation Vote" [*] > 2) when the vote #1 starts, send an email to the Incubator general list to > inform them that the vote is running > I suggest to perform them now. Aggreed. > Then the next steps will be (assuming the vote has passed): > 3) prepare the graduation proposal; see "Preparing a Charter" [**] > 4) send the proposal to the Incubator general list for review before the > vote > 5) start the graduation vote in the Incubator general list; see "The > Recommendation Vote" [***] > > Then (if the recommendation vote will be successful) we will submit the > resolution to the Board. > > Regards, > > Jacopo > > [*] > https://incubator.apache.org/guides/graduation.html#community_graduation_vote > [**] > https://incubator.apache.org/guides/graduation.html#preparing_a_charter > [***] > https://incubator.apache.org/guides/graduation.html#the_recommendation_vote > On Sun, Dec 17, 2017 at 5:21 PM, Sergio Fernández <wik...@apache.org> wrote: > >> Right. Sorry for the confusion. When I said "committed" I wanted to say >> people engadget with the project after graduation, so PMC members in short. >> >> I believe Daniel already got this list pretty clear. >> >> On Dec 16, 2017 14:07, "Ralph Goers" <ralph.go...@dslextreme.com> wrote: >> >> > The board needs a list of the PMC members, not necessarily committers, >> > although it is unusual that a podling will become a TLP with committers >> who >> > aren’t PMC members. >> > >> > Ralph >> > >> > > On Dec 15, 2017, at 10:37 AM, Sergio Fernández <wik...@apache.org> >> > wrote: >> > > >> > > HI Daniel, >> > > >> > > the graduation resolution is a formal text that has to be submitted to >> > the >> > > ASF Board to communicate the graduation of the podling. Further >> > information >> > > at >> > > https://incubator.apache.org/guides/graduation.html# >> > submission_of_the_resolution_to_the_board >> > > >> > > It has to be drafted internally, voted first by the PPMC and secondly >> by >> > > the IPMC (not that different than voting a release). >> > > >> > > The text is pretty standard. The two main things to decide are: 1) who >> is >> > > going to be the Freemarker VP 2) list of committed to the new TLP >> > > >> > > I drafted one in the past >> > > https://svn.apache.org/repos/asf/marmotta/graduation/resolution.txt >> > than we >> > > can use as an example for moving forward with this. >> > > >> > > On Fri, Dec 15, 2017 at 5:09 AM, Daniel Dekany <ddek...@apache.org> >> > wrote: >> > > >> > >> I would like to revie this thread. >> > >> >> > >> Again, I would like to encourage others to check if we miss some >> > >> formal requirements, other than the VOTE thread here. I bet there are >> > >> some little things at least. >> > >> >> > >> Also https://incubator.apache.org/guides/graduation.html talks about >> > >> things like propose a "resolution" general incubator list before a >> > >> VOTE, etc. (OFBiz is brough up as a good example there.) Anyone >> > >> intends to tackle these? >> > >> >> > >> >> > >> Wednesday, November 8, 2017, 1:34:24 AM, Daniel Dekany wrote: >> > >> >> > >>> So, we have released 2.3.27, and has changed the domain of the home >> > >>> page (not of try.freemarker.org though... is that a problem?). >> What's >> > >>> next? Anyone? >> > >>> >> > >>> >> > >>> Monday, October 23, 2017, 3:18:54 PM, Daniel Dekany wrote: >> > >>> >> > >>>> Monday, October 23, 2017, 4:04:54 PM, Jacopo Cappellato wrote: >> > >>>> >> > >>>>> +1 for the migration. >> > >>>>> And right after that I think we should start the graduation >> process. >> > >>>> >> > >>>> Agreed regarding graduation. (We certainly should release 2.3.27 >> > >>>> before that, but it's very close anyway, hopefully.) >> > >&g
Re: Attempting graduation?
I would like to revie this thread. Again, I would like to encourage others to check if we miss some formal requirements, other than the VOTE thread here. I bet there are some little things at least. Also https://incubator.apache.org/guides/graduation.html talks about things like propose a "resolution" general incubator list before a VOTE, etc. (OFBiz is brough up as a good example there.) Anyone intends to tackle these? Wednesday, November 8, 2017, 1:34:24 AM, Daniel Dekany wrote: > So, we have released 2.3.27, and has changed the domain of the home > page (not of try.freemarker.org though... is that a problem?). What's > next? Anyone? > > > Monday, October 23, 2017, 3:18:54 PM, Daniel Dekany wrote: > >> Monday, October 23, 2017, 4:04:54 PM, Jacopo Cappellato wrote: >> >>> +1 for the migration. >>> And right after that I think we should start the graduation process. >> >> Agreed regarding graduation. (We certainly should release 2.3.27 >> before that, but it's very close anyway, hopefully.) >> >> Related: >> >> - >> https://cwiki.apache.org/confluence/display/FREEMARKER/Apache+FreeMarker+Project+Maturity+Model >> >> - http://incubator.apache.org/projects/freemarker.html: >> Here some dates are year only. >> >> - https://whimsy.apache.org/roster/ppmc/freemarker: >> This has some glitches, like it states "No Release Yet/Binary has >> licensing issues"... will have to update this somehow. >> >>> Jacopo >>> >>> On Mon, Oct 23, 2017 at 11:48 AM, Daniel Dekany <ddek...@apache.org> wrote: >>> >>>> As this issue that we aren't using an apache.org domain comes up again >>>> and again, I propose that we switch to freemarker.apache.org now. Also >>>> to try.freemarker.apache.org. Anybody for or against it? >>>> >>>> >>>> Friday, October 20, 2017, 10:18:01 PM, Ralph Goers wrote: >>>> >>>> > >>>> >> On Oct 20, 2017, at 5:59 AM, Daniel Dekany <ddek...@apache.org> wrote: >>>> >> >>>> >> Friday, October 20, 2017, 12:24:30 PM, Jacques Le Roux wrote: >>>> >> >>>> >>> Le 01/10/2017 à 23:27, Daniel Dekany a écrit : >>>> >>>> Sunday, October 1, 2017, 8:26:53 PM, Jacques Le Roux wrote: >>>> >>>> >>>> >>>>> Le 23/09/2017 à 08:44, Daniel Dekany a écrit : >>>> >>>>>> Friday, September 22, 2017, 11:17:59 PM, Jacques Le Roux wrote: >>>> >>>>>> >>>> >>>>>>> Le 22/09/2017 à 22:22, Daniel Dekany a écrit : >>>> >>>>>>>> Google doesn't like plain HTTP sites as we know (SEO), also I hear >>>> >>>>>>>> that starting from October they want to show warning in Chrome if >>>> you >>>> >>>>>>>> have forms on your page. We do have forms... On all page under >>>> >>>>>>>> http://freemarker.org/docs/ there's a search field, and >>>> >>>>>>>> http://try.freemarker.org/ is nothing but a form. >>>> >>>>>>>> >>>> >>>>>>>> Anyone want to tackle this? Or part of this? >>>> >>>>>>>> >>>> >>>>>>> I did that for OFBiz. I can have a look before October. >>>> >>>>>> That would be great, thanks! >>>> >>>>>> >>>> >>>>>>> Jacques >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>> Sorry, OFBiz still being my priority, I was not able to do it yet. >>>> >>>>> But I should be able to start this week, most likely Monday... >>>> >>>> No problem, and thanks for keep us informed! >>>> >>>> >>>> >>>>> Jacques >>>> >>> Sorry again, my current contract has changed and I'll not be available >>>> before November >>>> >>> I'm though trying the new release in OFBiz right now, so far all seems >>>> OK :) >>>> >> >>>> >> The latest Chrome doesn't (yet?) show any warnings on our site, so no >>>> >> problem. (Maybe they only do it if there's a password filed, for now.) >>>> >> >>>> >> Thanks for the checking the release! >>>> > >>>> > I should also point out that in the last board report the issue of >>>> > freemarker not yet having an apache.org <http://apache.org/> web >>>> > site came up. I would suggest that the project make that transition >>>> > sooner than later if graduation is desired. >>>> > >>>> > Ralph >>>> > >>>> >>>> -- >>>> Thanks, >>>> Daniel Dekany >>>> >>>> >> > -- Thanks, Daniel Dekany
Re: try.freemarker.apache.org instead of try.freemarker.org?
To summarize, the opininos were (whether we should switch to try.freemarker.apache.org): - Daniel Dekany: We better not risk not doing this - Jacopo Cappellato: Agrees with me (above) in this - Jacques Le Roux: No opinion was expressed, but it's technically fine - Ralph Goers: It's certainly not necessary to do So, unless someone has more to add, I will ask this from Infra in the coming days... just to be on the safe side. Wednesday, November 29, 2017, 6:38:05 PM, Ralph Goers wrote: > The difference is that try.freemarker.org > <http://try.freemarker.org/> is a companion site. So long as the > main site is freemarker.apache.org I don’t think anyone will complain about a > companion site. > > Ralph > >> On Nov 29, 2017, at 8:33 AM, Jacques Le Roux <jacques.le.r...@les7arts.com> >> wrote: >> >> Hi Ralph, >> >> IIRW openoffice.org is an exception. There are others, when the domain was >> well established before entering the incubator, subversion.org comes to mind. >> >> IMO freemarker.org was well established before entering the incubator but >> not try.freemarker.apache.org which is quite recent. Hence maybe some >> caution needed... >> >> My 2 cts >> >> Jacques >> >> >> Le 29/11/2017 à 14:55, Ralph Goers a écrit : >>> Personally, I don’t see why there should be a problem as long as >>> try.freemarker.org <http://try.freemarker.org/> is an Apache controlled >>> domain. You aren’t the only project that has a vanity domain. See >>> www.openoffice.org <http://www.openoffice.org/> as an example. >>> >>> Ralph >>> >>>> On Nov 29, 2017, at 1:51 AM, Daniel Dekany <ddek...@apache.org> wrote: >>>> >>>> Just as a reminder, I'm planning to request try.freemarker.apache.org, >>>> from Infra and then redirect try.freemarker.org to it, because I'm >>>> worried that the IPMC will dislike that we use try.freemarker.org as >>>> the canonical address of the online template tester. It will also use >>>> https and a LetsEncrypt certificate (we can't use the *.apache.org >>>> cert on a VM). >>>> >>>> BTW, using a sub-sub domains is a bit extreme. I'm not aware of any >>>> gotchas in out case, but if anyone is aware some, like LetsEncrypt >>>> doesn't support them or something, please stop me! (Also, as this way >>>> we will receive the cookies of freemarker.apache.org, but certainly we >>>> will able to cope with that, if it ever causes a problem.) >>>> >>>> Any comments? And do you (especially PPMC members) agree? >>>> >>>> -- >>>> Thanks, >>>> Daniel Dekany >>>> >>>> >>> >> >> > -- Thanks, Daniel Dekany
Re: Alternative to ${exp}
OK, so I would go for [=exp] (see the reason told in this thread). How
acceptable is that guys?
Tuesday, December 5, 2017, 11:56:59 AM, Woonsan Ko wrote:
> On Mon, Dec 4, 2017 at 10:28 AM, Daniel Dekany <ddek...@apache.org> wrote:
>> Monday, December 4, 2017, 10:21:48 AM, Taher Alkhateeb wrote:
>>
>>> uh-huh, but I suspect maybe more collisions or need to escape
>>> character in something like [this] or than {{this}}. Anyway,
>>> nothing critical IMO, only thinking out loud.
>>
>> But they were [=this] and <=this>, so the sequences that will clash
>> are "[=" and "<=", which are quite rare. Oh wait... "<=" is not rare
>> at all: "if (x <= y)". But "[=" still is. OK, so I guess at this point
>> the two competitors left are {{exp}} and [=exp] (regardless of tag
>> syntax).
>
> +1.00 on [=exp].
> +0.49 on {{exp}}.
>
> :-D
>
> Many languages or templates allows ${exp}, including JavaScript. [1]
> And, mustache is supported in many languages or templates, too. [2]
> Therefore, I think there are more chances using both ${exp} and
> {{exp}} in output we want to generate in the future.
> The mustache style looks charming at the moment, but I wonder how its
> charming can help for the original intention (to avoid any possible
> collision in the output we want to generate by an alternative as much
> as we can).
>
> Regards,
>
> Woonsan
>
> [1] https://en.wikipedia.org/wiki/String_interpolation
> [2] https://mustache.github.io/
>
>>
>>> On Mon, Dec 4, 2017 at 12:00 PM, Daniel Dekany <ddek...@apache.org> wrote:
>>>> Monday, December 4, 2017, 9:17:34 AM, Taher Alkhateeb wrote:
>>>>
>>>>> So maybe a safe bet (and a familiar one) is the mustache syntax.
>>>>>
>>>>> In addition to avoiding clashes it might help with a multi-chained
>>>>> template. For example, we use FreeMarker extensively in Apache OFBiz
>>>>> to generate many documents including XML. Now our XML documents might
>>>>> contain some ${variable} that needs to be interpreted in the XML
>>>>> parser, not the freemarker parser (without having to escape characters
>>>>> everywhere)
>>>>
>>>> Though that also works with all the other proposal syntaxes as well.
>>>>
>>>>> On Mon, Dec 4, 2017 at 8:50 AM, Jacques Le Roux
>>>>> <jacques.le.r...@les7arts.com> wrote:
>>>>>> Le 03/12/2017 à 22:06, Woonsan Ko a écrit :
>>>>>>>
>>>>>>> It is also most productive as no shift key is required.
>>>>>>
>>>>>> Depends on keyboard, for French keyboard type (azerty) you need to use
>>>>>> Alt
>>>>>> key ;)
>>>>>> Same for {{...}} anyway
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Thanks,
>>>> Daniel Dekany
>>>>
>>>
>>
>> --
>> Thanks,
>> Daniel Dekany
>>
>
--
Thanks,
Daniel Dekany
Re: Freemarker builds
Wednesday, December 6, 2017, 1:01:07 PM, jmeter tea wrote: > Hello, > > I wanted to know where freemarker builds are executed, > I didn't find it in https://builds.apache.org/view/All/ as other Apache > incubator projects. On Travis: https://travis-ci.org/apache/incubator-freemarker > Thank you -- Thanks, Daniel Dekany
Re: Alternative to ${exp}
Monday, December 4, 2017, 10:21:48 AM, Taher Alkhateeb wrote:
> uh-huh, but I suspect maybe more collisions or need to escape
> character in something like [this] or than {{this}}. Anyway,
> nothing critical IMO, only thinking out loud.
But they were [=this] and <=this>, so the sequences that will clash
are "[=" and "<=", which are quite rare. Oh wait... "<=" is not rare
at all: "if (x <= y)". But "[=" still is. OK, so I guess at this point
the two competitors left are {{exp}} and [=exp] (regardless of tag
syntax).
> On Mon, Dec 4, 2017 at 12:00 PM, Daniel Dekany <ddek...@apache.org> wrote:
>> Monday, December 4, 2017, 9:17:34 AM, Taher Alkhateeb wrote:
>>
>>> So maybe a safe bet (and a familiar one) is the mustache syntax.
>>>
>>> In addition to avoiding clashes it might help with a multi-chained
>>> template. For example, we use FreeMarker extensively in Apache OFBiz
>>> to generate many documents including XML. Now our XML documents might
>>> contain some ${variable} that needs to be interpreted in the XML
>>> parser, not the freemarker parser (without having to escape characters
>>> everywhere)
>>
>> Though that also works with all the other proposal syntaxes as well.
>>
>>> On Mon, Dec 4, 2017 at 8:50 AM, Jacques Le Roux
>>> <jacques.le.r...@les7arts.com> wrote:
>>>> Le 03/12/2017 à 22:06, Woonsan Ko a écrit :
>>>>>
>>>>> It is also most productive as no shift key is required.
>>>>
>>>> Depends on keyboard, for French keyboard type (azerty) you need to use Alt
>>>> key ;)
>>>> Same for {{...}} anyway
>>>>
>>>> Jacques
>>>>
>>>
>>
>> --
>> Thanks,
>> Daniel Dekany
>>
>
--
Thanks,
Daniel Dekany
Re: Alternative to ${exp}
Monday, December 4, 2017, 6:50:20 AM, Jacques Le Roux wrote:
> Le 03/12/2017 à 22:06, Woonsan Ko a écrit :
>> It is also most productive as no shift key is required.
> Depends on keyboard, for French keyboard type (azerty) you need to use Alt
> key ;)
> Same for {{...}} anyway
Good point. Same on Hungarian keyboard (though I had to check... I
never type source code with hunarian layout). But programming
languages was created with US keyboard in mind, so surely the
developers who are still working using their national keyboard layout
doesn't care much about pressing "Alt Gr". (On Hungarian keyboard even
";" needs "Alt Gr", yet most colegues use Hungarian layout for Java.)
And those who do care will be happier with an English layout friendly
syntax. Though, templates are somewhat different from usual source
code in that they tend to contain more national text, or are edited by
non-programmers, so US layout friendlines has a bit less gain there.
> Jacques
>
>
--
Thanks,
Daniel Dekany
Re: Alternative to ${exp}
Monday, December 4, 2017, 9:17:34 AM, Taher Alkhateeb wrote:
> So maybe a safe bet (and a familiar one) is the mustache syntax.
>
> In addition to avoiding clashes it might help with a multi-chained
> template. For example, we use FreeMarker extensively in Apache OFBiz
> to generate many documents including XML. Now our XML documents might
> contain some ${variable} that needs to be interpreted in the XML
> parser, not the freemarker parser (without having to escape characters
> everywhere)
Though that also works with all the other proposal syntaxes as well.
> On Mon, Dec 4, 2017 at 8:50 AM, Jacques Le Roux
> <jacques.le.r...@les7arts.com> wrote:
>> Le 03/12/2017 à 22:06, Woonsan Ko a écrit :
>>>
>>> It is also most productive as no shift key is required.
>>
>> Depends on keyboard, for French keyboard type (azerty) you need to use Alt
>> key ;)
>> Same for {{...}} anyway
>>
>> Jacques
>>
>
--
Thanks,
Daniel Dekany
Re: Alternative to ${exp}
Sunday, December 3, 2017, 10:06:48 PM, Woonsan Ko wrote:
> On Tue, Nov 28, 2017 at 4:45 AM, Daniel Dekany <ddek...@apache.org> wrote:
>> This problem comes up again and again: the ${exp} syntax clashes with
>> the syntax of the thing the user wants to generate. So I believe we
>> need a Configuration option to address this. Something like
>> cfg.setInterpolationSyntax(FOO_INTERPOLATION_SYNTAX), and also
>> <#ftl interpolationSyntax="foo">.
>>
>> Like any syntax option, this is potentially confusing for users and
>> problem for tools, but I don't think there's a way around this. Users
>> have to deal with those clashing ${}-s somehow, and certainly an
>> in-house hack will be worse and even more confusing. (Surely they can
>> write ${'$'}{foo} or use #noparse, but if you need a lot of those,
>> then it's obviously not an acceptable workaround.)
>>
>> So, what the syntax would be? Some of my ideas:
>>
>> - {{exp}} is probably the nicest. For the same reason it potentially
>> clashes with something yet again, though I guess it's unlikely
>> enough that neither ${exp} nor {{exp}} works for you.
>>
>> - @{exp}. It's similar to ${exp}, which I think is an advantage.
>> There's however a very small but still real chance that for someone
>> both ${} and @{} clashes with what they want to generate, because
>> using {name} is somewhat popular.
>>
>> - #{exp}. That looks like the natural choice as we use # in tags as
>> well (also @, though). The reason I don't like it is that
>> we already have #{exp} in the standard syntax, but it's deprecated.
>> That's not a problem technically, as you can say that if you select
>> the #{} syntax, then it's not deprecated, and ${} will be treated
>> as static text. But now if someone sees #{exp}, they can't tell if
>> the template uses a deprecated syntax, or it uses the alternative
>> interpolation syntax. Also it's perhaps more likely that for someone
>> both ${} and #{} clashes (e.g. in the case you generate JSF JSP-s),
>> than that that both ${} and @{} clashes.
>>
>> - <=exp> and [=exp] depending on if you are using square- or
>> angle-bracket tag syntax. Look somewhat exotic... which also means
>> that hopefully it won't clash with anything.
>
> I personally prefer the style with square-bracket: [=exp], which seems
> most unique and intuitive.
You mean, even if you're using the angle bracket tag syntax (like
<#if foo>)? If somebody cares about pressing shift, I think he can use
square bracket tag syntax (like [#if something]), and so spare the
shifts needed for the tags as well. I have assumed that otherwise it
worths more that <=exp> is more consistent with the tag syntax. But
maybe it doesn't after all.
Actually, [=exp] has the slight advantage that it doesn't interfere
with the HTML/XML syntax (which FreeMarker doesn't care about, but
some tools can get confused), similarly as ${exp} didn't. As some
users mostly only use interpolations inside HTML/XML tags, I can
immagine that they aren't concerned enough about the angle brackes of
the FTL tags to switch to the less well known square bracket syntax.
Also, if the interpolation syntax doesn't depend on the tag synax
(it's always [#exp]), that might prevents some user confusion. Also it
doesn't complicate the parser that much.
> It is also most productive as no shift key is required.
> I like [=exp] better than <=exp> by the way, because the latter is
> confusing (looks like <%=exp>) and requiring shift keys.
So far we have heard 3 preferences:
- {{exp}}
- {exp}, where is specified in the Configuration,
so you end up with something like @{exp}, %{exp}, etc.
- [=exp], but even if the tagSyntax setting is angle-brackets (if I
understand well).
I'm torn between all three, with a slight bias towards [=exp] now.
That's probably the most practical solution, except, some users can't
stand unusually looking syntax like that.
> Regards,
>
> Woonsan
>
>>
>> There's also the idea that we just let the user specify any separator,
>> like `cfg.setInterpolationStart("@{"); cfg.setInterpolationEnd("}")`.
>> But if all kind of random syntax is possible, it's harder for users to
>> figure out what's going on (their syntax isn't mentioned in the
>> Manual, and nobody on StackOverlfow recognizes it either), and it's
>> more difficult to support that in tools as well. So I believe it's
>> better for everyone if there's one, or maybe two standard
>> alternatives. (Not to mention that I don't yet see how to implement
>> such a runtime-configured syntax with the current JavaCC-based parser.
>> Probably it would be a horrid hack if possible at all.)
>>
>> Opinions, ideas?
>>
>> --
>> Thanks,
>> Daniel Dekany
>>
>
--
Thanks,
Daniel Dekany
Re: Error when processing doap file https://git-wip-us.apache.org/repos/asf?p=incubator-freemarker-site.git;a=blob_plain;f=doap.rdf;hb=HEAD:
Hurray, it works! https://projects.apache.org/project.html?incubator-freemarker Note that the URL for incubator projects has been changed, so it doesn't end with "?freemarker", but "?incubator-freemarker". Tuesday, November 28, 2017, 10:02:29 PM, sebb wrote: > On 28 November 2017 at 20:13, Daniel Dekany <ddek...@apache.org> wrote: >> Tuesday, November 28, 2017, 8:45:05 PM, sebb wrote: >> >>> There was a bug in the processing script whereby the asfext:pmc >>> setting was overridden by the site URL. >>> >>> Not sure why this was done - probably for historical reasons. >>> The code is fixed now; should also fix Annotator when the site is >>> regenerated. >> >> Thanks, and let's hope that that was the problem! Though, note that >> for Taverna (incubating), there's >> http://taverna.incubator.apache.org/; />, yet >> that has worked. > > Yes, because the URL contains .incubator. > >>> On 28 November 2017 at 12:56, Daniel Dekany <ddek...@apache.org> wrote: >>>> We did that back then (we have >>> rdf:resource="http://incubator.apache.org; />, same as others), but it >>>> still says the same: >>>> >>>> Cannot find the PMC 'freemarker' for this project. Check the DOAP is >>>> correct. >>>> >>>> Are you sure this thing pick ups the latest committed version? >>>> >>>> Thursday, November 23, 2017, 1:41:57 AM, sebb wrote: >>>> >>>>> Compare the >>>> >>>>> On 23 November 2017 at 00:21, Sergio Fernández <wik...@apache.org> wrote: >>>>>> Why: It does pointing to Incubator, see >>>>>> https://github.com/apache/incubator-freemarker-site/blob/master/doap.rdf#L45 >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Nov 22, 2017 at 2:57 PM, sebb <seb...@gmail.com> wrote: >>>>>>> >>>>>>> The DOAP has the wrong pmc reference. >>>>>>> Compare your DOAP against other Incubator project DOAPs. >>>>>>> >>>>>>> On 22 November 2017 at 17:30, Sergio Fernández <wik...@apache.org> >>>>>>> wrote: >>>>>>> > OK, but https://projects.apache.org/project.html?freemarker doesn't >>>>>>> > load >>>>>>> > :-/ >>>>>>> > >>>>>>> > On Wed, Nov 22, 2017 at 3:38 AM, sebb <seb...@gmail.com> wrote: >>>>>>> >> >>>>>>> >> Looks like it was a transient error. >>>>>>> >> >>>>>>> >> AFAICT it worked OK on the last run(s) >>>>>>> >> >>>>>>> >> On 21 November 2017 at 19:45, Sergio Fernández <wik...@apache.org> >>>>>>> >> wrote: >>>>>>> >> > The file is valid RDF/XML file, I can warranty that. I think the >>>>>>> >> > infrastructure behind projects.a.o processes those files as XML, >>>>>>> >> > but >>>>>>> >> > I >>>>>>> >> > can't >>>>>>> >> > see what could be the error. >>>>>>> >> > >>>>>>> >> > On Tue, Nov 21, 2017 at 3:52 AM, sebb <seb...@gmail.com> wrote: >>>>>>> >> >> >>>>>>> >> >> You could try an online validator. >>>>>>> >> >> >>>>>>> >> >> A quick search found be this: >>>>>>> >> >> >>>>>>> >> >> https://www.xmlvalidation.com >>>>>>> >> >> >>>>>>> >> >> I'm sure there are others. >>>>>>> >> >> >>>>>>> >> >> >>>>>>> >> >> On 21 November 2017 at 03:48, Sergio Fernández <wik...@apache.org> >>>>>>> >> >> wrote: >>>>>>> >> >> > Sorry, my bad. >>>>>>> >> >> > Fixed in de6050c6d2dfb83de20fca602533e19b26c0eade >>>>>>> >> >> > >>>>>>> >> >> > Any other details why it failed? >>>>>>> >> >> > >>>>>>> >> >> > It says "mismatched tag: line 12, column 2", but don't >>>>>>> >> >> > understand >>>>>>> >> >> > why. >>>>>>> >> >> > >>>>>>> >> >> > >>>>>>> >> >> > On Mon, Nov 20, 2017 at 6:28 PM, sebb <seb...@gmail.com> wrote: >>>>>>> >> >> >> >>>>>>> >> >> >> Please can you fix the DOAP? >>>>>>> >> >> >> >>>>>>> >> >> >> Also the following entry is wrong: >>>>>>> >> >> >> >>>>>>> >> >> >> >>>>>> >> >> >> >>>>>>> >> >> >> >>>>>>> >> >> >> >>>>>>> >> >> >> rdf:resource="http://people.apache.org/committers-by-project.html#freemarker; >>>>>>> >> >> >> /> >>>>>>> >> >> >> >>>>>>> >> >> >> It should be >>>>>>> >> >> >> >>>>>>> >> >> >> http://incubator.apache.org; /> >>>>>>> >> >> >> >>>>>>> >> >> >> >>>>>>> >> >> >> Thanks! >>>>>>> >> >> >> >>>>>>> >> >> >> >>>>>>> >> >> >> -- Forwarded message -- >>>>>>> >> >> >> From: Projects <aps...@apache.org> >>>>>>> >> >> >> Date: 21 November 2017 at 02:00 >>>>>>> >> >> >> Subject: Error when processing doap file >>>>>>> >> >> >> >>>>>>> >> >> >> >>>>>>> >> >> >> >>>>>>> >> >> >> >>>>>>> >> >> >> https://git-wip-us.apache.org/repos/asf?p=incubator-freemarker-site.git;a=blob_plain;f=doap.rdf;hb=HEAD: >>>>>>> >> >> >> To: Site Development <site-...@apache.org> >>>>>>> >> >> >> >>>>>>> >> >> >> >>>>>>> >> >> >> mismatched tag: line 12, column 2 >>>>>>> >> >> > >>>>>>> >> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> > >>>>>>> > >>>>>> >>>>>> >>>>> >>>> >>>> -- >>>> Thanks, >>>> Daniel Dekany >>>> >>> >> >> -- >> Thanks, >> Daniel Dekany >> > -- Thanks, Daniel Dekany
try.freemarker.apache.org instead of try.freemarker.org?
Just as a reminder, I'm planning to request try.freemarker.apache.org, from Infra and then redirect try.freemarker.org to it, because I'm worried that the IPMC will dislike that we use try.freemarker.org as the canonical address of the online template tester. It will also use https and a LetsEncrypt certificate (we can't use the *.apache.org cert on a VM). BTW, using a sub-sub domains is a bit extreme. I'm not aware of any gotchas in out case, but if anyone is aware some, like LetsEncrypt doesn't support them or something, please stop me! (Also, as this way we will receive the cookies of freemarker.apache.org, but certainly we will able to cope with that, if it ever causes a problem.) Any comments? And do you (especially PPMC members) agree? -- Thanks, Daniel Dekany
Re: Alternative to ${exp}
Tuesday, November 28, 2017, 8:43:49 PM, Denis Bredelet wrote:
> Hi Daniel,
>
>> On 28 Nov 2017, at 15:45, Jacques Le Roux <jacques.le.r...@les7arts.com>
>> wrote:
>>
>> Le 28/11/2017 à 16:43, Jacques Le Roux a écrit :
>>>
>>>
>>> Le 28/11/2017 à 10:45, Daniel Dekany a écrit :
>>>> This problem comes up again and again: the ${exp} syntax clashes with
>>>> the syntax of the thing the user wants to generate. So I believe we
>>>> need a Configuration option to address this. Something like
>>>> cfg.setInterpolationSyntax(FOO_INTERPOLATION_SYNTAX), and also
>>>> <#ftl interpolationSyntax="foo">.
>>>>
>>>> Like any syntax option, this is potentially confusing for users and
>>>> problem for tools, but I don't think there's a way around this. Users
>>>> have to deal with those clashing ${}-s somehow, and certainly an
>>>> in-house hack will be worse and even more confusing. (Surely they can
>>>> write ${'$'}{foo} or use #noparse, but if you need a lot of those,
>>>> then it's obviously not an acceptable workaround.)
>>>>
>>>> So, what the syntax would be? Some of my ideas:
>>>>
>>>> - {{exp}} is probably the nicest. For the same reason it potentially
>>>>clashes with something yet again, though I guess it's unlikely
>>>>enough that neither ${exp} nor {{exp}} works for you.
>
> Mustache style, in fact I would choose that other the default :-)
>
>>>> - @{exp}. It's similar to ${exp}, which I think is an advantage.
>>>>There's however a very small but still real chance that for someone
>>>>both ${} and @{} clashes with what they want to generate, because
>>>>using {name} is somewhat popular.
>>>>
>>>> - #{exp}. That looks like the natural choice as we use # in tags as
>>>>well (also @, though). The reason I don't like it is that
>>>>we already have #{exp} in the standard syntax, but it's deprecated.
>>>>That's not a problem technically, as you can say that if you select
>>>>the #{} syntax, then it's not deprecated, and ${} will be treated
>>>>as static text. But now if someone sees #{exp}, they can't tell if
>>>>the template uses a deprecated syntax, or it uses the alternative
>>>>interpolation syntax. Also it's perhaps more likely that for someone
>>>>both ${} and #{} clashes (e.g. in the case you generate JSF JSP-s),
>>>>than that that both ${} and @{} clashes.
>>>>
>>>> - <=exp> and [=exp] depending on if you are using square- or
>>>>angle-bracket tag syntax. Look somewhat exotic... which also means
>>>>that hopefully it won't clash with anything.
>>>>
>>>> There's also the idea that we just let the user specify any separator,
>>>> like `cfg.setInterpolationStart("@{"); cfg.setInterpolationEnd("}")`.
>
> How about just:
>
> cfg.setInterpolationPrefix("@")
>
> If the start character is "{" then use {{ }}, else use #{ } or @{ } or
> whatever you choose.
The problem is that JavaCC doesn't really support such things. The
syntax is static in it. But we could hardwire all the sane symbols
into it (something like $@#%&), and then decide on runtime if we want
to change that token (like a "@{" token) to static text.
BTW, this reminds me that sometimes the problem is using "{" itself.
Some syntaxes (like RTF and Jira/Confluence) reserve that character,
and so no mater what character you put before it, it's still clashing.
And even {{exp}} has the same problem. So it seems that we need an
additional (or, the only alternative) syntax that doesn't use "{".
<=...> and [=...] comes into mind (though they are a bit complicated
as they depend on the tagSyntax as well).
> — Denis.
>
>>>> But if all kind of random syntax is possible, it's harder for users to
>>>> figure out what's going on (their syntax isn't mentioned in the
>>>> Manual, and nobody on StackOverlfow recognizes it either), and it's
>>>> more difficult to support that in tools as well. So I believe it's
>>>> better for everyone if there's one, or maybe two standard
>>>> alternatives. (Not to mention that I don't yet see how to implement
>>>> such a runtime-configured syntax with the current JavaCC-based parser.
>>>> Probably it would be a horrid hack if possible at all.)
>>>>
>>>> Opinions, ideas?
>>>>
>>>
>>>
>> Oops wrong button => blank message :/
>>
>> I also prefer {{exp}} for the simple reason that it reminds me Jira and of
>> course also for the reasons you explained
>>
>> Jacques
>>
>
>
--
Thanks,
Daniel Dekany
Re: Alternative to ${exp}
Tuesday, November 28, 2017, 4:45:01 PM, Jacques Le Roux wrote:
> Le 28/11/2017 à 16:43, Jacques Le Roux a écrit :
>>
>>
>> Le 28/11/2017 à 10:45, Daniel Dekany a écrit :
>>> This problem comes up again and again: the ${exp} syntax clashes with
>>> the syntax of the thing the user wants to generate. So I believe we
>>> need a Configuration option to address this. Something like
>>> cfg.setInterpolationSyntax(FOO_INTERPOLATION_SYNTAX), and also
>>> <#ftl interpolationSyntax="foo">.
>>>
>>> Like any syntax option, this is potentially confusing for users and
>>> problem for tools, but I don't think there's a way around this. Users
>>> have to deal with those clashing ${}-s somehow, and certainly an
>>> in-house hack will be worse and even more confusing. (Surely they can
>>> write ${'$'}{foo} or use #noparse, but if you need a lot of those,
>>> then it's obviously not an acceptable workaround.)
>>>
>>> So, what the syntax would be? Some of my ideas:
>>>
>>> - {{exp}} is probably the nicest. For the same reason it potentially
>>> clashes with something yet again, though I guess it's unlikely
>>> enough that neither ${exp} nor {{exp}} works for you.
>>>
>>> - @{exp}. It's similar to ${exp}, which I think is an advantage.
>>> There's however a very small but still real chance that for someone
>>> both ${} and @{} clashes with what they want to generate, because
>>> using {name} is somewhat popular.
>>>
>>> - #{exp}. That looks like the natural choice as we use # in tags as
>>> well (also @, though). The reason I don't like it is that
>>> we already have #{exp} in the standard syntax, but it's deprecated.
>>> That's not a problem technically, as you can say that if you select
>>> the #{} syntax, then it's not deprecated, and ${} will be treated
>>> as static text. But now if someone sees #{exp}, they can't tell if
>>> the template uses a deprecated syntax, or it uses the alternative
>>> interpolation syntax. Also it's perhaps more likely that for someone
>>> both ${} and #{} clashes (e.g. in the case you generate JSF JSP-s),
>>> than that that both ${} and @{} clashes.
>>>
>>> - <=exp> and [=exp] depending on if you are using square- or
>>> angle-bracket tag syntax. Look somewhat exotic... which also means
>>> that hopefully it won't clash with anything.
>>>
>>> There's also the idea that we just let the user specify any separator,
>>> like `cfg.setInterpolationStart("@{"); cfg.setInterpolationEnd("}")`.
>>> But if all kind of random syntax is possible, it's harder for users to
>>> figure out what's going on (their syntax isn't mentioned in the
>>> Manual, and nobody on StackOverlfow recognizes it either), and it's
>>> more difficult to support that in tools as well. So I believe it's
>>> better for everyone if there's one, or maybe two standard
>>> alternatives. (Not to mention that I don't yet see how to implement
>>> such a runtime-configured syntax with the current JavaCC-based parser.
>>> Probably it would be a horrid hack if possible at all.)
>>>
>>> Opinions, ideas?
>>>
>>
>>
Oops wrong button =>> blank message :/
>
> I also prefer {{exp}} for the simple reason that it reminds me Jira
> and of course also for the reasons you explained
Though it has a different meaning there, so it doesn't necessarily
help. (Worse, for making template for Jira markup, you can't use
${exp} either... so this is actually one of those rather unlucky
cases.) What's a much bigger factor is Angular templates also use
{{exp}} for inserting values.
> Jacques
>
>
--
Thanks,
Daniel Dekany
Re: Error when processing doap file https://git-wip-us.apache.org/repos/asf?p=incubator-freemarker-site.git;a=blob_plain;f=doap.rdf;hb=HEAD:
Tuesday, November 28, 2017, 8:45:05 PM, sebb wrote: > There was a bug in the processing script whereby the asfext:pmc > setting was overridden by the site URL. > > Not sure why this was done - probably for historical reasons. > The code is fixed now; should also fix Annotator when the site is regenerated. Thanks, and let's hope that that was the problem! Though, note that for Taverna (incubating), there's http://taverna.incubator.apache.org/; />, yet that has worked. > On 28 November 2017 at 12:56, Daniel Dekany <ddek...@apache.org> wrote: >> We did that back then (we have > rdf:resource="http://incubator.apache.org; />, same as others), but it >> still says the same: >> >> Cannot find the PMC 'freemarker' for this project. Check the DOAP is >> correct. >> >> Are you sure this thing pick ups the latest committed version? >> >> Thursday, November 23, 2017, 1:41:57 AM, sebb wrote: >> >>> Compare the >> >>> On 23 November 2017 at 00:21, Sergio Fernández <wik...@apache.org> wrote: >>>> Why: It does pointing to Incubator, see >>>> https://github.com/apache/incubator-freemarker-site/blob/master/doap.rdf#L45 >>>> >>>> >>>> >>>> On Wed, Nov 22, 2017 at 2:57 PM, sebb <seb...@gmail.com> wrote: >>>>> >>>>> The DOAP has the wrong pmc reference. >>>>> Compare your DOAP against other Incubator project DOAPs. >>>>> >>>>> On 22 November 2017 at 17:30, Sergio Fernández <wik...@apache.org> wrote: >>>>> > OK, but https://projects.apache.org/project.html?freemarker doesn't load >>>>> > :-/ >>>>> > >>>>> > On Wed, Nov 22, 2017 at 3:38 AM, sebb <seb...@gmail.com> wrote: >>>>> >> >>>>> >> Looks like it was a transient error. >>>>> >> >>>>> >> AFAICT it worked OK on the last run(s) >>>>> >> >>>>> >> On 21 November 2017 at 19:45, Sergio Fernández <wik...@apache.org> >>>>> >> wrote: >>>>> >> > The file is valid RDF/XML file, I can warranty that. I think the >>>>> >> > infrastructure behind projects.a.o processes those files as XML, but >>>>> >> > I >>>>> >> > can't >>>>> >> > see what could be the error. >>>>> >> > >>>>> >> > On Tue, Nov 21, 2017 at 3:52 AM, sebb <seb...@gmail.com> wrote: >>>>> >> >> >>>>> >> >> You could try an online validator. >>>>> >> >> >>>>> >> >> A quick search found be this: >>>>> >> >> >>>>> >> >> https://www.xmlvalidation.com >>>>> >> >> >>>>> >> >> I'm sure there are others. >>>>> >> >> >>>>> >> >> >>>>> >> >> On 21 November 2017 at 03:48, Sergio Fernández <wik...@apache.org> >>>>> >> >> wrote: >>>>> >> >> > Sorry, my bad. >>>>> >> >> > Fixed in de6050c6d2dfb83de20fca602533e19b26c0eade >>>>> >> >> > >>>>> >> >> > Any other details why it failed? >>>>> >> >> > >>>>> >> >> > It says "mismatched tag: line 12, column 2", but don't understand >>>>> >> >> > why. >>>>> >> >> > >>>>> >> >> > >>>>> >> >> > On Mon, Nov 20, 2017 at 6:28 PM, sebb <seb...@gmail.com> wrote: >>>>> >> >> >> >>>>> >> >> >> Please can you fix the DOAP? >>>>> >> >> >> >>>>> >> >> >> Also the following entry is wrong: >>>>> >> >> >> >>>>> >> >> >> >>>> >> >> >> >>>>> >> >> >> >>>>> >> >> >> >>>>> >> >> >> rdf:resource="http://people.apache.org/committers-by-project.html#freemarker; >>>>> >> >> >> /> >>>>> >> >> >> >>>>> >> >> >> It should be >>>>> >> >> >> >>>>> >> >> >> http://incubator.apache.org; /> >>>>> >> >> >> >>>>> >> >> >> >>>>> >> >> >> Thanks! >>>>> >> >> >> >>>>> >> >> >> >>>>> >> >> >> -- Forwarded message -- >>>>> >> >> >> From: Projects <aps...@apache.org> >>>>> >> >> >> Date: 21 November 2017 at 02:00 >>>>> >> >> >> Subject: Error when processing doap file >>>>> >> >> >> >>>>> >> >> >> >>>>> >> >> >> >>>>> >> >> >> >>>>> >> >> >> https://git-wip-us.apache.org/repos/asf?p=incubator-freemarker-site.git;a=blob_plain;f=doap.rdf;hb=HEAD: >>>>> >> >> >> To: Site Development <site-...@apache.org> >>>>> >> >> >> >>>>> >> >> >> >>>>> >> >> >> mismatched tag: line 12, column 2 >>>>> >> >> > >>>>> >> >> > >>>>> >> > >>>>> >> > >>>>> > >>>>> > >>>> >>>> >>> >> >> -- >> Thanks, >> Daniel Dekany >> > -- Thanks, Daniel Dekany
Re: Error when processing doap file https://git-wip-us.apache.org/repos/asf?p=incubator-freemarker-site.git;a=b lob_plain;f=doap.rdf;hb=HEAD:
Tuesday, November 28, 2017, 11:43:27 AM, Jacques Le Roux wrote: > Le 27/11/2017 à 19:10, Jacques Le Roux a écrit : >> Then maybe indeed we just have to wait? > It seems waiting does not help :( > > I tried to compare with > https://projects.apache.org/project.html?milagro which is smaller > http://milagro.incubator.apache.org/doap.rdf > but still don't get what could be wrong. > > Maybe we could temporarily simplify the file as much as possible > and add elements one by one to find the possible culprit/s? > > For instance starting by removing all after > rdf:resource="https://freemarker.apache.org/freemarkerdownload.html; /> > Also trying to reorder elements, using the same way than in Milagro Given that the error message is quite specific, I think we have little chance like that. My guess is still that it doesn't detect that the file was changed, for some reason. (If you change something now, it might detect that, and then you will believe that it works because of what you have changed, but it doesn't.) You know what, I ask "sebb" in another reply... > If you agree I can try that... > > My 2cts so far > > Jacques -- Thanks, Daniel Dekany
Alternative to ${exp}
This problem comes up again and again: the ${exp} syntax clashes with
the syntax of the thing the user wants to generate. So I believe we
need a Configuration option to address this. Something like
cfg.setInterpolationSyntax(FOO_INTERPOLATION_SYNTAX), and also
<#ftl interpolationSyntax="foo">.
Like any syntax option, this is potentially confusing for users and
problem for tools, but I don't think there's a way around this. Users
have to deal with those clashing ${}-s somehow, and certainly an
in-house hack will be worse and even more confusing. (Surely they can
write ${'$'}{foo} or use #noparse, but if you need a lot of those,
then it's obviously not an acceptable workaround.)
So, what the syntax would be? Some of my ideas:
- {{exp}} is probably the nicest. For the same reason it potentially
clashes with something yet again, though I guess it's unlikely
enough that neither ${exp} nor {{exp}} works for you.
- @{exp}. It's similar to ${exp}, which I think is an advantage.
There's however a very small but still real chance that for someone
both ${} and @{} clashes with what they want to generate, because
using {name} is somewhat popular.
- #{exp}. That looks like the natural choice as we use # in tags as
well (also @, though). The reason I don't like it is that
we already have #{exp} in the standard syntax, but it's deprecated.
That's not a problem technically, as you can say that if you select
the #{} syntax, then it's not deprecated, and ${} will be treated
as static text. But now if someone sees #{exp}, they can't tell if
the template uses a deprecated syntax, or it uses the alternative
interpolation syntax. Also it's perhaps more likely that for someone
both ${} and #{} clashes (e.g. in the case you generate JSF JSP-s),
than that that both ${} and @{} clashes.
- <=exp> and [=exp] depending on if you are using square- or
angle-bracket tag syntax. Look somewhat exotic... which also means
that hopefully it won't clash with anything.
There's also the idea that we just let the user specify any separator,
like `cfg.setInterpolationStart("@{"); cfg.setInterpolationEnd("}")`.
But if all kind of random syntax is possible, it's harder for users to
figure out what's going on (their syntax isn't mentioned in the
Manual, and nobody on StackOverlfow recognizes it either), and it's
more difficult to support that in tools as well. So I believe it's
better for everyone if there's one, or maybe two standard
alternatives. (Not to mention that I don't yet see how to implement
such a runtime-configured syntax with the current JavaCC-based parser.
Probably it would be a horrid hack if possible at all.)
Opinions, ideas?
--
Thanks,
Daniel Dekany
Re: Error when processing doap file https://git-wip-us.apache.org/repos/asf?p=incubator-freemarker-site.git;a=b lob_plain;f=doap.rdf;hb=HEAD:
For example https://projects.apache.org/project.html?taverna is working, and it has exactly the same asfext:pmc as us: http://incubator.apache.org; /> Maybe the project page still uses some older version of our rdf. (Surely it will be brought up against graduation that we couldn't even get the damn DOAP file right for weeks... (; ) Sunday, November 26, 2017, 11:57:28 AM, Jacques Le Roux wrote: > Not sure what > http://incubator.apache.org; /> > should contain > > When I look into > https://svn.apache.org/repos/asf/comdev/projects.apache.org/data/projects.xml > for other incubated projects it's not clear to me. > > I found none working, is > https://projects.apache.org/project.html > possible for incubated project? > > Jacques > > Le 26/11/2017 à 10:17, Daniel Dekany a écrit : >> https://projects.apache.org/project.html?freemarker says: >> >> Cannot find the PMC 'freemarker' for this project. Check the DOAP is correct. >> >> >> Thursday, November 23, 2017, 3:11:32 AM, Sergio Fernández wrote: >> >>> OK, now it should be fully compliant, with the canonical uri for the >>> podling and incubator as pmc. >>> So let's if in the next run it will be fine. >>> Thanks. >>> >>> On Wed, Nov 22, 2017 at 4:41 PM, sebb <seb...@gmail.com> wrote: >>> >>>> Compare the >>> >>>> On 23 November 2017 at 00:21, Sergio Fernández <wik...@apache.org> wrote: >>>>> Why: It does pointing to Incubator, see >>>>> https://github.com/apache/incubator-freemarker-site/ >>>> blob/master/doap.rdf#L45 >>>>> >>>>> >>>>> On Wed, Nov 22, 2017 at 2:57 PM, sebb <seb...@gmail.com> wrote: >>>>>> The DOAP has the wrong pmc reference. >>>>>> Compare your DOAP against other Incubator project DOAPs. >>>>>> >>>>>> On 22 November 2017 at 17:30, Sergio Fernández <wik...@apache.org> >>>> wrote: >>>>>>> OK, but https://projects.apache.org/project.html?freemarker doesn't >>>> load >>>>>>> :-/ >>>>>>> >>>>>>> On Wed, Nov 22, 2017 at 3:38 AM, sebb <seb...@gmail.com> wrote: >>>>>>>> Looks like it was a transient error. >>>>>>>> >>>>>>>> AFAICT it worked OK on the last run(s) >>>>>>>> >>>>>>>> On 21 November 2017 at 19:45, Sergio Fernández <wik...@apache.org> >>>>>>>> wrote: >>>>>>>>> The file is valid RDF/XML file, I can warranty that. I think the >>>>>>>>> infrastructure behind projects.a.o processes those files as XML, >>>> but >>>>>>>>> I >>>>>>>>> can't >>>>>>>>> see what could be the error. >>>>>>>>> >>>>>>>>> On Tue, Nov 21, 2017 at 3:52 AM, sebb <seb...@gmail.com> wrote: >>>>>>>>>> You could try an online validator. >>>>>>>>>> >>>>>>>>>> A quick search found be this: >>>>>>>>>> >>>>>>>>>> https://www.xmlvalidation.com >>>>>>>>>> >>>>>>>>>> I'm sure there are others. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 21 November 2017 at 03:48, Sergio Fernández <wik...@apache.org >>>>>>>>>> wrote: >>>>>>>>>>> Sorry, my bad. >>>>>>>>>>> Fixed in de6050c6d2dfb83de20fca602533e19b26c0eade >>>>>>>>>>> >>>>>>>>>>> Any other details why it failed? >>>>>>>>>>> >>>>>>>>>>> It says "mismatched tag: line 12, column 2", but don't >>>> understand >>>>>>>>>>> why. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Mon, Nov 20, 2017 at 6:28 PM, sebb <seb...@gmail.com> wrote: >>>>>>>>>>>> Please can you fix the DOAP? >>>>>>>>>>>> >>>>>>>>>>>> Also the following entry is wrong: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> rdf:resource="http://people.apache.org/committers-by- >>>> project.html#freemarker" >>>>>>>>>>>> /> >>>>>>>>>>>> >>>>>>>>>>>> It should be >>>>>>>>>>>> >>>>>>>>>>>> http://incubator.apache.org; /> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- Forwarded message -- >>>>>>>>>>>> From: Projects <aps...@apache.org> >>>>>>>>>>>> Date: 21 November 2017 at 02:00 >>>>>>>>>>>> Subject: Error when processing doap file >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> https://git-wip-us.apache.org/repos/asf?p=incubator- >>>> freemarker-site.git;a=blob_plain;f=doap.rdf;hb=HEAD: >>>>>>>>>>>> To: Site Development <site-...@apache.org> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mismatched tag: line 12, column 2 >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> > -- Thanks, Daniel Dekany
Re: Error when processing doap file https://git-wip-us.apache.org/repos/asf?p=incubator-freemarker-site.git;a=blob_plain;f=doap.rdf;hb=HEAD:
https://projects.apache.org/project.html?freemarker says: Cannot find the PMC 'freemarker' for this project. Check the DOAP is correct. Thursday, November 23, 2017, 3:11:32 AM, Sergio Fernández wrote: > OK, now it should be fully compliant, with the canonical uri for the > podling and incubator as pmc. > So let's if in the next run it will be fine. > Thanks. > > On Wed, Nov 22, 2017 at 4:41 PM, sebb <seb...@gmail.com> wrote: > >> Compare the > >> On 23 November 2017 at 00:21, Sergio Fernández <wik...@apache.org> wrote: >> > Why: It does pointing to Incubator, see >> > https://github.com/apache/incubator-freemarker-site/ >> blob/master/doap.rdf#L45 >> > >> > >> > >> > On Wed, Nov 22, 2017 at 2:57 PM, sebb <seb...@gmail.com> wrote: >> >> >> >> The DOAP has the wrong pmc reference. >> >> Compare your DOAP against other Incubator project DOAPs. >> >> >> >> On 22 November 2017 at 17:30, Sergio Fernández <wik...@apache.org> >> wrote: >> >> > OK, but https://projects.apache.org/project.html?freemarker doesn't >> load >> >> > :-/ >> >> > >> >> > On Wed, Nov 22, 2017 at 3:38 AM, sebb <seb...@gmail.com> wrote: >> >> >> >> >> >> Looks like it was a transient error. >> >> >> >> >> >> AFAICT it worked OK on the last run(s) >> >> >> >> >> >> On 21 November 2017 at 19:45, Sergio Fernández <wik...@apache.org> >> >> >> wrote: >> >> >> > The file is valid RDF/XML file, I can warranty that. I think the >> >> >> > infrastructure behind projects.a.o processes those files as XML, >> but >> >> >> > I >> >> >> > can't >> >> >> > see what could be the error. >> >> >> > >> >> >> > On Tue, Nov 21, 2017 at 3:52 AM, sebb <seb...@gmail.com> wrote: >> >> >> >> >> >> >> >> You could try an online validator. >> >> >> >> >> >> >> >> A quick search found be this: >> >> >> >> >> >> >> >> https://www.xmlvalidation.com >> >> >> >> >> >> >> >> I'm sure there are others. >> >> >> >> >> >> >> >> >> >> >> >> On 21 November 2017 at 03:48, Sergio Fernández <wik...@apache.org >> > >> >> >> >> wrote: >> >> >> >> > Sorry, my bad. >> >> >> >> > Fixed in de6050c6d2dfb83de20fca602533e19b26c0eade >> >> >> >> > >> >> >> >> > Any other details why it failed? >> >> >> >> > >> >> >> >> > It says "mismatched tag: line 12, column 2", but don't >> understand >> >> >> >> > why. >> >> >> >> > >> >> >> >> > >> >> >> >> > On Mon, Nov 20, 2017 at 6:28 PM, sebb <seb...@gmail.com> wrote: >> >> >> >> >> >> >> >> >> >> Please can you fix the DOAP? >> >> >> >> >> >> >> >> >> >> Also the following entry is wrong: >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> rdf:resource="http://people.apache.org/committers-by- >> project.html#freemarker" >> >> >> >> >> /> >> >> >> >> >> >> >> >> >> >> It should be >> >> >> >> >> >> >> >> >> >> http://incubator.apache.org; /> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Thanks! >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- Forwarded message -- >> >> >> >> >> From: Projects <aps...@apache.org> >> >> >> >> >> Date: 21 November 2017 at 02:00 >> >> >> >> >> Subject: Error when processing doap file >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> https://git-wip-us.apache.org/repos/asf?p=incubator- >> freemarker-site.git;a=blob_plain;f=doap.rdf;hb=HEAD: >> >> >> >> >> To: Site Development <site-...@apache.org> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> mismatched tag: line 12, column 2 >> >> >> >> > >> >> >> >> > >> >> >> > >> >> >> > >> >> > >> >> > >> > >> > >> -- Thanks, Daniel Dekany
Re: Error when processing doap file https://git-wip-us.apache.org/repos/asf?p=incubator-freemarker-site.git;a=blob_plain;f=doap.rdf;hb=HEAD:
This change makes me wonder if we will be executed for using
https://freemarker.apache.org instead of the
freemarker.incubator.apache.org version (".incubator" HTTP 301
redirects to freemarker.apache.org). (Would be fun to change domain
name yet again...)
Thursday, November 23, 2017, 3:11:32 AM, Sergio Fernández wrote:
> OK, now it should be fully compliant, with the canonical uri for the
> podling and incubator as pmc.
> So let's if in the next run it will be fine.
> Thanks.
>
> On Wed, Nov 22, 2017 at 4:41 PM, sebb <seb...@gmail.com> wrote:
>
>> Compare the >
>> On 23 November 2017 at 00:21, Sergio Fernández <wik...@apache.org> wrote:
>> > Why: It does pointing to Incubator, see
>> > https://github.com/apache/incubator-freemarker-site/
>> blob/master/doap.rdf#L45
>> >
>> >
>> >
>> > On Wed, Nov 22, 2017 at 2:57 PM, sebb <seb...@gmail.com> wrote:
>> >>
>> >> The DOAP has the wrong pmc reference.
>> >> Compare your DOAP against other Incubator project DOAPs.
>> >>
>> >> On 22 November 2017 at 17:30, Sergio Fernández <wik...@apache.org>
>> wrote:
>> >> > OK, but https://projects.apache.org/project.html?freemarker doesn't
>> load
>> >> > :-/
>> >> >
>> >> > On Wed, Nov 22, 2017 at 3:38 AM, sebb <seb...@gmail.com> wrote:
>> >> >>
>> >> >> Looks like it was a transient error.
>> >> >>
>> >> >> AFAICT it worked OK on the last run(s)
>> >> >>
>> >> >> On 21 November 2017 at 19:45, Sergio Fernández <wik...@apache.org>
>> >> >> wrote:
>> >> >> > The file is valid RDF/XML file, I can warranty that. I think the
>> >> >> > infrastructure behind projects.a.o processes those files as XML,
>> but
>> >> >> > I
>> >> >> > can't
>> >> >> > see what could be the error.
>> >> >> >
>> >> >> > On Tue, Nov 21, 2017 at 3:52 AM, sebb <seb...@gmail.com> wrote:
>> >> >> >>
>> >> >> >> You could try an online validator.
>> >> >> >>
>> >> >> >> A quick search found be this:
>> >> >> >>
>> >> >> >> https://www.xmlvalidation.com
>> >> >> >>
>> >> >> >> I'm sure there are others.
>> >> >> >>
>> >> >> >>
>> >> >> >> On 21 November 2017 at 03:48, Sergio Fernández <wik...@apache.org
>> >
>> >> >> >> wrote:
>> >> >> >> > Sorry, my bad.
>> >> >> >> > Fixed in de6050c6d2dfb83de20fca602533e19b26c0eade
>> >> >> >> >
>> >> >> >> > Any other details why it failed?
>> >> >> >> >
>> >> >> >> > It says "mismatched tag: line 12, column 2", but don't
>> understand
>> >> >> >> > why.
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On Mon, Nov 20, 2017 at 6:28 PM, sebb <seb...@gmail.com> wrote:
>> >> >> >> >>
>> >> >> >> >> Please can you fix the DOAP?
>> >> >> >> >>
>> >> >> >> >> Also the following entry is wrong:
>> >> >> >> >>
>> >> >> >> >> > >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> rdf:resource="http://people.apache.org/committers-by-
>> project.html#freemarker"
>> >> >> >> >> />
>> >> >> >> >>
>> >> >> >> >> It should be
>> >> >> >> >>
>> >> >> >> >> http://incubator.apache.org; />
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> Thanks!
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> -- Forwarded message --
>> >> >> >> >> From: Projects <aps...@apache.org>
>> >> >> >> >> Date: 21 November 2017 at 02:00
>> >> >> >> >> Subject: Error when processing doap file
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> https://git-wip-us.apache.org/repos/asf?p=incubator-
>> freemarker-site.git;a=blob_plain;f=doap.rdf;hb=HEAD:
>> >> >> >> >> To: Site Development <site-...@apache.org>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> mismatched tag: line 12, column 2
>> >> >> >> >
>> >> >> >> >
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >
>> >
>>
--
Thanks,
Daniel Dekany
Re: Attempting graduation?
I have committed this last version then. Wednesday, November 22, 2017, 11:11:22 AM, Jacques Le Roux wrote: > +1 > > Jacques > > > Le 22/11/2017 à 09:41, Daniel Dekany a écrit : >> Yeas, it's less twisted that way, though the meaning slightly differs. >> I would refine it further: >> >> Usually, a general-purpose programming language (like Java) is used to >> prepare the data (issue database queries, do business calculations). >> Then, Apache FreeMarker displays that prepared data using templates. >> >> >> Tuesday, November 21, 2017, 9:48:24 PM, Denis Bredelet wrote: >> >>> Hi, >>> >>> I would like to change that sentence in the description: >>>You meant to prepare the data to display in a real >>> programming language, like issue database queries and do business >>> calculations, and then the template displays that already prepared data. >>> >>> What do you think of: >>> A general programming language is used to prepare the data, issue >>> database queries and do business calculations. Then the Apache >>> FreeMarker template engine displays that prepared data using templates. >>> >>> Cheers, >>> — Denis. >>> >>>> On 21 Nov 2017, at 19:47, Sergio Fernández <wik...@apache.org> wrote: >>>> >>>> On Tue, Nov 21, 2017 at 1:06 AM, Daniel Dekany <ddek...@apache.org> wrote: >>>> >>>>> Monday, November 20, 2017, 10:42:11 PM, Sergio Fernández wrote: >>>>> >>>>>> sorry, because I think I've created some confusion on this. Let me try to >>>>>> explain my self, because there are to aspects on this: >>>>>> >>>>>> 1) From a pure ASF perspective, host the DOAP file from Git is fine. The >>>>>> system behind projects.a.o will retrieve it and further process it. >>>>>> >>>>>> 2) From a broader Semantic Web perspective, ideally we should have the >>>>> DOAP >>>>>> file publicly available from the project web site. >>>>>> >>>>>> I aim for 2, that's why I played with the site build. But staying at 1 >>>>>> should be enough. I hope now it's a bit clearer. >>>>> I see, but the URL we put into projects.xml is a HTTP URL, so why not >>>>> just add a link with that target address on the home page? That's one >>>>> less copy of that file that can go out if sync as well. (At that point >>>>> it doesn't even make sense anymore that it's inside "site", but >>>>> whatever...) >>>> >>>> it does for provenance reasons. But you can keep it at git, fine. > > -- Thanks, Daniel Dekany
Re: Attempting graduation?
Yeas, it's less twisted that way, though the meaning slightly differs. I would refine it further: Usually, a general-purpose programming language (like Java) is used to prepare the data (issue database queries, do business calculations). Then, Apache FreeMarker displays that prepared data using templates. Tuesday, November 21, 2017, 9:48:24 PM, Denis Bredelet wrote: > Hi, > > I would like to change that sentence in the description: > You meant to prepare the data to display in a real > programming language, like issue database queries and do business > calculations, and then the template displays that already prepared data. > > What do you think of: > A general programming language is used to prepare the data, issue > database queries and do business calculations. Then the Apache > FreeMarker template engine displays that prepared data using templates. > > Cheers, > — Denis. > >> On 21 Nov 2017, at 19:47, Sergio Fernández <wik...@apache.org> wrote: >> >> On Tue, Nov 21, 2017 at 1:06 AM, Daniel Dekany <ddek...@apache.org> wrote: >> >>> Monday, November 20, 2017, 10:42:11 PM, Sergio Fernández wrote: >>> >>>> sorry, because I think I've created some confusion on this. Let me try to >>>> explain my self, because there are to aspects on this: >>>> >>>> 1) From a pure ASF perspective, host the DOAP file from Git is fine. The >>>> system behind projects.a.o will retrieve it and further process it. >>>> >>>> 2) From a broader Semantic Web perspective, ideally we should have the >>> DOAP >>>> file publicly available from the project web site. >>>> >>>> I aim for 2, that's why I played with the site build. But staying at 1 >>>> should be enough. I hope now it's a bit clearer. >>> >>> I see, but the URL we put into projects.xml is a HTTP URL, so why not >>> just add a link with that target address on the home page? That's one >>> less copy of that file that can go out if sync as well. (At that point >>> it doesn't even make sense anymore that it's inside "site", but >>> whatever...) >> >> >> it does for provenance reasons. But you can keep it at git, fine. > -- Thanks, Daniel Dekany
Re: Attempting graduation?
Sunday, November 19, 2017, 9:37:45 PM, Sergio Fernández wrote: > On Sat, Nov 18, 2017 at 7:48 PM, Daniel Dekany <ddek...@apache.org> wrote: >> >> I guess it's time to add the reference to >> https://svn.apache.org/repos/asf/comdev/projects.apache. >> org/data/projects.xml. >> > > Right. I tried to get it published to > https://freemarker.apache.org/doap.rdf > to add that reference, but I didn't manage to locally build the site due > some dependencies' problem. I'll try again later. You mean a problem with incubator-freemarker-site Ant build? What was that? But, you don't need to build the incubator-freemarker-site for this. Just upload the doap.rdf to the "asf-site" branch of incubator-freemarker-site directly. > In the meantime I've added the reference to git in > http://svn.apache.org/r1815757, so it should be available at > https://projects.apache.org/project.html?freemarker in the next build (2 AM > UTC). -- Thanks, Daniel Dekany
Re: Attempting graduation?
Saturday, November 18, 2017, 10:14:09 AM, Jacques Le Roux wrote: > Le 18/11/2017 à 00:18, Daniel Dekany a écrit : >> Friday, November 17, 2017, 11:01:42 PM, Jacques Le Roux wrote: >> >>> Le 17/11/2017 à 13:10, Daniel Dekany a écrit : >>>> Note sure what the recommended place is... but as far as I'm >>>> concerned, putting it into the root if the "site" repo >>>> (git://git.apache.org/incubator-freemarker-site.git) is fine. >>> Done, please check >> I have committed some fixes. >> >> Some others that came to my mind after that: Others use https links >> even for GitRepository/location. Also, we have multiple repositories >> (https://freemarker.apache.org/sourcecode.html). > Actually yesterday to be able to push I had to use > https://git-wip-us.apache.org/repos/asf/incubator-freemarker.git like it's > documented at > https://freemarker.apache.org/sourcecode.html > git://git.apache.org/incubator-freemarker.git did not work, I was rejected > with this msg > fatal: remote error: access denied or repository not exported: > /incubator-freemarker-site.git > > So maybe we should rather use that in the doap Yes. > or even > https://freemarker.apache.org/sourcecode.html? Hardly. But certainly we need to specify all the repositories, like in http://taverna.incubator.apache.org/doap.rdf. >> asfext:pmc just points to the project home page in the DOAP of some >> other projects that I have randomly looked at (from >> https://svn.apache.org/repos/asf/comdev/projects.apache.org/data/projects.xml), >> and to http://incubator.apache.org for the incubating ones. > Yep, OFBiz has a custom page for that > https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+PMC+Members+and+Committers > but officially it's at > https://projects.apache.org/committee.html?ofbiz > So I think we can wait to have the later available (when TLPised) > >> Whether a PPMC needs a PMC DOAP file... hopefully it's documented >> somewhere, someone will have to find it. (I guess not, as the PMC is >> the IPMC for now.) > I think it's not needed yet, because only TLPs have PMCs > > Jacques > -- Thanks, Daniel Dekany
Re: Scope of variable for <#nested> while using #import
Friday, November 17, 2017, 3:55:22 PM, Daniel Dekany wrote:
> #assign sets the variable in the current namespace. Each #include-d
I wanted to write #import"-ed above... #include-d templates use the
namespace of the includer.
> template has its own namespace, plus the the topmost template has its
> own namespace (the "main" namespace). So if you use #assign like that,
> then in the other namespace you had to write ${widget.name}. You might
> want to use #global instead, and then the variable is visible from
> everywhere (unless it's shadowed by a variable of the same name in the
> same namespace). (It's also possible to pass back a value like
> <#nested "FreeMarker World"> and then
> <@widget.getName ; name>${name}. Also you should write
> a #function if you just want to get a value, not a macro, as that has
> a return value.)
>
> See also: https://freemarker.apache.org/docs/dgui_misc_namespace.html
>
>
> Friday, November 17, 2017, 1:56:03 PM, Swapnil Mane wrote:
>
>> Dear FreeMarker team,
>>
>> First I would like to thank you for creating such a nice template engine, I
>> personally liked it very much :-)
>>
>> I need your help in an issue,
>>
>> While using <#nested>, the variable I defined using assign is not
>> accessible in nested code.
>>
>> Here is the more details
>>
>> 1.) I have a macro file having Widgets.ftl
>>
>> {code}
>>
>> <#macro getName>
>> <#assign name = "FreeMarker World"/>
>> <#nested>
>>
>>
>> {code}
>>
>> 2.) I have included the above file in another file using <#import>
>>
>> {code}
>>
>> <#import "Widgets.ftl" as widget>
>> <@widget.getName>
>> Hi ${name!}
>>
>>
>> {code}
>>
>> Expected output - Hi FreeMarker World
>> Actual output - Hi
>>
>>
>> Here the value of 'name' variable is not setting properly if assign is used.
>> But when I set it using global, everything work as expected.
>>
>> {code}
>> <#global name = "FreeMarker World"/>
>> {code}
>>
>> The similar types of macros will be heavily used in my application and
>> setting it at global level will cause performance and memory issue. So, I
>> want to set value of variable using assign.
>>
>> Please let me know if I am missing anything.
>> Thanks again for your time and contribution.
>>
>> - Best Regards,
>> Swapnil M Mane
>
--
Thanks,
Daniel Dekany
Re: Attempting graduation?
Friday, November 17, 2017, 11:43:15 AM, Jacques Le Roux wrote: > Hi Daniel, > > Inline... > > Le 13/11/2017 à 23:14, Daniel Dekany a écrit : >> Monday, November 13, 2017, 8:58:51 PM, Sergio Fernández wrote: >> >>> No idea why that thread is not in my inbox. >>> >>> Anyway I still have the same idea of keeping around the project if my >>> support can be helpful, technically or whatever. >> That's good news, thanks! Of course it can be helpful, like to check >> releases sometimes, as we need 3 votes. >> >> As of this thread... I know that we have >> https://cwiki.apache.org/confluence/display/FREEMARKER/Apache+FreeMarker+Project+Maturity+Model, >> and according that everything is fine formally, but it isn't. I ran >> through some documents on the weekend, and found and fixed a few >> smaller problems on the home page. > I had a look at this wiki page and it sounds quite good to me, > nothing missing or needed to be amended now? Not on the Wiki page AFAR... Otherwise, I don't know, I had to read through all the ASF documentation to check. >> I have also noticed (but not fixed) >> that we have no DOAP file >> (https://www.apache.org/foundation/marks/pmcs#metadata), and somewhere >> I have read that that's needed for graduation (can't find where now). > I can create the DOAP file based on my experience with OFBiz: > https://svn.apache.org/repos/asf/ofbiz/site/doap_OFBiz.rdf > Where would you suggest to put it? Note sure what the recommended place is... but as far as I'm concerned, putting it into the root if the "site" repo (git://git.apache.org/incubator-freemarker-site.git) is fine. > What would be the equivalent of > > Apache OFBiz is an open source > enterprise automation software project > > Apache OFBiz is an open source product for the automation of > enterprise processes that includes framework components and business > applications > for ERP (Enterprise Resource Planning), CRM (Customer > Relationship Management), E-Business / E-Commerce, SCM (Supply Chain > Management), > MRP (Manufacturing Resource Planning), MMS/EAM (Maintenance > Management System/Enterprise Asset Management). > Apache OFBiz provides a foundation and starting point for > reliable, secure and scalable enterprise solutions. > > Java > rdf:resource="http://projects.apache.org/category/http; /> > ? The short description: FreeMarker is a template engine, i.e. a generic tool to generate text output based on templates. FreeMarker is implemented in Java as a class library for programmers. The description is (from our home page): Apache FreeMarker is a template engine: a Java library to generate text output (HTML web pages, e-mails, configuration files, source code, etc.) based on templates and changing data. Templates are written in the FreeMarker Template Language (FTL), which is a simple, specialized language (not a full-blown programming language). You meant to prepare the data to display in a real programming language, like issue database queries and do business calculations, and then the template displays that already prepared data. In the template you are focusing on how to present the data, and outside the template you are focusing on what data to present. Location... > The rest I think I can take care of, or ask more if needed... > > Jacques > >> >> And that's just what I have noticed, and I haven't read through all >> documents yet. So can someone else also run through things? >> >>> On Nov 8, 2017 23:17, "Daniel Dekany" <ddek...@apache.org> wrote: >>> >>>> Thursday, November 9, 2017, 3:05:26 AM, Sergio Fernández wrote: >>>> >>>>> Sorry, I can't find that thread... >>>> And I can't link to that, as I have no right to use >>>> https://mail-search.apache.org/pmc/private-arch/freemarker-private/. >>>> But it doesn't mater. The question was that if FreeMarker graduates, >>>> will you stay in the FreeMarker PMC? (One year ago or so you said that >>>> you would, but I wanted that to be reassured.) >>>> >>>>> On Tue, Nov 7, 2017 at 11:10 PM, Daniel Dekany <ddek...@apache.org> >>>> wrote: >>>>>> Wednesday, November 8, 2017, 6:48:07 AM, Sergio Fernández wrote: >>>>>> >>>>>>> Nothing really that I can see. We should go for discusion seriously >>>> and >>>>>>> voting towards graduation ;-) >>>>>> There are the things quoted below. Also, please look at the private >>>>>> list (there
Re: Home page content changes - please review
Thanks, fixed. Monday, November 13, 2017, 5:13:47 PM, Ralph Goers wrote: > Aggreement s/b Agreement. > > Ralph > > >> On Nov 13, 2017, at 1:55 AM, Daniel Dekany <ddek...@apache.org> wrote: >> >> I have added a such statement to the README.md now: >> https://github.com/apache/incubator-freemarker/ >> >> Regarding pull request on Github >> >> By sending a pull request you grant the Apache Software Foundation >> sufficient rights to use and release the submitted work under the >> Apache license. You grant the same rights (copyright license, patent >> license, etc.) to the Apache Software Foundation as if you have >> signed a Contributor License Aggreement. For contributions that are >> judged to be non-trivial, you will be asked to actually signing a >> Contributor License Aggreement. >> >> Though it's not shown in a popup with a checkbox before someone makes >> a pull request, so anybody can say that they haven't seen it... it's >> certainly better than nothing. >> >> Monday, November 13, 2017, 12:36:24 AM, Ralph Goers wrote: >> >>> An ICLA is always encouraged but is not required if the committer >>> knows for certain the contributor intends for their contribution to >>> be Apache licensed. Simply having a statement in the main README at >>> GitHub with a statement to the effect that all contributions >>> submitted as pull requests are under the Apache license would be enough. >>> >>> Ralph >>> >>>> On Nov 11, 2017, at 12:04 PM, Daniel Dekany <ddek...@apache.org> wrote: >>>> >>>> Months ago we had discussion here about when an ICLA or CCLA is needed for >>>> merging Girhub PR. To reflect that, I have updated this part: >>>> https://freemarker.apache.org/committer-howto.html#merging-pull-request >>>> >>>> Do you agree? Especially if you are PPMC, it would be good if you >>>> answer. >>>> >>>> >>>> Also, the left side menu has changed (like here: >>>> https://freemarker.apache.org/ ), as I have removed the >>>> "Miscellaneous" category, and added the "Foundation" category. The >>>> last is to make certain ASF related matters more accessible. The items >>>> that were under "Miscellaneous": >>>> - sf.net project link was removed (nobody should use that anymore) >>>> - "Source code" was moved to Community (doesn't fit elsewhere...) >>>> - "Project history" was moved under "Foundation" >>>> >>>> -- >>>> Thanks, >>>> Daniel Dekany >>>> >>>> >>> >>> >>> >> >> -- >> Thanks, >> Daniel Dekany >> >> > -- Thanks, Daniel Dekany
Re: AW: AW: Changing official domain to freemarker.apache.org now? Was: Migrating [try.]freemarker.org to HTTPS, anyone?
With that link it works. Note my comment there. Friday, November 10, 2017, 5:51:50 PM, Jacques Le Roux wrote: > That https://issues.apache.org/jira/browse/INFRA-15476 ? > > Jacques > > > Le 10/11/2017 à 16:39, Daniel Dekany a écrit : >> I have no permission to see it. >> >> >> Friday, November 10, 2017, 3:26:56 PM, Jacques Le Roux wrote: >> >>> I have created >>> https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-15476 >>> >>> For that... >>> >>> Jacques >>> >>> >>> Le 09/11/2017 à 21:09, Daniel Dekany a écrit : >>>> Thanks! When we have a certificate installed, it will be merged. >>>> >>>> >>>> Thursday, November 9, 2017, 7:23:54 PM, Riehemann, Michael wrote: >>>> >>>>> I openend 2 pull-requests with the changes for you (since >>>>> https://freemarker.apache.org/ works fine for me): >>>>> >>>>> https://github.com/apache/incubator-freemarker/pull/38 >>>>> https://github.com/apache/incubator-freemarker-site/pull/7 >>>>> >>>>> >>>>> -Ursprüngliche Nachricht- >>>>> Von: Daniel Dekany [mailto:ddek...@apache.org] >>>>> Gesendet: Donnerstag, 9. November 2017 15:36 >>>>> An: Jacques Le Roux <dev@freemarker.incubator.apache.org> >>>>> Betreff: Re: AW: Changing official domain to freemarker.apache.org >>>>> now? Was: Migrating [try.]freemarker.org to HTTPS, anyone? >>>>> >>>>> As of the links on the web pages, they are generated based on >>>>> https://github.com/apache/incubator-freemarker/blob/2.3-gae/src/manual/en_US/docgen.cjson >>>>> and >>>>> https://github.com/apache/incubator-freemarker-site/blob/master/src/main/docgen/docgen.cjson, >>>>> so we can update them easily. >>>>> >>>>> >>>>> Thursday, November 9, 2017, 3:15:56 PM, Jacques Le Roux wrote: >>>>> >>>>>> Hi Michael, >>>>>> >>>>>> Yes this was the start of this discussion https://s.apache.org/JFBa :) >>>>>> >>>>>> freemarker.apache.org is pupettized. I see 2 places where it's >>>>>> referenced >>>>>> >>>>>> https://github.com/apache/infrastructure-puppet/blob/deployment/data/n >>>>>> odes/themis.apache.org.eyaml >>>>>> >>>>>> https://github.com/apache/infrastructure-puppet/blob/deployment/data/n >>>>>> odes/tlp-eu-mid.apache.org.eyaml >>>>>> >>>>>> AFAIK, we don't need to change anything there or we will see later >>>>>> >>>>>> But in order to use a letsencrypt certificate we need to change >>>>>> >>>>>> >>>>>> https://github.com/apache/infrastructure-puppet.git/data/nodes/freemar >>>>>> ker-vm.apache.org.yaml >>>>>> >>>>>> I'm looking at it and let you know if I need some help >>>>>> >>>>>> Thanks >>>>>> >>>>>> Jacques >>>>>> >>>>>> >>>>>> Le 09/11/2017 à 11:24, Riehemann, Michael a écrit : >>>>>>> Hi! >>>>>>> >>>>>>> I just checked freemarker.org and the redirection to >>>>>>> freemarker.apache.org works. But I would suggest to change the 301 to >>>>>>> HTTPS too! >>>>>>> All links on the website and the documentation are http links instead >>>>>>> of https. >>>>>>> It would be nice to redirect everything to https. >>>>>>> If you need any help or some Pull-Request, just give me a hint. >>>>>>> >>>>>>> Thank you, >>>>>>> Michael >>>>>>> >>>>>>> -Ursprüngliche Nachricht- >>>>>>> Von: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com] >>>>>>> Gesendet: Samstag, 4. November 2017 13:07 >>>>>>> An: dev@freemarker.incubator.apache.org >>>>>>> Betreff: Re: Changing official domain to freemarker.apache.org now? >>>>>>> Was: Migrating [try.]freemarker.org to HTTPS, anyone? >>>>>>> >>>>>>> Le 04/11/2017 à 11:52, Daniel Dekany a écrit : >>>>>>>> The freemarker.org domain is now changed to (HTTP 301 redirects to) >>>>>>>> freemarker.apache.org, so that this won't stand in the way of >>>>>>>> graduation. (The change was submitted to Google Webmasters Tools and >>>>>>>> Google Custom Search as well; it may take a while until that will >>>>>>>> have >>>>>>>> effect.) >>>>>>> Works already here >>>>>>> >>>>>>> Jacques >>>>>>>> The try.freemarker.org domain is not yet changed. I'm not sure if >>>>>>>> that will be a problem during graduation. (I'm somewhat reluctant to >>>>>>>> do changes until we know what our domain will be. Like in case we >>>>>>>> can't be TLP but a subproject, we can't use freemarker.apache.org, I >>>>>>>> guess.) >>>>>>>> >>>>>>>> >>>>>>>> Wednesday, October 25, 2017, 11:20:36 AM, Jacopo Cappellato wrote: >>>>>>>> >>>>>>>>> On Tue, Oct 24, 2017 at 3:12 AM, Ralph Goers >>>>>>>>> <ralph.go...@dslextreme.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> There is no requirement that you ever get rid of the >>>>>>>>>> freemarker.org domain. This is not the first project to have its own >>>>>>>>>> domain. >>>>>>>>>> >>>>>>>>> Exactly. For example OFBiz owns the ofbiz.org domain since before >>>>>>>>> the graduation (2006) and since then the ASF has maintained the >>>>>>>>> redirection to the canonical ofbiz.apache.org. >>>>>>>>> >>>>>>>>> Jacopo >>>>> -- >>>>> Thanks, >>>>>Daniel Dekany >>>>> >>> > > -- Thanks, Daniel Dekany
Re: AW: AW: Changing official domain to freemarker.apache.org now? Was: Migrating [try.]freemarker.org to HTTPS, anyone?
I have no permission to see it. Friday, November 10, 2017, 3:26:56 PM, Jacques Le Roux wrote: > I have created > https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-15476 > > For that... > > Jacques > > > Le 09/11/2017 à 21:09, Daniel Dekany a écrit : >> Thanks! When we have a certificate installed, it will be merged. >> >> >> Thursday, November 9, 2017, 7:23:54 PM, Riehemann, Michael wrote: >> >>> I openend 2 pull-requests with the changes for you (since >>> https://freemarker.apache.org/ works fine for me): >>> >>> https://github.com/apache/incubator-freemarker/pull/38 >>> https://github.com/apache/incubator-freemarker-site/pull/7 >>> >>> >>> -Ursprüngliche Nachricht- >>> Von: Daniel Dekany [mailto:ddek...@apache.org] >>> Gesendet: Donnerstag, 9. November 2017 15:36 >>> An: Jacques Le Roux <dev@freemarker.incubator.apache.org> >>> Betreff: Re: AW: Changing official domain to freemarker.apache.org >>> now? Was: Migrating [try.]freemarker.org to HTTPS, anyone? >>> >>> As of the links on the web pages, they are generated based on >>> https://github.com/apache/incubator-freemarker/blob/2.3-gae/src/manual/en_US/docgen.cjson >>> and >>> https://github.com/apache/incubator-freemarker-site/blob/master/src/main/docgen/docgen.cjson, >>> so we can update them easily. >>> >>> >>> Thursday, November 9, 2017, 3:15:56 PM, Jacques Le Roux wrote: >>> >>>> Hi Michael, >>>> >>>> Yes this was the start of this discussion https://s.apache.org/JFBa :) >>>> >>>> freemarker.apache.org is pupettized. I see 2 places where it's >>>> referenced >>>> >>>> https://github.com/apache/infrastructure-puppet/blob/deployment/data/n >>>> odes/themis.apache.org.eyaml >>>> >>>> https://github.com/apache/infrastructure-puppet/blob/deployment/data/n >>>> odes/tlp-eu-mid.apache.org.eyaml >>>> >>>> AFAIK, we don't need to change anything there or we will see later >>>> >>>> But in order to use a letsencrypt certificate we need to change >>>> >>>> >>>> https://github.com/apache/infrastructure-puppet.git/data/nodes/freemar >>>> ker-vm.apache.org.yaml >>>> >>>> I'm looking at it and let you know if I need some help >>>> >>>> Thanks >>>> >>>> Jacques >>>> >>>> >>>> Le 09/11/2017 à 11:24, Riehemann, Michael a écrit : >>>>> Hi! >>>>> >>>>> I just checked freemarker.org and the redirection to >>>>> freemarker.apache.org works. But I would suggest to change the 301 to >>>>> HTTPS too! >>>>> All links on the website and the documentation are http links instead of >>>>> https. >>>>> It would be nice to redirect everything to https. >>>>> If you need any help or some Pull-Request, just give me a hint. >>>>> >>>>> Thank you, >>>>> Michael >>>>> >>>>> -Ursprüngliche Nachricht- >>>>> Von: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com] >>>>> Gesendet: Samstag, 4. November 2017 13:07 >>>>> An: dev@freemarker.incubator.apache.org >>>>> Betreff: Re: Changing official domain to freemarker.apache.org now? Was: >>>>> Migrating [try.]freemarker.org to HTTPS, anyone? >>>>> >>>>> Le 04/11/2017 à 11:52, Daniel Dekany a écrit : >>>>>> The freemarker.org domain is now changed to (HTTP 301 redirects to) >>>>>> freemarker.apache.org, so that this won't stand in the way of >>>>>> graduation. (The change was submitted to Google Webmasters Tools and >>>>>> Google Custom Search as well; it may take a while until that will >>>>>> have >>>>>> effect.) >>>>> Works already here >>>>> >>>>> Jacques >>>>>> The try.freemarker.org domain is not yet changed. I'm not sure if >>>>>> that will be a problem during graduation. (I'm somewhat reluctant to >>>>>> do changes until we know what our domain will be. Like in case we >>>>>> can't be TLP but a subproject, we can't use freemarker.apache.org, I >>>>>> guess.) >>>>>> >>>>>> >>>>>> Wednesday, October 25, 2017, 11:20:36 AM, Jacopo Cappellato wrote: >>>>>> >>>>>>> On Tue, Oct 24, 2017 at 3:12 AM, Ralph Goers >>>>>>> <ralph.go...@dslextreme.com> >>>>>>> wrote: >>>>>>> >>>>>>>> There is no requirement that you ever get rid of the >>>>>>>> freemarker.org domain. This is not the first project to have its own >>>>>>>> domain. >>>>>>>> >>>>>>> Exactly. For example OFBiz owns the ofbiz.org domain since before >>>>>>> the graduation (2006) and since then the ASF has maintained the >>>>>>> redirection to the canonical ofbiz.apache.org. >>>>>>> >>>>>>> Jacopo >>>> >>> -- >>> Thanks, >>> Daniel Dekany >>> > > -- Thanks, Daniel Dekany
Re: AW: Changing official domain to freemarker.apache.org now? Was: Migrating [try.]freemarker.org to HTTPS, anyone?
Thursday, November 9, 2017, 11:24:10 AM, Riehemann, Michael wrote: > Hi! > > I just checked freemarker.org and the redirection to > freemarker.apache.org works. But I would suggest to change the 301 to HTTPS > too! > All links on the website and the documentation are http links instead of > https. > It would be nice to redirect everything to https. > If you need any help or some Pull-Request, just give me a hint. Hi, It was always just HTTP, not HTTPS. (Coincidentally, we have discussed recently that we will switch to HTTPS... one of us said he will manage that.) > Thank you, > Michael > > -Ursprüngliche Nachricht- > Von: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com] > Gesendet: Samstag, 4. November 2017 13:07 > An: dev@freemarker.incubator.apache.org > Betreff: Re: Changing official domain to freemarker.apache.org now? > Was: Migrating [try.]freemarker.org to HTTPS, anyone? > > Le 04/11/2017 à 11:52, Daniel Dekany a écrit : >> The freemarker.org domain is now changed to (HTTP 301 redirects to) >> freemarker.apache.org, so that this won't stand in the way of >> graduation. (The change was submitted to Google Webmasters Tools and >> Google Custom Search as well; it may take a while until that will have >> effect.) > Works already here > > Jacques >> >> The try.freemarker.org domain is not yet changed. I'm not sure if that >> will be a problem during graduation. (I'm somewhat reluctant to do >> changes until we know what our domain will be. Like in case we can't >> be TLP but a subproject, we can't use freemarker.apache.org, I guess.) >> >> >> Wednesday, October 25, 2017, 11:20:36 AM, Jacopo Cappellato wrote: >> >>> On Tue, Oct 24, 2017 at 3:12 AM, Ralph Goers >>> <ralph.go...@dslextreme.com> >>> wrote: >>> >>>> There is no requirement that you ever get rid of the freemarker.org >>>> domain. This is not the first project to have its own domain. >>>> >>> Exactly. For example OFBiz owns the ofbiz.org domain since before the >>> graduation (2006) and since then the ASF has maintained the >>> redirection to the canonical ofbiz.apache.org. >>> >>> Jacopo > -- Thanks, Daniel Dekany
Re: Attempting graduation?
Thursday, November 9, 2017, 3:05:26 AM, Sergio Fernández wrote: > Sorry, I can't find that thread... And I can't link to that, as I have no right to use https://mail-search.apache.org/pmc/private-arch/freemarker-private/. But it doesn't mater. The question was that if FreeMarker graduates, will you stay in the FreeMarker PMC? (One year ago or so you said that you would, but I wanted that to be reassured.) > On Tue, Nov 7, 2017 at 11:10 PM, Daniel Dekany <ddek...@apache.org> wrote: > >> Wednesday, November 8, 2017, 6:48:07 AM, Sergio Fernández wrote: >> >> > Nothing really that I can see. We should go for discusion seriously and >> > voting towards graduation ;-) >> >> There are the things quoted below. Also, please look at the private >> list (there was a question if you still intend to remain in the PMC >> after graduation). >> >> > On Nov 7, 2017 20:02, "Daniel Dekany" <ddek...@apache.org> wrote: >> > >> >> So, we have released 2.3.27, and has changed the domain of the home >> >> page (not of try.freemarker.org though... is that a problem?). What's >> >> next? Anyone? >> >> >> >> >> >> Monday, October 23, 2017, 3:18:54 PM, Daniel Dekany wrote: >> >> >> >> > Monday, October 23, 2017, 4:04:54 PM, Jacopo Cappellato wrote: >> >> > >> >> >> +1 for the migration. >> >> >> And right after that I think we should start the graduation process. >> >> > >> >> > Agreed regarding graduation. (We certainly should release 2.3.27 >> >> > before that, but it's very close anyway, hopefully.) >> >> > >> >> > Related: >> >> > >> >> > - >> >> > https://cwiki.apache.org/confluence/display/FREEMARKER/ >> >> Apache+FreeMarker+Project+Maturity+Model >> >> > >> >> > - http://incubator.apache.org/projects/freemarker.html: >> >> > Here some dates are year only. >> >> > >> >> > - https://whimsy.apache.org/roster/ppmc/freemarker: >> >> > This has some glitches, like it states "No Release Yet/Binary has >> >> > licensing issues"... will have to update this somehow. >> >> > >> >> >> Jacopo >> >> >> >> >> >> On Mon, Oct 23, 2017 at 11:48 AM, Daniel Dekany <ddek...@apache.org> >> >> wrote: >> >> >> >> >> >>> As this issue that we aren't using an apache.org domain comes up >> again >> >> >>> and again, I propose that we switch to freemarker.apache.org now. >> Also >> >> >>> to try.freemarker.apache.org. Anybody for or against it? >> >> >>> >> >> >>> >> >> >>> Friday, October 20, 2017, 10:18:01 PM, Ralph Goers wrote: >> >> >>> >> >> >>> > >> >> >>> >> On Oct 20, 2017, at 5:59 AM, Daniel Dekany <ddek...@apache.org> >> >> wrote: >> >> >>> >> >> >> >>> >> Friday, October 20, 2017, 12:24:30 PM, Jacques Le Roux wrote: >> >> >>> >> >> >> >>> >>> Le 01/10/2017 à 23:27, Daniel Dekany a écrit : >> >> >>> >>>> Sunday, October 1, 2017, 8:26:53 PM, Jacques Le Roux wrote: >> >> >>> >>>> >> >> >>> >>>>> Le 23/09/2017 à 08:44, Daniel Dekany a écrit : >> >> >>> >>>>>> Friday, September 22, 2017, 11:17:59 PM, Jacques Le Roux >> wrote: >> >> >>> >>>>>> >> >> >>> >>>>>>> Le 22/09/2017 à 22:22, Daniel Dekany a écrit : >> >> >>> >>>>>>>> Google doesn't like plain HTTP sites as we know (SEO), >> also I >> >> hear >> >> >>> >>>>>>>> that starting from October they want to show warning in >> >> Chrome if >> >> >>> you >> >> >>> >>>>>>>> have forms on your page. We do have forms... On all page >> under >> >> >>> >>>>>>>> http://freemarker.org/docs/ there's a search field, and >> >> >>> >>>>>>>> http://try.freemarker.org/ is nothing but a form. >> >> >>> >>>>>>>> >> &g
New committer and PMC member: Jacques Le Roux
The Project Management Committee (PMC) for Apache FreeMarker (incubating) has invited Jacques Le Roux to become a committer, and also a PMC member, and we are pleased to announce that he has accepted. Being a committer enables easier contribution to the project since there is no need to go via the patch submission process. This should enable better productivity. Being a PMC member enables assistance with the management and to guide the direction of the project. -- Thanks, Daniel Dekany
