Re: About a Freemarker template evaluator service

[Woonsan Ko]

On Sat, Feb 25, 2017 at 10:55 PM, Barrie Selack  wrote:
> +! for incubator-freemarker-online-tester

+1. Me too.

Regards,

Woonsan

>
>
> On Sat, Feb 25, 2017 at 5:09 AM, Daniel Dekany  wrote:
>
>> Friday, February 24, 2017, 10:42:46 PM, Barrie Selack wrote:
>>
>> > I'd probably add something (like tester) as just -online doesn't seem to
>> > say what it is.
>>
>> So then how about incubator-freemarker-online-tester? (I'm not afraid
>> of long names... :) )
>>
>> > On Fri, Feb 24, 2017 at 9:07 AM, Daniel Dekany 
>> wrote:
>> >
>> >> I will request a Git repo for the evaluator service. Then I will ask
>> >> Kenshoo to submit an ICLA, and make a pull request on that repository.
>> >>
>> >> What should be the name of the repository? If nobody says otherwise,
>> >> it will be incubating-freemarker-online. (See our currently existing
>> >> repos here: http://freemarker.org/sourcecode.html)
>> >>
>> >>
>> >> Wednesday, February 8, 2017, 3:32:49 PM, Jacques Le Roux wrote:
>> >>
>> >> > Done, good news :)
>> >> >
>> >> > Jacques
>> >> >
>> >> >
>> >> > Le 08/02/2017 à 15:03, Daniel Dekany a écrit :
>> >> >> They say the are will to donate the freemarker-online source code to
>> >> >> ASF. Does someone want to help out with the paper work, like sending
>> >> >> them the file to fill and sign and post, etc.?
>> >> >>
>> >> >> I have also posted to INFRA-13246 about this, but couldn't change the
>> >> >> status to "wariting for infra". Jacques, do you have the right to do
>> >> >> that?
>> >> >>
>> >> >>
>> >> >> Saturday, January 21, 2017, 6:48:15 PM, Jacques Le Roux wrote:
>> >> >>
>> >> >>> Le 21/01/2017 à 17:58, Daniel Dekany a écrit :
>> >>  Saturday, January 21, 2017, 5:17:33 PM, Jacques Le Roux wrote:
>> >> 
>> >> > Le 21/01/2017 à 16:11, Daniel Dekany a écrit :
>> >> >> Nope (as far as I know)... I was hoping that INFRA-13246 will
>> have
>> >> >> some kind of positive feedback first, but it seems it has to be
>> the
>> >> >> other way around then.
>> >> >>
>> >> >> Anyway, have you seen and reactions on our proposal? In case you
>> >> have
>> >> >> met someone face to face or something...
>> >> > I must say I'm reluctant to push the request more w/o nothing in
>> >> > hand, or at least nothing more to say (like we contacted them, we
>> >> begin to work on
>> >> > it, etc., ie some action engaged)
>> >>  OK, I will ask Kenshoo (the owner of freemarker-online) now...
>> >> >>> Thanks I'm sure this will help
>> >> >>>
>> >> >>> Jacques
>> >> >>>
>> >> > Jacques
>> >> >
>> >> >> Saturday, January 21, 2017, 3:00:47 PM, Jacques Le Roux wrote:
>> >> >>
>> >> >>> Any news about this? Somebody contacted them?
>> >> >>>
>> >> >>> It would help to push INFRA-13246
>> >> >>>
>> >> >>> Thanks
>> >> >>>
>> >> >>> Jacques
>> >> >>>
>> >> >>>
>> >> >>> Le 03/01/2017 à 13:27, Daniel Dekany a écrit :
>> >>  Probably there will be a higher chance for positive answer if
>> we
>> >> can
>> >>  offer running the service too. Because I guess that's a burden
>> for
>> >>  them, while owning a piece of software on GitHub is not, that's
>> >> just
>> >>  good PR.
>> >> 
>> >> 
>> >>  Tuesday, January 3, 2017, 12:53:12 PM, Jacques Le Roux wrote:
>> >> 
>> >> > Le 03/01/2017 à 09:32, Jacopo Cappellato a écrit :
>> >> >> Hi all,
>> >> >>
>> >> >> a couple of days ago Daniel brought to my attention the
>> >> site/service:
>> >> >>
>> >> >> http://freemarker-online.kenshoo.com/
>> >> >>
>> >> >> They provide a nice online tool to evaluate any Freemarker
>> >> template by
>> >> >> providing the template code and its context.
>> >> >>
>> >> >> Wouldn't be nice is we could offer that or a similar service
>> to
>> >> the users
>> >> >> and potential adopters of Freemarker? I think it would be a
>> >> very useful
>> >> >> tool and also a good mechanism to attract new consumers.
>> >> >>
>> >> >> If there is an interest in this community then we could move
>> in
>> >> two
>> >> >> directions:
>> >> >>
>> >> >> 1) get in touch with the maintainers of freemarker-online and
>> >> see if they
>> >> >> are interested to contribute their work [*] or join our
>> >> community and help
>> >> >> to build a similar one here; if they are not interested then
>> we
>> >> could
>> >> >> discuss if it would make sense to build our own here
>> >> >>
>> >> >> 2) get in touch with the Infra team and explore the
>> possibility
>> >> to set up a
>> >> >> virtual machine to dedicated to our project that we could use
>> >> to deploy a
>> >> >> similar service, from our official website
>> >> >>
>> >> >> I can volunteer 

Re: About a Freemarker template evaluator service

[Barrie Selack]

+! for incubator-freemarker-online-tester


On Sat, Feb 25, 2017 at 5:09 AM, Daniel Dekany  wrote:

> Friday, February 24, 2017, 10:42:46 PM, Barrie Selack wrote:
>
> > I'd probably add something (like tester) as just -online doesn't seem to
> > say what it is.
>
> So then how about incubator-freemarker-online-tester? (I'm not afraid
> of long names... :) )
>
> > On Fri, Feb 24, 2017 at 9:07 AM, Daniel Dekany 
> wrote:
> >
> >> I will request a Git repo for the evaluator service. Then I will ask
> >> Kenshoo to submit an ICLA, and make a pull request on that repository.
> >>
> >> What should be the name of the repository? If nobody says otherwise,
> >> it will be incubating-freemarker-online. (See our currently existing
> >> repos here: http://freemarker.org/sourcecode.html)
> >>
> >>
> >> Wednesday, February 8, 2017, 3:32:49 PM, Jacques Le Roux wrote:
> >>
> >> > Done, good news :)
> >> >
> >> > Jacques
> >> >
> >> >
> >> > Le 08/02/2017 à 15:03, Daniel Dekany a écrit :
> >> >> They say the are will to donate the freemarker-online source code to
> >> >> ASF. Does someone want to help out with the paper work, like sending
> >> >> them the file to fill and sign and post, etc.?
> >> >>
> >> >> I have also posted to INFRA-13246 about this, but couldn't change the
> >> >> status to "wariting for infra". Jacques, do you have the right to do
> >> >> that?
> >> >>
> >> >>
> >> >> Saturday, January 21, 2017, 6:48:15 PM, Jacques Le Roux wrote:
> >> >>
> >> >>> Le 21/01/2017 à 17:58, Daniel Dekany a écrit :
> >>  Saturday, January 21, 2017, 5:17:33 PM, Jacques Le Roux wrote:
> >> 
> >> > Le 21/01/2017 à 16:11, Daniel Dekany a écrit :
> >> >> Nope (as far as I know)... I was hoping that INFRA-13246 will
> have
> >> >> some kind of positive feedback first, but it seems it has to be
> the
> >> >> other way around then.
> >> >>
> >> >> Anyway, have you seen and reactions on our proposal? In case you
> >> have
> >> >> met someone face to face or something...
> >> > I must say I'm reluctant to push the request more w/o nothing in
> >> > hand, or at least nothing more to say (like we contacted them, we
> >> begin to work on
> >> > it, etc., ie some action engaged)
> >>  OK, I will ask Kenshoo (the owner of freemarker-online) now...
> >> >>> Thanks I'm sure this will help
> >> >>>
> >> >>> Jacques
> >> >>>
> >> > Jacques
> >> >
> >> >> Saturday, January 21, 2017, 3:00:47 PM, Jacques Le Roux wrote:
> >> >>
> >> >>> Any news about this? Somebody contacted them?
> >> >>>
> >> >>> It would help to push INFRA-13246
> >> >>>
> >> >>> Thanks
> >> >>>
> >> >>> Jacques
> >> >>>
> >> >>>
> >> >>> Le 03/01/2017 à 13:27, Daniel Dekany a écrit :
> >>  Probably there will be a higher chance for positive answer if
> we
> >> can
> >>  offer running the service too. Because I guess that's a burden
> for
> >>  them, while owning a piece of software on GitHub is not, that's
> >> just
> >>  good PR.
> >> 
> >> 
> >>  Tuesday, January 3, 2017, 12:53:12 PM, Jacques Le Roux wrote:
> >> 
> >> > Le 03/01/2017 à 09:32, Jacopo Cappellato a écrit :
> >> >> Hi all,
> >> >>
> >> >> a couple of days ago Daniel brought to my attention the
> >> site/service:
> >> >>
> >> >> http://freemarker-online.kenshoo.com/
> >> >>
> >> >> They provide a nice online tool to evaluate any Freemarker
> >> template by
> >> >> providing the template code and its context.
> >> >>
> >> >> Wouldn't be nice is we could offer that or a similar service
> to
> >> the users
> >> >> and potential adopters of Freemarker? I think it would be a
> >> very useful
> >> >> tool and also a good mechanism to attract new consumers.
> >> >>
> >> >> If there is an interest in this community then we could move
> in
> >> two
> >> >> directions:
> >> >>
> >> >> 1) get in touch with the maintainers of freemarker-online and
> >> see if they
> >> >> are interested to contribute their work [*] or join our
> >> community and help
> >> >> to build a similar one here; if they are not interested then
> we
> >> could
> >> >> discuss if it would make sense to build our own here
> >> >>
> >> >> 2) get in touch with the Infra team and explore the
> possibility
> >> to set up a
> >> >> virtual machine to dedicated to our project that we could use
> >> to deploy a
> >> >> similar service, from our official website
> >> >>
> >> >> I can volunteer to try to get in touch with them (#1); any
> >> volunteers for
> >> >> #2 (or even #1)?
> >> >>
> >> >> Kind regards,
> >> >>
> >> >> Jacopo
> >> >>
> >> >> [*] which is licensed with the 

Re: About a Freemarker template evaluator service

[Daniel Dekany]

Saturday, February 25, 2017, 5:28:25 PM, Denis Bredelet wrote:

> Hi,
>> Le 25 févr. 2017 à 10:16, Christoph Rüger  a écrit :
>> 
>> +1 for incubator-freemarker-online-tester
>> 
>> Am 25.02.2017 11:10 vorm. schrieb "Daniel Dekany" :
>> 
>> Friday, February 24, 2017, 10:42:46 PM, Barrie Selack wrote:
>> 
>>> I'd probably add something (like tester) as just -online doesn't seem to
>>> say what it is.
>> 
>> So then how about incubator-freemarker-online-tester? (I'm not afraid
>> of long names... :) )
>
> Typescript, Go and Swift all have « playgrounds ».
>
> What I would suggest is:
>
> (incubator-)try-freemarker-online

It has to start with (incubator-)freemarker, so that would be:
incubator-freemarker-try-online

Though it's a bit strange if the name of a product is not a noun.

> — Denis.
>
>>> On Fri, Feb 24, 2017 at 9:07 AM, Daniel Dekany 
>> wrote:
>>> 
 I will request a Git repo for the evaluator service. Then I will ask
 Kenshoo to submit an ICLA, and make a pull request on that repository.
 
 What should be the name of the repository? If nobody says otherwise,
 it will be incubating-freemarker-online. (See our currently existing
 repos here: http://freemarker.org/sourcecode.html)
 
 
 Wednesday, February 8, 2017, 3:32:49 PM, Jacques Le Roux wrote:
 
> Done, good news :)
> 
> Jacques
> 
> 
> Le 08/02/2017 à 15:03, Daniel Dekany a écrit :
>> They say the are will to donate the freemarker-online source code to
>> ASF. Does someone want to help out with the paper work, like sending
>> them the file to fill and sign and post, etc.?
>> 
>> I have also posted to INFRA-13246 about this, but couldn't change the
>> status to "wariting for infra". Jacques, do you have the right to do
>> that?
>> 
>> 
>> Saturday, January 21, 2017, 6:48:15 PM, Jacques Le Roux wrote:
>> 
>>> Le 21/01/2017 à 17:58, Daniel Dekany a écrit :
 Saturday, January 21, 2017, 5:17:33 PM, Jacques Le Roux wrote:
 
> Le 21/01/2017 à 16:11, Daniel Dekany a écrit :
>> Nope (as far as I know)... I was hoping that INFRA-13246 will have
>> some kind of positive feedback first, but it seems it has to be
>> the
>> other way around then.
>> 
>> Anyway, have you seen and reactions on our proposal? In case you
 have
>> met someone face to face or something...
> I must say I'm reluctant to push the request more w/o nothing in
> hand, or at least nothing more to say (like we contacted them, we
 begin to work on
> it, etc., ie some action engaged)
 OK, I will ask Kenshoo (the owner of freemarker-online) now...
>>> Thanks I'm sure this will help
>>> 
>>> Jacques
>>> 
> Jacques
> 
>> Saturday, January 21, 2017, 3:00:47 PM, Jacques Le Roux wrote:
>> 
>>> Any news about this? Somebody contacted them?
>>> 
>>> It would help to push INFRA-13246
>>> 
>>> Thanks
>>> 
>>> Jacques
>>> 
>>> 
>>> Le 03/01/2017 à 13:27, Daniel Dekany a écrit :
 Probably there will be a higher chance for positive answer if we
 can
 offer running the service too. Because I guess that's a burden
>> for
 them, while owning a piece of software on GitHub is not, that's
 just
 good PR.
 
 
 Tuesday, January 3, 2017, 12:53:12 PM, Jacques Le Roux wrote:
 
> Le 03/01/2017 à 09:32, Jacopo Cappellato a écrit :
>> Hi all,
>> 
>> a couple of days ago Daniel brought to my attention the
 site/service:
>> 
>> http://freemarker-online.kenshoo.com/
>> 
>> They provide a nice online tool to evaluate any Freemarker
 template by
>> providing the template code and its context.
>> 
>> Wouldn't be nice is we could offer that or a similar service
>> to
 the users
>> and potential adopters of Freemarker? I think it would be a
 very useful
>> tool and also a good mechanism to attract new consumers.
>> 
>> If there is an interest in this community then we could move
>> in
 two
>> directions:
>> 
>> 1) get in touch with the maintainers of freemarker-online and
 see if they
>> are interested to contribute their work [*] or join our
 community and help
>> to build a similar one here; if they are not interested then
>> we
 could
>> discuss if it would make sense to build our own here
>> 
>> 2) get in touch with the Infra team and explore the
>> possibility
 to set up a
>> virtual 

Re: Gradle for FreeMarker, anyone? (Was: Maven for Freemarker)

[Daniel Dekany]

Saturday, February 25, 2017, 8:02:06 PM, Taher Alkhateeb wrote:

> Hello Folks,
>
> Okay I've been trying to migrate the compile task to gradle, but did not
> expect so many hacks and quirks in this target. I can copy instructions
> blindly but then that wouldn't make much sense since gradle operates very
> differently with its declarative approach. Examples of where it was
> confusing:
>
> - boot classpath checks? Why do they exist

To ensure that you don't link to things (in rt.jar) that don't exist
in the officially supported lowest Java SE version. People often just
hastily use Java version what they have already installed, rather than
hunting down the specific (and usually ancient) Java version needed.
This obviously can't be allowed when building a release (that's why we
check in during "dist").

This has some extra importance as far as we have no "modules", because
within the only "module" we have, different classes are linked against
different Java SE versions, but IDE-s don't support that, so usually
you work with the highest supported version there. Thus only the build
will catch if you accidentally use a too modern API somewhere (it used
to happen in reality).

> - regex replacements of Java source files! What's the story behind that

As the comment says: ""

See also: 
http://stackoverflow.com/questions/37422191/how-to-remove-suppressfbwarnings-annotations-from-released-jar-s

> - why is the rmic compiler used?

To generate the RMI stubs of course, but what do you mean?

> - why do we have many separate ivy:cachepath declarations? do we have
> different artifacts?

Because different classes have different *allowed* dependencies. Like
Configuration can't accidentally depend on the Servlet API, only the
Servlet support classes can, or else FreeMarker will crash in an
environment without servlets despite that you don't try to use its
servlet support (already happened when back then the build script was
sloppy). The build has to ensure that no such human error slips in,
because the IDE won't point it out.

This is though yet again because of the monolithic (one jar) approach.
That's why I sad the we can split FM2 to multiple modules (requires
some Java expertise and understanding FM internals), as far as at the
end we can re-unite it in a single jar. Can Gradle do that? For FM3,
we don't do the last, we actually will have multiple artifacts.

> - Why are we manually copying files?

At various places for various reasons... Which one you don't
understand?

> I think if we can have some interactive session or something to get my head
> around the logic of this build then this would help me in translating it.

There's no way around reading and thus understanding build.xml, as you
intend to rewrite the build process. I mean, everything is written
down there. If you don't get the reason of something, ask, as you did.

> My conclusion so far is that either the product is inherently complex, or
> the build logic is painfully manual.

It's low level library that has to work in various environments, has
optional dependencies, and dependencies on different versions of the
same library. (Less so than even in few years ago, but it's still like
that.)

What makes the build more trickier than it could be is that FM2 is
monolithic. We can't change it in FM2, as far as the final artifact is
concerned. (I think it was the right compromise back then, but now
that we have dependency management, it's not anymore.) But really it's
not a big deal (with Ant). You have multiple classpaths, and multiple
subsets of classes paired with them. That's it.

> Getting the big picture of what is happening is lost in the midst of
> these unending build instructions.
>
> I also am under the impression that the code base should be a multi-project
> architecture given this constant shoving of files around.

That's what were talking about in the past, right? It should be
modular, in FM3 it truly will be, in FM2 it can be *if* we can then
unite it into a signle jar that's equivalent with what we have now. If
that's not feasible with Gradle (which would be strange), then only
FM3 will switch to Gradle.

> Am I correct in my conclusions so far?
>
> On Tue, Feb 14, 2017 at 11:00 PM, Daniel Dekany  wrote:
>
>> Tuesday, February 14, 2017, 7:53:36 PM, Mauricio Nuñez wrote:
>>
>> > Hi,
>> >
>> > I have a question about this. With FM2, the ant script allows differents
>> > combinations. I think this is not needed for FM3. Or we need to be aware
>> > about specifics combinations of dependencies? This is related to drop
>> > support to older dependencies in FM3.
>>
>> We certainly will need to be able to support multiple versions of the
>> same library in FM3 too, though such cases will be much fewer at the
>> beginning. However, it's possible that in FM3 we solve that with
>> modularization (where each module is a separate jar and a separate
>> Maven artifact, and so can be built separately). It was already
>> decided that 

Re: Gradle for FreeMarker, anyone? (Was: Maven for Freemarker)

[Taher Alkhateeb]

Hello Folks,

Okay I've been trying to migrate the compile task to gradle, but did not
expect so many hacks and quirks in this target. I can copy instructions
blindly but then that wouldn't make much sense since gradle operates very
differently with its declarative approach. Examples of where it was
confusing:

- boot classpath checks? Why do they exist
- regex replacements of Java source files! What's the story behind that
- why is the rmic compiler used?
- why do we have many separate ivy:cachepath declarations? do we have
different artifacts?
- Why are we manually copying files?

I think if we can have some interactive session or something to get my head
around the logic of this build then this would help me in translating it.
My conclusion so far is that either the product is inherently complex, or
the build logic is painfully manual. Getting the big picture of what is
happening is lost in the midst of these unending build instructions.

I also am under the impression that the code base should be a multi-project
architecture given this constant shoving of files around. Am I correct in
my conclusions so far?

On Tue, Feb 14, 2017 at 11:00 PM, Daniel Dekany  wrote:

> Tuesday, February 14, 2017, 7:53:36 PM, Mauricio Nuñez wrote:
>
> > Hi,
> >
> > I have a question about this. With FM2, the ant script allows differents
> > combinations. I think this is not needed for FM3. Or we need to be aware
> > about specifics combinations of dependencies? This is related to drop
> > support to older dependencies in FM3.
>
> We certainly will need to be able to support multiple versions of the
> same library in FM3 too, though such cases will be much fewer at the
> beginning. However, it's possible that in FM3 we solve that with
> modularization (where each module is a separate jar and a separate
> Maven artifact, and so can be built separately). It was already
> decided that we will modularize FM3 to freemarker-core,
> freemarker-sevlet, etc. So that's modularization by functionality.
> Perhaps we should modularize further by dependency version. For
> example, we could have freemarker-core-java8, which adds java.time
> support to freemarker-core. So then, freemarker-core can remain purely
> Java 7 (the minimal required version of FM3), and
> freemarker-core-java-8 contains all that depends on Java 8, and
> freemarker-core finds freemarker-core-java-8 via the SPI mechanism of
> the Java platform (if that works reliably in all environments...).
> But, while that's the cleanest solution as far as the build goes, it's
> not necessary the most convenient solution for the user. He now has to
> remember adding a dependency on freemarker-core-java-8 manually (if he
> wants time API support). Things can get worse if this happens with
> some other modules as well, like we have freemarker-serlet, and later
> we realize that we will need a freemarker-servlet-5 as well. We can
> hope that such things won't happen in reality, but the history of FM2
> shows otherwise. (And the absolute horror is if you have to support
> permutations of the versions of multiple dependencies for the same
> functional module... but let's assume we won't be so unlucky.) Compare
> this to FM2, where the user didn't have to care... you drop in
> freemarker.jar, and it discovers its environment automatically.
>
> I wonder if we could modularize FM2 on the source code level too, but
> then smash all the output together into a single jar (and that's the
> published artifact), while in FM3 they would remain separately
> published artifacts. Thus the FM2 and FM3 would be more similar.
>
> > Regards,
> >
> > Mauricio
> >
> >
> >
> > 2017-02-14 15:39 GMT-03:00 Taher Alkhateeb :
> >
> >> Yeah that would be my bad :) We've been doing heart surgery in the OFBiz
> >> project that got me delayed a bit.
> >>
> >> Anyway, to share what I've worked on so far, I realized most of the
> >> complexity in the script is in the "compile" target. There is _lots_ of
> >> shuffling files around and a good amount of ivy:cachepath directives. I
> did
> >> not expect the logic to be so customized.
> >>
> >> I would like to add a build.gradle file that for now only handles this
> >> target, I will try to deliver something soon but this work should
> really go
> >> in baby steps ... it was overwhelming to try to do it all in one shot.
> >> Perhaps I can put a skeleton and we can work together to improve it.
> >>
> >> Anyway, sit tight, I'll work on something in the next few days.
> >>
> >> On Tue, Feb 14, 2017 at 5:23 PM, Daniel Dekany 
> >> wrote:
> >>
> >> > Any update regarding the Gadle-isation?
> >> >
> >> >
> >> > Monday, January 2, 2017, 9:36:03 AM, Taher Alkhateeb wrote:
> >> >
> >> > > Hi Daniel,
> >> > >
> >> > > Okay things are much more clear thank you!
> >> > >
> >> > > With respect to the repository, I guess there are two uses of the
> word
> >> > > repository. On one hand it is what you meant (a 

Re: About a Freemarker template evaluator service

[Denis Bredelet]

Hi,
> Le 25 févr. 2017 à 10:16, Christoph Rüger  a écrit :
> 
> +1 for incubator-freemarker-online-tester
> 
> Am 25.02.2017 11:10 vorm. schrieb "Daniel Dekany" :
> 
> Friday, February 24, 2017, 10:42:46 PM, Barrie Selack wrote:
> 
>> I'd probably add something (like tester) as just -online doesn't seem to
>> say what it is.
> 
> So then how about incubator-freemarker-online-tester? (I'm not afraid
> of long names... :) )

Typescript, Go and Swift all have « playgrounds ».

What I would suggest is:

(incubator-)try-freemarker-online

— Denis.

>> On Fri, Feb 24, 2017 at 9:07 AM, Daniel Dekany 
> wrote:
>> 
>>> I will request a Git repo for the evaluator service. Then I will ask
>>> Kenshoo to submit an ICLA, and make a pull request on that repository.
>>> 
>>> What should be the name of the repository? If nobody says otherwise,
>>> it will be incubating-freemarker-online. (See our currently existing
>>> repos here: http://freemarker.org/sourcecode.html)
>>> 
>>> 
>>> Wednesday, February 8, 2017, 3:32:49 PM, Jacques Le Roux wrote:
>>> 
 Done, good news :)
 
 Jacques
 
 
 Le 08/02/2017 à 15:03, Daniel Dekany a écrit :
> They say the are will to donate the freemarker-online source code to
> ASF. Does someone want to help out with the paper work, like sending
> them the file to fill and sign and post, etc.?
> 
> I have also posted to INFRA-13246 about this, but couldn't change the
> status to "wariting for infra". Jacques, do you have the right to do
> that?
> 
> 
> Saturday, January 21, 2017, 6:48:15 PM, Jacques Le Roux wrote:
> 
>> Le 21/01/2017 à 17:58, Daniel Dekany a écrit :
>>> Saturday, January 21, 2017, 5:17:33 PM, Jacques Le Roux wrote:
>>> 
 Le 21/01/2017 à 16:11, Daniel Dekany a écrit :
> Nope (as far as I know)... I was hoping that INFRA-13246 will have
> some kind of positive feedback first, but it seems it has to be
> the
> other way around then.
> 
> Anyway, have you seen and reactions on our proposal? In case you
>>> have
> met someone face to face or something...
 I must say I'm reluctant to push the request more w/o nothing in
 hand, or at least nothing more to say (like we contacted them, we
>>> begin to work on
 it, etc., ie some action engaged)
>>> OK, I will ask Kenshoo (the owner of freemarker-online) now...
>> Thanks I'm sure this will help
>> 
>> Jacques
>> 
 Jacques
 
> Saturday, January 21, 2017, 3:00:47 PM, Jacques Le Roux wrote:
> 
>> Any news about this? Somebody contacted them?
>> 
>> It would help to push INFRA-13246
>> 
>> Thanks
>> 
>> Jacques
>> 
>> 
>> Le 03/01/2017 à 13:27, Daniel Dekany a écrit :
>>> Probably there will be a higher chance for positive answer if we
>>> can
>>> offer running the service too. Because I guess that's a burden
> for
>>> them, while owning a piece of software on GitHub is not, that's
>>> just
>>> good PR.
>>> 
>>> 
>>> Tuesday, January 3, 2017, 12:53:12 PM, Jacques Le Roux wrote:
>>> 
 Le 03/01/2017 à 09:32, Jacopo Cappellato a écrit :
> Hi all,
> 
> a couple of days ago Daniel brought to my attention the
>>> site/service:
> 
> http://freemarker-online.kenshoo.com/
> 
> They provide a nice online tool to evaluate any Freemarker
>>> template by
> providing the template code and its context.
> 
> Wouldn't be nice is we could offer that or a similar service
> to
>>> the users
> and potential adopters of Freemarker? I think it would be a
>>> very useful
> tool and also a good mechanism to attract new consumers.
> 
> If there is an interest in this community then we could move
> in
>>> two
> directions:
> 
> 1) get in touch with the maintainers of freemarker-online and
>>> see if they
> are interested to contribute their work [*] or join our
>>> community and help
> to build a similar one here; if they are not interested then
> we
>>> could
> discuss if it would make sense to build our own here
> 
> 2) get in touch with the Infra team and explore the
> possibility
>>> to set up a
> virtual machine to dedicated to our project that we could use
>>> to deploy a
> similar service, from our official website
> 
> I can volunteer to try to get in touch with them (#1); any
>>> volunteers for
> #2 (or even #1)?
> 
> Kind regards,
> 
> Jacopo
> 
> 

Re: About a Freemarker template evaluator service

[Christoph Rüger]

+1 for incubator-freemarker-online-tester

Am 25.02.2017 11:10 vorm. schrieb "Daniel Dekany" :

Friday, February 24, 2017, 10:42:46 PM, Barrie Selack wrote:

> I'd probably add something (like tester) as just -online doesn't seem to
> say what it is.

So then how about incubator-freemarker-online-tester? (I'm not afraid
of long names... :) )

> On Fri, Feb 24, 2017 at 9:07 AM, Daniel Dekany 
wrote:
>
>> I will request a Git repo for the evaluator service. Then I will ask
>> Kenshoo to submit an ICLA, and make a pull request on that repository.
>>
>> What should be the name of the repository? If nobody says otherwise,
>> it will be incubating-freemarker-online. (See our currently existing
>> repos here: http://freemarker.org/sourcecode.html)
>>
>>
>> Wednesday, February 8, 2017, 3:32:49 PM, Jacques Le Roux wrote:
>>
>> > Done, good news :)
>> >
>> > Jacques
>> >
>> >
>> > Le 08/02/2017 à 15:03, Daniel Dekany a écrit :
>> >> They say the are will to donate the freemarker-online source code to
>> >> ASF. Does someone want to help out with the paper work, like sending
>> >> them the file to fill and sign and post, etc.?
>> >>
>> >> I have also posted to INFRA-13246 about this, but couldn't change the
>> >> status to "wariting for infra". Jacques, do you have the right to do
>> >> that?
>> >>
>> >>
>> >> Saturday, January 21, 2017, 6:48:15 PM, Jacques Le Roux wrote:
>> >>
>> >>> Le 21/01/2017 à 17:58, Daniel Dekany a écrit :
>>  Saturday, January 21, 2017, 5:17:33 PM, Jacques Le Roux wrote:
>> 
>> > Le 21/01/2017 à 16:11, Daniel Dekany a écrit :
>> >> Nope (as far as I know)... I was hoping that INFRA-13246 will have
>> >> some kind of positive feedback first, but it seems it has to be
the
>> >> other way around then.
>> >>
>> >> Anyway, have you seen and reactions on our proposal? In case you
>> have
>> >> met someone face to face or something...
>> > I must say I'm reluctant to push the request more w/o nothing in
>> > hand, or at least nothing more to say (like we contacted them, we
>> begin to work on
>> > it, etc., ie some action engaged)
>>  OK, I will ask Kenshoo (the owner of freemarker-online) now...
>> >>> Thanks I'm sure this will help
>> >>>
>> >>> Jacques
>> >>>
>> > Jacques
>> >
>> >> Saturday, January 21, 2017, 3:00:47 PM, Jacques Le Roux wrote:
>> >>
>> >>> Any news about this? Somebody contacted them?
>> >>>
>> >>> It would help to push INFRA-13246
>> >>>
>> >>> Thanks
>> >>>
>> >>> Jacques
>> >>>
>> >>>
>> >>> Le 03/01/2017 à 13:27, Daniel Dekany a écrit :
>>  Probably there will be a higher chance for positive answer if we
>> can
>>  offer running the service too. Because I guess that's a burden
for
>>  them, while owning a piece of software on GitHub is not, that's
>> just
>>  good PR.
>> 
>> 
>>  Tuesday, January 3, 2017, 12:53:12 PM, Jacques Le Roux wrote:
>> 
>> > Le 03/01/2017 à 09:32, Jacopo Cappellato a écrit :
>> >> Hi all,
>> >>
>> >> a couple of days ago Daniel brought to my attention the
>> site/service:
>> >>
>> >> http://freemarker-online.kenshoo.com/
>> >>
>> >> They provide a nice online tool to evaluate any Freemarker
>> template by
>> >> providing the template code and its context.
>> >>
>> >> Wouldn't be nice is we could offer that or a similar service
to
>> the users
>> >> and potential adopters of Freemarker? I think it would be a
>> very useful
>> >> tool and also a good mechanism to attract new consumers.
>> >>
>> >> If there is an interest in this community then we could move
in
>> two
>> >> directions:
>> >>
>> >> 1) get in touch with the maintainers of freemarker-online and
>> see if they
>> >> are interested to contribute their work [*] or join our
>> community and help
>> >> to build a similar one here; if they are not interested then
we
>> could
>> >> discuss if it would make sense to build our own here
>> >>
>> >> 2) get in touch with the Infra team and explore the
possibility
>> to set up a
>> >> virtual machine to dedicated to our project that we could use
>> to deploy a
>> >> similar service, from our official website
>> >>
>> >> I can volunteer to try to get in touch with them (#1); any
>> volunteers for
>> >> #2 (or even #1)?
>> >>
>> >> Kind regards,
>> >>
>> >> Jacopo
>> >>
>> >> [*] which is licensed with the AL2.0 and available here:
>> >> https://github.com/kenshoo/freemarker-online
>> >>
>> > Hi Jacopo,
>> >
>> > I can take care of 2, I'm used to these kind of things for
OFBiz
>> > I guess 1 is a prerequisite and I'm not well 

Re: About a Freemarker template evaluator service

[Daniel Dekany]

Friday, February 24, 2017, 10:42:46 PM, Barrie Selack wrote:

> I'd probably add something (like tester) as just -online doesn't seem to
> say what it is.

So then how about incubator-freemarker-online-tester? (I'm not afraid
of long names... :) )

> On Fri, Feb 24, 2017 at 9:07 AM, Daniel Dekany  wrote:
>
>> I will request a Git repo for the evaluator service. Then I will ask
>> Kenshoo to submit an ICLA, and make a pull request on that repository.
>>
>> What should be the name of the repository? If nobody says otherwise,
>> it will be incubating-freemarker-online. (See our currently existing
>> repos here: http://freemarker.org/sourcecode.html)
>>
>>
>> Wednesday, February 8, 2017, 3:32:49 PM, Jacques Le Roux wrote:
>>
>> > Done, good news :)
>> >
>> > Jacques
>> >
>> >
>> > Le 08/02/2017 à 15:03, Daniel Dekany a écrit :
>> >> They say the are will to donate the freemarker-online source code to
>> >> ASF. Does someone want to help out with the paper work, like sending
>> >> them the file to fill and sign and post, etc.?
>> >>
>> >> I have also posted to INFRA-13246 about this, but couldn't change the
>> >> status to "wariting for infra". Jacques, do you have the right to do
>> >> that?
>> >>
>> >>
>> >> Saturday, January 21, 2017, 6:48:15 PM, Jacques Le Roux wrote:
>> >>
>> >>> Le 21/01/2017 à 17:58, Daniel Dekany a écrit :
>>  Saturday, January 21, 2017, 5:17:33 PM, Jacques Le Roux wrote:
>> 
>> > Le 21/01/2017 à 16:11, Daniel Dekany a écrit :
>> >> Nope (as far as I know)... I was hoping that INFRA-13246 will have
>> >> some kind of positive feedback first, but it seems it has to be the
>> >> other way around then.
>> >>
>> >> Anyway, have you seen and reactions on our proposal? In case you
>> have
>> >> met someone face to face or something...
>> > I must say I'm reluctant to push the request more w/o nothing in
>> > hand, or at least nothing more to say (like we contacted them, we
>> begin to work on
>> > it, etc., ie some action engaged)
>>  OK, I will ask Kenshoo (the owner of freemarker-online) now...
>> >>> Thanks I'm sure this will help
>> >>>
>> >>> Jacques
>> >>>
>> > Jacques
>> >
>> >> Saturday, January 21, 2017, 3:00:47 PM, Jacques Le Roux wrote:
>> >>
>> >>> Any news about this? Somebody contacted them?
>> >>>
>> >>> It would help to push INFRA-13246
>> >>>
>> >>> Thanks
>> >>>
>> >>> Jacques
>> >>>
>> >>>
>> >>> Le 03/01/2017 à 13:27, Daniel Dekany a écrit :
>>  Probably there will be a higher chance for positive answer if we
>> can
>>  offer running the service too. Because I guess that's a burden for
>>  them, while owning a piece of software on GitHub is not, that's
>> just
>>  good PR.
>> 
>> 
>>  Tuesday, January 3, 2017, 12:53:12 PM, Jacques Le Roux wrote:
>> 
>> > Le 03/01/2017 à 09:32, Jacopo Cappellato a écrit :
>> >> Hi all,
>> >>
>> >> a couple of days ago Daniel brought to my attention the
>> site/service:
>> >>
>> >> http://freemarker-online.kenshoo.com/
>> >>
>> >> They provide a nice online tool to evaluate any Freemarker
>> template by
>> >> providing the template code and its context.
>> >>
>> >> Wouldn't be nice is we could offer that or a similar service to
>> the users
>> >> and potential adopters of Freemarker? I think it would be a
>> very useful
>> >> tool and also a good mechanism to attract new consumers.
>> >>
>> >> If there is an interest in this community then we could move in
>> two
>> >> directions:
>> >>
>> >> 1) get in touch with the maintainers of freemarker-online and
>> see if they
>> >> are interested to contribute their work [*] or join our
>> community and help
>> >> to build a similar one here; if they are not interested then we
>> could
>> >> discuss if it would make sense to build our own here
>> >>
>> >> 2) get in touch with the Infra team and explore the possibility
>> to set up a
>> >> virtual machine to dedicated to our project that we could use
>> to deploy a
>> >> similar service, from our official website
>> >>
>> >> I can volunteer to try to get in touch with them (#1); any
>> volunteers for
>> >> #2 (or even #1)?
>> >>
>> >> Kind regards,
>> >>
>> >> Jacopo
>> >>
>> >> [*] which is licensed with the AL2.0 and available here:
>> >> https://github.com/kenshoo/freemarker-online
>> >>
>> > Hi Jacopo,
>> >
>> > I can take care of 2, I'm used to these kind of things for OFBiz
>> > I guess 1 is a prerequisite and I'm not well placed for this
>> task.
>> >
>> > Jacques
>> >
>> >
>> >>>
>> >
>> >
>>
>> --
>> 

Re: Alternatives to the ObjectWrapper/TemplateModel approach (Was: [FM3] Remove BeansWrapper and some of its settings)

[Daniel Dekany]

Saturday, February 25, 2017, 7:59:55 AM, David E Jones wrote:

> These all sound like good changes, and clarify what is really going on.

(Basically, I'm decreasing code size and complexity before the more
interesting changes are started.)

> Removing object wrapping IMO is more important than removing the
> *Template*Model* interfaces.

(The two come hand in hand really. If we had no TemplateModel-s, we
had no ObjectWrappers either.)

> These interfaces don't have the same runtime and
> GC overhead as object wrapping and they can be nice for type checking to make
> sure the operation in the template can actually be done on the object. Still,
> with those interfaces it would be nice to use more standard ones where they
> exist (Java collection interfaces for example).
>
> On the object wrapping topic there might be some useful things to learn from
> Groovy, though as FTL doesn't compile to a class not all of the same applies.
> The biggest performance overhead in Groovy is all the type conversions that it
> does to be a type optional scripting language. I've done a lot of work on
> optimizing Groovy code since I made a decision years ago to write a big
> framework mostly in Groovy.
>
>   
>
> I don't know that this is directly applicable to the discussion, but here is
> an article I wrote last year on some stuff I learned about Groovy
> optimization, and it may be that we can avoid some of these issues:
>
>   
>
> https://dzone.com/articles/how-to-make-groovy-as-fast-as-java  
>
>   
>
> Even Groovy has a sort of object wrapper, ie its meta class. It's one thing
> that would be great to disable when you're not using the Groovy features that
> rely on it... maybe someday I'll even look into this in Groovy itself or open
> the discussion in that community (for now I'm up to my neck in work :) ).

Luckily, I don't think this kind of performance is priority for a
template engine like FreeMarker, or at least that it's a high enough
priority to trump easy extendibility and such. That's because it's not
a programming language. Its a kind of domain specific language
basically. For something that generates output, hopefully you don't
have lines that are executed for millions and millions of times,
unless you also generate heck of a lot of output, which has to be
stored or sent, which will then (hopefully...) dominate your
performance anyway.

Also, for us, a key difficulty is that in general we can't have
assumptions about the data-model content. It's outside the template. I
just don't know that in ${user.name}, what `user` will be. Sometimes
though, the data-model is a bean, so if that's declared inside the
template, then you have better chances. But... what if User has no
fullName property, but some User subclass has, and you write
`${user.fullName!'unknown'}`? Should now I also require the user to do
an explicit type cast? Anyway, one thing is sure, templates must be
able to operate in non-static mode. Adding an alternative static mode
is way out of reach (given the resources we can burn). And without
that... our performance options are rather limited. Well, we can pull
some tricks, like with indy, even if you don't know what the type of
`user` will be, you can during execution learn that it's in practice
always an User, and then you can link User.getName() as if it was a
"static" invocation (with a guard condition so if it's not an User
after all, you can take the slow route).

> A good step in the right direction might be to start with the use of standard
> Java interfaces. For example when you do a #list it could be required that the
> object you are iterating over implements either the List or Iterator
> interfaces (perhaps with optimization to detect RandomAccess lists like
> ArrayList to avoid creating an Iterator).
> This doesn't get us all the way down
> the road, but is a start.

What I consider instead of ObjectWrapper+TemplateModel-s is the
following. We don't wrap values into anything. Instead we will have an
interface called MOPImplementation (where MOP stands for Meta Object
Protocol), which declares methods for each *operations* that FTL is
interested in, such as `int getSize(env, v)`, `boolean isEmpty(v,
env)`, `Iterator getListItemIterator(v, env)`, `Object
getParent(v, env)` (for XML DOM-s and such), etc. So if you, for
example, need to #list a value, you get the MOPImplementation instance
based on the class of the value (it's the class of the "raw" value,
not a TemplateMode), and then call getListItemIterator on it, which
either gives you the Iterator or throws an
TemplateOperationNotSupportedException. A key idea behind this is that
you do not have a MOPImplementation per value instance. Like if you
have two List-s, they all will use the same shared MOPImplementation
instance (something like
o.a.f.core.mop.impl.ListMOPImplementation.INSTANCE) to access those
lists. The MOPImplementation isn't bound to a value, it's only bound
to the class of the value (i.e. you have different