You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@freemarker.apache.org by Daniel Dekany <dd...@freemail.hu> on 2016/06/12 20:32:17 UTC
Anybody wants anything before 2.3.25? Also, current release notes.
I plan to start a voting here on 2016-06-14, for releasing 2.3.25. So
if anyone wants to add anything before that, inform me.
This is what we have so far:
- Version history: http://freemarker.org/builds/2.3.25-nightly/documentation/_html/versions_2_3_25.html
- Last build: http://freemarker.org/builds/2.3.25-nightly/freemarker.jar
--
Thanks,
Daniel Dekany
Re: Anybody wants anything before 2.3.25? Also, current release notes.
Posted by Daniel Dekany <dd...@freemail.hu>.
I think this solves the multiple lists problem (this works for a long
time):
<#list mylist1 + list2 as item>
Monday, June 13, 2016, 10:26:17 AM, Albert Kam wrote:
> Dear Daniel,
>
> I think you nailed it, it's obviously a filtering problem !
>
> One more issue regarding json comma crossed my head just now.
> Example being this:
> {
> <#list mylist1 as item>
> '${item}': '${item}'<#sep>,</#sep>
> </#list>,
> <#list mylist2 as item>
> '${item}': '${item}'<#sep>,</#sep>
> </#list>
> }
>
> If mylist1 is empty, then it will result in
> {
> ,
> 'mylist2item1': 'mylist2item1',
> 'mylist2item2': 'mylist2item2'
> }
> And if mylist2 happens to be empty, then it'll result in
> {
> 'mylist2item1': 'mylist2item1',
> 'mylist2item2': 'mylist2item2'
> ,
> }
> If both are empty, then
> {
> ,
> }
>
> So the ugly and not reusable way to deal with this would be:
> {
> <#list mylist1 as item>
> '${item}': '${item}'<#sep>,</#sep>
> </#list><#if mylist1?has_content && mylist2?has_content>,</#if>
> <#list mylist2 as item>
> '${item}': '${item}'<#sep>,</#sep>
> </#list>
> }
>
> The reusable approach is maybe sth like this
> {
> <@optionalNested commaSuffix=true>
> <#list mylist1 as item>
> '${item}': '${item}'<#sep>,</#sep>
> </#list>
> </...@optionalNested>
> <#list mylist2 as item>
> '${item}': '${item}'<#sep>,</#sep>
> </#list>
> }
> where optional nested only adds a comma at the end when it's
> trimmed-<#nested> is not empty.
>
> Are there any other solutions that i might miss ?
>
>
>
> On Mon, Jun 13, 2016 at 1:55 PM, Daniel Dekany <dd...@freemail.hu> wrote:
>> That's a work around for the separator, but this problem is deeper
>> that that. Things like x?index, x?hasNext, x?itemParity, etc. don't
>> work either if you do filtering like that. So I plan to add closure
>> support (if it's technically possible...) and then you can do
>> something like:
>>
>> <#list hobbies?filter(i -> i != 'walk') as hobby>
>>
>> Though you meant to filter lists before passing them to the
>> data-model, so it will also support bad practices... But I know that
>> in real world filtering has good uses too.
>>
>>
>> Monday, June 13, 2016, 3:55:29 AM, Albert Kam wrote:
>>
>>> Hello Daniel,
>>>
>>> Thanks for the great updates !
>>>
>>> I have something in mind concerning the <#sep> directive. Is it
>>> possible to add a startSeparator only when the previous loop produces
>>> content ?
>>> This happens a lot when printing json hash entries. Example :
>>>
>>> <#local hobbies=['read', 'code', 'walk']>
>>> {
>>> <#list hobbies as hobby>
>>> <#if hobby != 'walk>
>>> 'prop${hobby_index}': '${hobby}'<#sep>,<#sep>
>>> </#if>
>>> </#list>
>>> }
>>>
>>> This will result in
>>> {
>>> 'prop0': 'read',
>>> 'prop1': 'walk',
>>> }
>>> Notice the extra comma after 'walk'.
>>>
>>> I have a workaround for this issue with adding the comma at the head
>>> if already had an entry:
>>> <#local hasEntry=false>
>>> <#list hobbies as hobby>
>>> <#if hobby != 'walk>
>>> <#if hasEntry>,</#if>
>>> 'prop${hobby_index}': '${hobby}'
>>> <#local hasEntry=true>
>>> </#if>
>>> </#list>
>>>
>>> This will result in
>>> {
>>> 'prop0': 'read'
>>> ,
>>> 'prop1': 'walk'
>>> }
>>>
>>> The ideal directive to emultate the workaround above would look
>>> something like this:
>>> <#list hobbies as hobby>
>>> <#if hobby != 'walk>
>>> <#head_sep>,<#head_sep>
>>> 'prop${hobby_index}': '${hobby}'
>>> </#if>
>>> </#list>
>>> Where <#head_sep> renderes the comma only if the previous loop had an entry.
>>>
>>> Just a suggestion.
>>>
>>> Thanks !
>>>
>>>
>>> On Mon, Jun 13, 2016 at 3:32 AM, Daniel Dekany <dd...@freemail.hu> wrote:
>>>> I plan to start a voting here on 2016-06-14, for releasing 2.3.25. So
>>>> if anyone wants to add anything before that, inform me.
>>>>
>>>> This is what we have so far:
>>>> - Version history: http://freemarker.org/builds/2.3.25-nightly/documentation/_html/versions_2_3_25.html
>>>> - Last build: http://freemarker.org/builds/2.3.25-nightly/freemarker.jar
>>>>
>>>> --
>>>> Thanks,
>>>> Daniel Dekany
>>>>
>>>
>>>
>>>
>>
>> --
>> Thanks,
>> Daniel Dekany
>>
>
>
>
--
Thanks,
Daniel Dekany
Re: Anybody wants anything before 2.3.25? Also, current release notes.
Posted by Albert Kam <mo...@gmail.com>.
Dear Daniel,
I think you nailed it, it's obviously a filtering problem !
One more issue regarding json comma crossed my head just now.
Example being this:
{
<#list mylist1 as item>
'${item}': '${item}'<#sep>,</#sep>
</#list>,
<#list mylist2 as item>
'${item}': '${item}'<#sep>,</#sep>
</#list>
}
If mylist1 is empty, then it will result in
{
,
'mylist2item1': 'mylist2item1',
'mylist2item2': 'mylist2item2'
}
And if mylist2 happens to be empty, then it'll result in
{
'mylist2item1': 'mylist2item1',
'mylist2item2': 'mylist2item2'
,
}
If both are empty, then
{
,
}
So the ugly and not reusable way to deal with this would be:
{
<#list mylist1 as item>
'${item}': '${item}'<#sep>,</#sep>
</#list><#if mylist1?has_content && mylist2?has_content>,</#if>
<#list mylist2 as item>
'${item}': '${item}'<#sep>,</#sep>
</#list>
}
The reusable approach is maybe sth like this
{
<@optionalNested commaSuffix=true>
<#list mylist1 as item>
'${item}': '${item}'<#sep>,</#sep>
</#list>
</...@optionalNested>
<#list mylist2 as item>
'${item}': '${item}'<#sep>,</#sep>
</#list>
}
where optional nested only adds a comma at the end when it's
trimmed-<#nested> is not empty.
Are there any other solutions that i might miss ?
On Mon, Jun 13, 2016 at 1:55 PM, Daniel Dekany <dd...@freemail.hu> wrote:
> That's a work around for the separator, but this problem is deeper
> that that. Things like x?index, x?hasNext, x?itemParity, etc. don't
> work either if you do filtering like that. So I plan to add closure
> support (if it's technically possible...) and then you can do
> something like:
>
> <#list hobbies?filter(i -> i != 'walk') as hobby>
>
> Though you meant to filter lists before passing them to the
> data-model, so it will also support bad practices... But I know that
> in real world filtering has good uses too.
>
>
> Monday, June 13, 2016, 3:55:29 AM, Albert Kam wrote:
>
>> Hello Daniel,
>>
>> Thanks for the great updates !
>>
>> I have something in mind concerning the <#sep> directive. Is it
>> possible to add a startSeparator only when the previous loop produces
>> content ?
>> This happens a lot when printing json hash entries. Example :
>>
>> <#local hobbies=['read', 'code', 'walk']>
>> {
>> <#list hobbies as hobby>
>> <#if hobby != 'walk>
>> 'prop${hobby_index}': '${hobby}'<#sep>,<#sep>
>> </#if>
>> </#list>
>> }
>>
>> This will result in
>> {
>> 'prop0': 'read',
>> 'prop1': 'walk',
>> }
>> Notice the extra comma after 'walk'.
>>
>> I have a workaround for this issue with adding the comma at the head
>> if already had an entry:
>> <#local hasEntry=false>
>> <#list hobbies as hobby>
>> <#if hobby != 'walk>
>> <#if hasEntry>,</#if>
>> 'prop${hobby_index}': '${hobby}'
>> <#local hasEntry=true>
>> </#if>
>> </#list>
>>
>> This will result in
>> {
>> 'prop0': 'read'
>> ,
>> 'prop1': 'walk'
>> }
>>
>> The ideal directive to emultate the workaround above would look
>> something like this:
>> <#list hobbies as hobby>
>> <#if hobby != 'walk>
>> <#head_sep>,<#head_sep>
>> 'prop${hobby_index}': '${hobby}'
>> </#if>
>> </#list>
>> Where <#head_sep> renderes the comma only if the previous loop had an entry.
>>
>> Just a suggestion.
>>
>> Thanks !
>>
>>
>> On Mon, Jun 13, 2016 at 3:32 AM, Daniel Dekany <dd...@freemail.hu> wrote:
>>> I plan to start a voting here on 2016-06-14, for releasing 2.3.25. So
>>> if anyone wants to add anything before that, inform me.
>>>
>>> This is what we have so far:
>>> - Version history: http://freemarker.org/builds/2.3.25-nightly/documentation/_html/versions_2_3_25.html
>>> - Last build: http://freemarker.org/builds/2.3.25-nightly/freemarker.jar
>>>
>>> --
>>> Thanks,
>>> Daniel Dekany
>>>
>>
>>
>>
>
> --
> Thanks,
> Daniel Dekany
>
--
Do not pursue the past. Do not lose yourself in the future.
The past no longer is. The future has not yet come.
Looking deeply at life as it is in the very here and now,
the practitioner dwells in stability and freedom.
(Thich Nhat Hanh)
Re: Anybody wants anything before 2.3.25? Also, current release notes.
Posted by Daniel Dekany <dd...@freemail.hu>.
That's a work around for the separator, but this problem is deeper
that that. Things like x?index, x?hasNext, x?itemParity, etc. don't
work either if you do filtering like that. So I plan to add closure
support (if it's technically possible...) and then you can do
something like:
<#list hobbies?filter(i -> i != 'walk') as hobby>
Though you meant to filter lists before passing them to the
data-model, so it will also support bad practices... But I know that
in real world filtering has good uses too.
Monday, June 13, 2016, 3:55:29 AM, Albert Kam wrote:
> Hello Daniel,
>
> Thanks for the great updates !
>
> I have something in mind concerning the <#sep> directive. Is it
> possible to add a startSeparator only when the previous loop produces
> content ?
> This happens a lot when printing json hash entries. Example :
>
> <#local hobbies=['read', 'code', 'walk']>
> {
> <#list hobbies as hobby>
> <#if hobby != 'walk>
> 'prop${hobby_index}': '${hobby}'<#sep>,<#sep>
> </#if>
> </#list>
> }
>
> This will result in
> {
> 'prop0': 'read',
> 'prop1': 'walk',
> }
> Notice the extra comma after 'walk'.
>
> I have a workaround for this issue with adding the comma at the head
> if already had an entry:
> <#local hasEntry=false>
> <#list hobbies as hobby>
> <#if hobby != 'walk>
> <#if hasEntry>,</#if>
> 'prop${hobby_index}': '${hobby}'
> <#local hasEntry=true>
> </#if>
> </#list>
>
> This will result in
> {
> 'prop0': 'read'
> ,
> 'prop1': 'walk'
> }
>
> The ideal directive to emultate the workaround above would look
> something like this:
> <#list hobbies as hobby>
> <#if hobby != 'walk>
> <#head_sep>,<#head_sep>
> 'prop${hobby_index}': '${hobby}'
> </#if>
> </#list>
> Where <#head_sep> renderes the comma only if the previous loop had an entry.
>
> Just a suggestion.
>
> Thanks !
>
>
> On Mon, Jun 13, 2016 at 3:32 AM, Daniel Dekany <dd...@freemail.hu> wrote:
>> I plan to start a voting here on 2016-06-14, for releasing 2.3.25. So
>> if anyone wants to add anything before that, inform me.
>>
>> This is what we have so far:
>> - Version history: http://freemarker.org/builds/2.3.25-nightly/documentation/_html/versions_2_3_25.html
>> - Last build: http://freemarker.org/builds/2.3.25-nightly/freemarker.jar
>>
>> --
>> Thanks,
>> Daniel Dekany
>>
>
>
>
--
Thanks,
Daniel Dekany
Re: Graduation issues
Posted by Jacopo Cappellato <ja...@gmail.com>.
I do, if you are ok with it.
Jacopo
On Sun, Jun 19, 2016 at 10:06 AM, Daniel Dekany <dd...@freemail.hu> wrote:
> Who of the mentors plan to stay as PMC member after FM graduates?
>
> --
> Thanks,
> Daniel Dekany
>
>
> Sunday, June 19, 2016, 4:39:54 AM, Ralph Goers wrote:
>
> > If the graduation vote fails the project would be told why. They
> > would continue in the incubator if they choose until whatever issues
> there were are addressed.
> >
> > PPMC members usually continue on as PMC members although mentors
> frequently don’t stay on.
> >
> > Ralph
> >
> >> On Jun 18, 2016, at 7:01 AM, Daniel Dekany <dd...@freemail.hu> wrote:
> >>
> >> Saturday, June 18, 2016, 9:41:19 AM, Jacopo Cappellato wrote:
> >>
> >>> I agree that it is the right time to discuss graduation.
> >>> In my opinion the incubation process for Freemarker has been
> successful and
> >>> for this reason I will vote +1 for the graduation.
> >>> As anticipated when we initially discussed the incubation, one critical
> >>> aspect of the Freemarker project was its small committer's base; under
> this
> >>> aspect the incubation process didn't do any magic and frankly speaking
> I
> >>> was not expecting it to happen.
> >>> However, as mentioned by Daniel and Sergio, the project is mature but
> there
> >>> are plans for the future that will keep the community busy, not just
> >>> maintaining the old code.
> >>> This community has still to find a more effective way to attract new
> >>> committers but this should not be a blocker to become a top level
> project @
> >>> ASF.
> >>
> >> And for the record, I think that requires some substantial
> >> modernization/cleanup, which I have called FreeMarker 3 as it drops
> >> backward compatibility. There are many things where FreeMarker 2 can
> >> be evolved further without breaking backward compatibility, but making
> >> the project more attractive is also timely, and the resources are
> >> scarce, so I think we can't have both.
> >>
> >>> It is however important to verify that we will have, even after
> graduation,
> >>> a PMC group capable of casting at least 3 positive votes on releases.
> >>
> >> Is it customary for PPMC members of the poddling to be also in the PMC
> >> of the graduated project? If so, can any of you express his intent
> >> regarding that?
> >>
> >> What are the risks of failing the graduation vote?
> >>
> >> BTW, something that I can do to help it, to document some
> >> project-specific rules, and a step-by-step release tutorial.
> >>
> >> --
> >> Thanks,
> >> Daniel Dekany
> >>
> >>
> >>> Jacopo
> >>>
> >>> On Tue, Jun 14, 2016 at 1:55 PM, Sergio Fernández <wi...@apache.org>
> wrote:
> >>>
> >>>> Hi Daniel,
> >>>>
> >>>> On Mon, Jun 13, 2016 at 9:18 PM, Daniel Dekany <dd...@freemail.hu>
> >>>> wrote:
> >>>>
> >>>>> I think we can start some discussion about that even now. Or at least
> >>>>> I will tell what do I think about the state of the project.
> >>>>>
> >>>>
> >>>> Great step. Thanks.
> >>>>
> >>>> The main problem is the number of active developers, which is 1, me.
> >>>>>
> >>>>
> >>>> I'm aware...
> >>>>
> >>>>
> https://github.com/apache/incubator-freemarker/graphs/contributors?from=2015-07-01&type=c
> >>>>
> >>>>
> >>>>> What if I'm hit by a truck tomorrow? We can hope that if there's a
> bug
> >>>>> that concerns many, then someone will eventually fix it. After all
> the
> >>>>> owner (ASF) won't be gone, the release infrastructure is there, etc.
> >>>>> But as far as non-bugfix development goes, it's certain that things
> >>>>> would stop. Some may say that that's OK for a project that's
> >>>>> backward-compatibility-locked for 12 years now (the 2.x line is
> >>>>> actually 14 years old).
> >>>>
> >>>>
> >>>> Well, I'd say that's critical, but the community of a project is more
> than
> >>>> the developers who code. And the Freemarker community is much bigger
> than
> >>>> what you could think.
> >>>>
> >>>> For instance if you consider my personal case: I volunteered for
> mentor
> >>>> because I knew the project for so long. I even code some extensions (
> >>>> http://marmotta.apache.org/ldpath/template.html). Definitively I used
> >>>> Freemarker much more in the past than currently, but Web development
> has
> >>>> changed a lot, moving more stuff to the frontend (10 years ago we
> didn't
> >>>> have AngularJS).
> >>>>
> >>>> So I'd say there are many people like me out there, using every day
> >>>> solutions based on Freemarker. People who are not that close to the
> source
> >>>> base, but familiar enough to be able to jump in at any time a provide
> a
> >>>> patch.
> >>>>
> >>>>
> >>>>
> >>>>> But of course that's just slow death if a
> >>>>> project can't counter its old design problems and can't evolve to
> >>>>> tackle new problems anymore. So indeed 2.x should switch to
> >>>>> maintenance eventually (but ATM there are still things that can be
> >>>>> done in 2.x), but only to give place for 3.x. Anyway, how to catch
> >>>>> long standing developers? I don't think that 2.x have a real chance
> >>>>> for that, because of all the legacy code burden piled up. (Some
> Apache
> >>>>> projects have many paid contributors, but I think FM isn't the kind
> of
> >>>>> project that can have that, so it's important that the developers
> want
> >>>>> to fiddle with it for free.) So the 3.x jump will be necessary, and
> >>>>> then, maybe, we can have a developer base growth (template engines
> >>>>> isn't hot topic anymore, so I just mean having a few developers
> >>>>> around). But 3.x is far away (if it will happen at all), and we can't
> >>>>> hang around in the incubator forever.
> >>>>
> >>>>
> >>>> Well, we can consider 2.3.x feature-complete, and 2.3.25-incubating a
> >>>> maintenance release. The world has change a lot in template business
> in
> >>>> these 14 years. But I'm pretty sure FreeMarker has its place there,
> and 3.x
> >>>> could bring some many great ideas that may attract potential new
> >>>> contributors. And that's what I see as future of this project.
> >>>>
> >>>>
> >>>>> So, do you believe there's any chance to graduate with the current
> >>>>> developer base?
> >>>>>
> >>>>
> >>>> Definitively that has been always the major issue with this podling.
> >>>> Honestly I'm not sure. But following with all my argumentation that
> the
> >>>> community is much bigger that what shows the development team, I'd say
> >>>> could be at least discussed with the IPMC.
> >>>>
> >>>> Looking forward to hear every body else's opinions.
> >>>>
> >>>> Cheers,
> >>>>
> >>>> --
> >>>> Sergio Fernández
> >>>> Partner Technology Manager
> >>>> Redlink GmbH
> >>>> m: +43 6602747925
> >>>> e: sergio.fernandez@redlink.co
> >>>> w: http://redlink.co
> >>>>
> >>
> >>
> >
> >
> >
>
>
Re: Graduation issues
Posted by Sergio Fernández <wi...@apache.org>.
Jacopo, now that 2.3.25-incubating is out, I think it open the time to
start the discussion at general@incubator. Go for it whenever you want/can.
Thanks.
On Mon, Jun 20, 2016 at 1:17 PM, Jacopo Cappellato <
jacopo.cappellato@gmail.com> wrote:
> makes sense, thank you Sergio.
>
> Jacopo
>
> On Mon, Jun 20, 2016 at 12:55 PM, Sergio Fernández <wi...@apache.org>
> wrote:
>
> > On Mon, Jun 20, 2016 at 11:31 AM, Jacopo Cappellato <
> > jacopo.cappellato@gmail.com> wrote:
> > >
> > > Should I start the thread today? Should I send you a preview of the
> > message
> > > as soon as it is ready so that you can all comment and improve it?
> > >
> >
> > What about wait until the current vote is over and release published?
> > I think that's a bit better timing...
> >
> >
> > --
> > Sergio Fernández
> > Partner Technology Manager
> > Redlink GmbH
> > m: +43 6602747925
> > e: sergio.fernandez@redlink.co
> > w: http://redlink.co
> >
>
--
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 6602747925
e: sergio.fernandez@redlink.co
w: http://redlink.co
Re: Graduation issues
Posted by Sergio Fernández <wi...@apache.org>.
On Tue, Jun 21, 2016 at 12:14 AM, Daniel Dekany <dd...@freemail.hu> wrote:
> I suppose some work should be done before that anyway. Not much
> hopefully. Things like filling the blanks on
> http://incubator.apache.org/projects/freemarker.html, etc.
>
Yes, we should take care of updating the podling information pages before
the formal graduation process, not blocking discussions any way ;-)
Re: Graduation issues
Posted by Daniel Dekany <dd...@freemail.hu>.
I suppose some work should be done before that anyway. Not much
hopefully. Things like filling the blanks on
http://incubator.apache.org/projects/freemarker.html, etc.
Monday, June 20, 2016, 1:17:06 PM, Jacopo Cappellato wrote:
> makes sense, thank you Sergio.
>
> Jacopo
>
> On Mon, Jun 20, 2016 at 12:55 PM, Sergio Fern�ndez <wi...@apache.org>
> wrote:
>
>> On Mon, Jun 20, 2016 at 11:31 AM, Jacopo Cappellato <
>> jacopo.cappellato@gmail.com> wrote:
>> >
>> > Should I start the thread today? Should I send you a preview of the
>> message
>> > as soon as it is ready so that you can all comment and improve it?
>> >
>>
>> What about wait until the current vote is over and release published?
>> I think that's a bit better timing...
>>
>>
>> --
>> Sergio Fern�ndez
>> Partner Technology Manager
>> Redlink GmbH
>> m: +43 6602747925
>> e: sergio.fernandez@redlink.co
>> w: http://redlink.co
--
Thanks,
Daniel Dekany
Re: Graduation issues
Posted by Jacopo Cappellato <ja...@gmail.com>.
makes sense, thank you Sergio.
Jacopo
On Mon, Jun 20, 2016 at 12:55 PM, Sergio Fernández <wi...@apache.org>
wrote:
> On Mon, Jun 20, 2016 at 11:31 AM, Jacopo Cappellato <
> jacopo.cappellato@gmail.com> wrote:
> >
> > Should I start the thread today? Should I send you a preview of the
> message
> > as soon as it is ready so that you can all comment and improve it?
> >
>
> What about wait until the current vote is over and release published?
> I think that's a bit better timing...
>
>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 6602747925
> e: sergio.fernandez@redlink.co
> w: http://redlink.co
>
Re: Graduation issues
Posted by Sergio Fernández <wi...@apache.org>.
On Mon, Jun 20, 2016 at 11:31 AM, Jacopo Cappellato <
jacopo.cappellato@gmail.com> wrote:
>
> Should I start the thread today? Should I send you a preview of the message
> as soon as it is ready so that you can all comment and improve it?
>
What about wait until the current vote is over and release published?
I think that's a bit better timing...
--
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 6602747925
e: sergio.fernandez@redlink.co
w: http://redlink.co
Re: Graduation issues
Posted by Jacopo Cappellato <ja...@gmail.com>.
Thank you Sergio.
Should I start the thread today? Should I send you a preview of the message
as soon as it is ready so that you can all comment and improve it?
Jacopo
On Mon, Jun 20, 2016 at 10:58 AM, Sergio Fernández <wi...@apache.org>
wrote:
> On Sun, Jun 19, 2016 at 10:06 AM, Daniel Dekany <dd...@freemail.hu>
> wrote:
>
> > Who of the mentors plan to stay as PMC member after FM graduates?
> >
>
> I do.
>
> I think, before casting any graduation vote, I'd prefer to discuss these
> issues in general@incubator, so we get a more formed opinion from external
> people what they think about the viability of the community. I'd say
> that Jacopo, as Champion, should start it.
>
>
>
>
> Sunday, June 19, 2016, 4:39:54 AM, Ralph Goers wrote:
> >
> > > If the graduation vote fails the project would be told why. They
> > > would continue in the incubator if they choose until whatever issues
> > there were are addressed.
> > >
> > > PPMC members usually continue on as PMC members although mentors
> > frequently don’t stay on.
> > >
> > > Ralph
> > >
> > >> On Jun 18, 2016, at 7:01 AM, Daniel Dekany <dd...@freemail.hu>
> wrote:
> > >>
> > >> Saturday, June 18, 2016, 9:41:19 AM, Jacopo Cappellato wrote:
> > >>
> > >>> I agree that it is the right time to discuss graduation.
> > >>> In my opinion the incubation process for Freemarker has been
> > successful and
> > >>> for this reason I will vote +1 for the graduation.
> > >>> As anticipated when we initially discussed the incubation, one
> critical
> > >>> aspect of the Freemarker project was its small committer's base;
> under
> > this
> > >>> aspect the incubation process didn't do any magic and frankly
> speaking
> > I
> > >>> was not expecting it to happen.
> > >>> However, as mentioned by Daniel and Sergio, the project is mature but
> > there
> > >>> are plans for the future that will keep the community busy, not just
> > >>> maintaining the old code.
> > >>> This community has still to find a more effective way to attract new
> > >>> committers but this should not be a blocker to become a top level
> > project @
> > >>> ASF.
> > >>
> > >> And for the record, I think that requires some substantial
> > >> modernization/cleanup, which I have called FreeMarker 3 as it drops
> > >> backward compatibility. There are many things where FreeMarker 2 can
> > >> be evolved further without breaking backward compatibility, but making
> > >> the project more attractive is also timely, and the resources are
> > >> scarce, so I think we can't have both.
> > >>
> > >>> It is however important to verify that we will have, even after
> > graduation,
> > >>> a PMC group capable of casting at least 3 positive votes on releases.
> > >>
> > >> Is it customary for PPMC members of the poddling to be also in the PMC
> > >> of the graduated project? If so, can any of you express his intent
> > >> regarding that?
> > >>
> > >> What are the risks of failing the graduation vote?
> > >>
> > >> BTW, something that I can do to help it, to document some
> > >> project-specific rules, and a step-by-step release tutorial.
> > >>
> > >> --
> > >> Thanks,
> > >> Daniel Dekany
> > >>
> > >>
> > >>> Jacopo
> > >>>
> > >>> On Tue, Jun 14, 2016 at 1:55 PM, Sergio Fernández <wikier@apache.org
> >
> > wrote:
> > >>>
> > >>>> Hi Daniel,
> > >>>>
> > >>>> On Mon, Jun 13, 2016 at 9:18 PM, Daniel Dekany <ddekany@freemail.hu
> >
> > >>>> wrote:
> > >>>>
> > >>>>> I think we can start some discussion about that even now. Or at
> least
> > >>>>> I will tell what do I think about the state of the project.
> > >>>>>
> > >>>>
> > >>>> Great step. Thanks.
> > >>>>
> > >>>> The main problem is the number of active developers, which is 1, me.
> > >>>>>
> > >>>>
> > >>>> I'm aware...
> > >>>>
> > >>>>
> >
> https://github.com/apache/incubator-freemarker/graphs/contributors?from=2015-07-01&type=c
> > >>>>
> > >>>>
> > >>>>> What if I'm hit by a truck tomorrow? We can hope that if there's a
> > bug
> > >>>>> that concerns many, then someone will eventually fix it. After all
> > the
> > >>>>> owner (ASF) won't be gone, the release infrastructure is there,
> etc.
> > >>>>> But as far as non-bugfix development goes, it's certain that things
> > >>>>> would stop. Some may say that that's OK for a project that's
> > >>>>> backward-compatibility-locked for 12 years now (the 2.x line is
> > >>>>> actually 14 years old).
> > >>>>
> > >>>>
> > >>>> Well, I'd say that's critical, but the community of a project is
> more
> > than
> > >>>> the developers who code. And the Freemarker community is much bigger
> > than
> > >>>> what you could think.
> > >>>>
> > >>>> For instance if you consider my personal case: I volunteered for
> > mentor
> > >>>> because I knew the project for so long. I even code some extensions
> (
> > >>>> http://marmotta.apache.org/ldpath/template.html). Definitively I
> used
> > >>>> Freemarker much more in the past than currently, but Web development
> > has
> > >>>> changed a lot, moving more stuff to the frontend (10 years ago we
> > didn't
> > >>>> have AngularJS).
> > >>>>
> > >>>> So I'd say there are many people like me out there, using every day
> > >>>> solutions based on Freemarker. People who are not that close to the
> > source
> > >>>> base, but familiar enough to be able to jump in at any time a
> provide
> > a
> > >>>> patch.
> > >>>>
> > >>>>
> > >>>>
> > >>>>> But of course that's just slow death if a
> > >>>>> project can't counter its old design problems and can't evolve to
> > >>>>> tackle new problems anymore. So indeed 2.x should switch to
> > >>>>> maintenance eventually (but ATM there are still things that can be
> > >>>>> done in 2.x), but only to give place for 3.x. Anyway, how to catch
> > >>>>> long standing developers? I don't think that 2.x have a real chance
> > >>>>> for that, because of all the legacy code burden piled up. (Some
> > Apache
> > >>>>> projects have many paid contributors, but I think FM isn't the kind
> > of
> > >>>>> project that can have that, so it's important that the developers
> > want
> > >>>>> to fiddle with it for free.) So the 3.x jump will be necessary, and
> > >>>>> then, maybe, we can have a developer base growth (template engines
> > >>>>> isn't hot topic anymore, so I just mean having a few developers
> > >>>>> around). But 3.x is far away (if it will happen at all), and we
> can't
> > >>>>> hang around in the incubator forever.
> > >>>>
> > >>>>
> > >>>> Well, we can consider 2.3.x feature-complete, and 2.3.25-incubating
> a
> > >>>> maintenance release. The world has change a lot in template business
> > in
> > >>>> these 14 years. But I'm pretty sure FreeMarker has its place there,
> > and 3.x
> > >>>> could bring some many great ideas that may attract potential new
> > >>>> contributors. And that's what I see as future of this project.
> > >>>>
> > >>>>
> > >>>>> So, do you believe there's any chance to graduate with the current
> > >>>>> developer base?
> > >>>>>
> > >>>>
> > >>>> Definitively that has been always the major issue with this podling.
> > >>>> Honestly I'm not sure. But following with all my argumentation that
> > the
> > >>>> community is much bigger that what shows the development team, I'd
> say
> > >>>> could be at least discussed with the IPMC.
> > >>>>
> > >>>> Looking forward to hear every body else's opinions.
> > >>>>
> > >>>> Cheers,
> > >>>>
> > >>>> --
> > >>>> Sergio Fernández
> > >>>> Partner Technology Manager
> > >>>> Redlink GmbH
> > >>>> m: +43 6602747925
> > >>>> e: sergio.fernandez@redlink.co
> > >>>> w: http://redlink.co
> > >>>>
> > >>
> > >>
> > >
> > >
> > >
> >
> >
>
>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 6602747925
> e: sergio.fernandez@redlink.co
> w: http://redlink.co
>
Re: Graduation issues
Posted by Sergio Fernández <wi...@apache.org>.
On Sun, Jun 19, 2016 at 10:06 AM, Daniel Dekany <dd...@freemail.hu> wrote:
> Who of the mentors plan to stay as PMC member after FM graduates?
>
I do.
I think, before casting any graduation vote, I'd prefer to discuss these
issues in general@incubator, so we get a more formed opinion from external
people what they think about the viability of the community. I'd say
that Jacopo, as Champion, should start it.
Sunday, June 19, 2016, 4:39:54 AM, Ralph Goers wrote:
>
> > If the graduation vote fails the project would be told why. They
> > would continue in the incubator if they choose until whatever issues
> there were are addressed.
> >
> > PPMC members usually continue on as PMC members although mentors
> frequently don’t stay on.
> >
> > Ralph
> >
> >> On Jun 18, 2016, at 7:01 AM, Daniel Dekany <dd...@freemail.hu> wrote:
> >>
> >> Saturday, June 18, 2016, 9:41:19 AM, Jacopo Cappellato wrote:
> >>
> >>> I agree that it is the right time to discuss graduation.
> >>> In my opinion the incubation process for Freemarker has been
> successful and
> >>> for this reason I will vote +1 for the graduation.
> >>> As anticipated when we initially discussed the incubation, one critical
> >>> aspect of the Freemarker project was its small committer's base; under
> this
> >>> aspect the incubation process didn't do any magic and frankly speaking
> I
> >>> was not expecting it to happen.
> >>> However, as mentioned by Daniel and Sergio, the project is mature but
> there
> >>> are plans for the future that will keep the community busy, not just
> >>> maintaining the old code.
> >>> This community has still to find a more effective way to attract new
> >>> committers but this should not be a blocker to become a top level
> project @
> >>> ASF.
> >>
> >> And for the record, I think that requires some substantial
> >> modernization/cleanup, which I have called FreeMarker 3 as it drops
> >> backward compatibility. There are many things where FreeMarker 2 can
> >> be evolved further without breaking backward compatibility, but making
> >> the project more attractive is also timely, and the resources are
> >> scarce, so I think we can't have both.
> >>
> >>> It is however important to verify that we will have, even after
> graduation,
> >>> a PMC group capable of casting at least 3 positive votes on releases.
> >>
> >> Is it customary for PPMC members of the poddling to be also in the PMC
> >> of the graduated project? If so, can any of you express his intent
> >> regarding that?
> >>
> >> What are the risks of failing the graduation vote?
> >>
> >> BTW, something that I can do to help it, to document some
> >> project-specific rules, and a step-by-step release tutorial.
> >>
> >> --
> >> Thanks,
> >> Daniel Dekany
> >>
> >>
> >>> Jacopo
> >>>
> >>> On Tue, Jun 14, 2016 at 1:55 PM, Sergio Fernández <wi...@apache.org>
> wrote:
> >>>
> >>>> Hi Daniel,
> >>>>
> >>>> On Mon, Jun 13, 2016 at 9:18 PM, Daniel Dekany <dd...@freemail.hu>
> >>>> wrote:
> >>>>
> >>>>> I think we can start some discussion about that even now. Or at least
> >>>>> I will tell what do I think about the state of the project.
> >>>>>
> >>>>
> >>>> Great step. Thanks.
> >>>>
> >>>> The main problem is the number of active developers, which is 1, me.
> >>>>>
> >>>>
> >>>> I'm aware...
> >>>>
> >>>>
> https://github.com/apache/incubator-freemarker/graphs/contributors?from=2015-07-01&type=c
> >>>>
> >>>>
> >>>>> What if I'm hit by a truck tomorrow? We can hope that if there's a
> bug
> >>>>> that concerns many, then someone will eventually fix it. After all
> the
> >>>>> owner (ASF) won't be gone, the release infrastructure is there, etc.
> >>>>> But as far as non-bugfix development goes, it's certain that things
> >>>>> would stop. Some may say that that's OK for a project that's
> >>>>> backward-compatibility-locked for 12 years now (the 2.x line is
> >>>>> actually 14 years old).
> >>>>
> >>>>
> >>>> Well, I'd say that's critical, but the community of a project is more
> than
> >>>> the developers who code. And the Freemarker community is much bigger
> than
> >>>> what you could think.
> >>>>
> >>>> For instance if you consider my personal case: I volunteered for
> mentor
> >>>> because I knew the project for so long. I even code some extensions (
> >>>> http://marmotta.apache.org/ldpath/template.html). Definitively I used
> >>>> Freemarker much more in the past than currently, but Web development
> has
> >>>> changed a lot, moving more stuff to the frontend (10 years ago we
> didn't
> >>>> have AngularJS).
> >>>>
> >>>> So I'd say there are many people like me out there, using every day
> >>>> solutions based on Freemarker. People who are not that close to the
> source
> >>>> base, but familiar enough to be able to jump in at any time a provide
> a
> >>>> patch.
> >>>>
> >>>>
> >>>>
> >>>>> But of course that's just slow death if a
> >>>>> project can't counter its old design problems and can't evolve to
> >>>>> tackle new problems anymore. So indeed 2.x should switch to
> >>>>> maintenance eventually (but ATM there are still things that can be
> >>>>> done in 2.x), but only to give place for 3.x. Anyway, how to catch
> >>>>> long standing developers? I don't think that 2.x have a real chance
> >>>>> for that, because of all the legacy code burden piled up. (Some
> Apache
> >>>>> projects have many paid contributors, but I think FM isn't the kind
> of
> >>>>> project that can have that, so it's important that the developers
> want
> >>>>> to fiddle with it for free.) So the 3.x jump will be necessary, and
> >>>>> then, maybe, we can have a developer base growth (template engines
> >>>>> isn't hot topic anymore, so I just mean having a few developers
> >>>>> around). But 3.x is far away (if it will happen at all), and we can't
> >>>>> hang around in the incubator forever.
> >>>>
> >>>>
> >>>> Well, we can consider 2.3.x feature-complete, and 2.3.25-incubating a
> >>>> maintenance release. The world has change a lot in template business
> in
> >>>> these 14 years. But I'm pretty sure FreeMarker has its place there,
> and 3.x
> >>>> could bring some many great ideas that may attract potential new
> >>>> contributors. And that's what I see as future of this project.
> >>>>
> >>>>
> >>>>> So, do you believe there's any chance to graduate with the current
> >>>>> developer base?
> >>>>>
> >>>>
> >>>> Definitively that has been always the major issue with this podling.
> >>>> Honestly I'm not sure. But following with all my argumentation that
> the
> >>>> community is much bigger that what shows the development team, I'd say
> >>>> could be at least discussed with the IPMC.
> >>>>
> >>>> Looking forward to hear every body else's opinions.
> >>>>
> >>>> Cheers,
> >>>>
> >>>> --
> >>>> Sergio Fernández
> >>>> Partner Technology Manager
> >>>> Redlink GmbH
> >>>> m: +43 6602747925
> >>>> e: sergio.fernandez@redlink.co
> >>>> w: http://redlink.co
> >>>>
> >>
> >>
> >
> >
> >
>
>
--
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 6602747925
e: sergio.fernandez@redlink.co
w: http://redlink.co
Re: Graduation issues
Posted by Daniel Dekany <dd...@freemail.hu>.
Who of the mentors plan to stay as PMC member after FM graduates?
--
Thanks,
Daniel Dekany
Sunday, June 19, 2016, 4:39:54 AM, Ralph Goers wrote:
> If the graduation vote fails the project would be told why. They
> would continue in the incubator if they choose until whatever issues there were are addressed.
>
> PPMC members usually continue on as PMC members although mentors frequently don\u2019t stay on.
>
> Ralph
>
>> On Jun 18, 2016, at 7:01 AM, Daniel Dekany <dd...@freemail.hu> wrote:
>>
>> Saturday, June 18, 2016, 9:41:19 AM, Jacopo Cappellato wrote:
>>
>>> I agree that it is the right time to discuss graduation.
>>> In my opinion the incubation process for Freemarker has been successful and
>>> for this reason I will vote +1 for the graduation.
>>> As anticipated when we initially discussed the incubation, one critical
>>> aspect of the Freemarker project was its small committer's base; under this
>>> aspect the incubation process didn't do any magic and frankly speaking I
>>> was not expecting it to happen.
>>> However, as mentioned by Daniel and Sergio, the project is mature but there
>>> are plans for the future that will keep the community busy, not just
>>> maintaining the old code.
>>> This community has still to find a more effective way to attract new
>>> committers but this should not be a blocker to become a top level project @
>>> ASF.
>>
>> And for the record, I think that requires some substantial
>> modernization/cleanup, which I have called FreeMarker 3 as it drops
>> backward compatibility. There are many things where FreeMarker 2 can
>> be evolved further without breaking backward compatibility, but making
>> the project more attractive is also timely, and the resources are
>> scarce, so I think we can't have both.
>>
>>> It is however important to verify that we will have, even after graduation,
>>> a PMC group capable of casting at least 3 positive votes on releases.
>>
>> Is it customary for PPMC members of the poddling to be also in the PMC
>> of the graduated project? If so, can any of you express his intent
>> regarding that?
>>
>> What are the risks of failing the graduation vote?
>>
>> BTW, something that I can do to help it, to document some
>> project-specific rules, and a step-by-step release tutorial.
>>
>> --
>> Thanks,
>> Daniel Dekany
>>
>>
>>> Jacopo
>>>
>>> On Tue, Jun 14, 2016 at 1:55 PM, Sergio Fern�ndez <wi...@apache.org> wrote:
>>>
>>>> Hi Daniel,
>>>>
>>>> On Mon, Jun 13, 2016 at 9:18 PM, Daniel Dekany <dd...@freemail.hu>
>>>> wrote:
>>>>
>>>>> I think we can start some discussion about that even now. Or at least
>>>>> I will tell what do I think about the state of the project.
>>>>>
>>>>
>>>> Great step. Thanks.
>>>>
>>>> The main problem is the number of active developers, which is 1, me.
>>>>>
>>>>
>>>> I'm aware...
>>>>
>>>> https://github.com/apache/incubator-freemarker/graphs/contributors?from=2015-07-01&type=c
>>>>
>>>>
>>>>> What if I'm hit by a truck tomorrow? We can hope that if there's a bug
>>>>> that concerns many, then someone will eventually fix it. After all the
>>>>> owner (ASF) won't be gone, the release infrastructure is there, etc.
>>>>> But as far as non-bugfix development goes, it's certain that things
>>>>> would stop. Some may say that that's OK for a project that's
>>>>> backward-compatibility-locked for 12 years now (the 2.x line is
>>>>> actually 14 years old).
>>>>
>>>>
>>>> Well, I'd say that's critical, but the community of a project is more than
>>>> the developers who code. And the Freemarker community is much bigger than
>>>> what you could think.
>>>>
>>>> For instance if you consider my personal case: I volunteered for mentor
>>>> because I knew the project for so long. I even code some extensions (
>>>> http://marmotta.apache.org/ldpath/template.html). Definitively I used
>>>> Freemarker much more in the past than currently, but Web development has
>>>> changed a lot, moving more stuff to the frontend (10 years ago we didn't
>>>> have AngularJS).
>>>>
>>>> So I'd say there are many people like me out there, using every day
>>>> solutions based on Freemarker. People who are not that close to the source
>>>> base, but familiar enough to be able to jump in at any time a provide a
>>>> patch.
>>>>
>>>>
>>>>
>>>>> But of course that's just slow death if a
>>>>> project can't counter its old design problems and can't evolve to
>>>>> tackle new problems anymore. So indeed 2.x should switch to
>>>>> maintenance eventually (but ATM there are still things that can be
>>>>> done in 2.x), but only to give place for 3.x. Anyway, how to catch
>>>>> long standing developers? I don't think that 2.x have a real chance
>>>>> for that, because of all the legacy code burden piled up. (Some Apache
>>>>> projects have many paid contributors, but I think FM isn't the kind of
>>>>> project that can have that, so it's important that the developers want
>>>>> to fiddle with it for free.) So the 3.x jump will be necessary, and
>>>>> then, maybe, we can have a developer base growth (template engines
>>>>> isn't hot topic anymore, so I just mean having a few developers
>>>>> around). But 3.x is far away (if it will happen at all), and we can't
>>>>> hang around in the incubator forever.
>>>>
>>>>
>>>> Well, we can consider 2.3.x feature-complete, and 2.3.25-incubating a
>>>> maintenance release. The world has change a lot in template business in
>>>> these 14 years. But I'm pretty sure FreeMarker has its place there, and 3.x
>>>> could bring some many great ideas that may attract potential new
>>>> contributors. And that's what I see as future of this project.
>>>>
>>>>
>>>>> So, do you believe there's any chance to graduate with the current
>>>>> developer base?
>>>>>
>>>>
>>>> Definitively that has been always the major issue with this podling.
>>>> Honestly I'm not sure. But following with all my argumentation that the
>>>> community is much bigger that what shows the development team, I'd say
>>>> could be at least discussed with the IPMC.
>>>>
>>>> Looking forward to hear every body else's opinions.
>>>>
>>>> Cheers,
>>>>
>>>> --
>>>> Sergio Fern�ndez
>>>> Partner Technology Manager
>>>> Redlink GmbH
>>>> m: +43 6602747925
>>>> e: sergio.fernandez@redlink.co
>>>> w: http://redlink.co
>>>>
>>
>>
>
>
>
Re: Graduation issues
Posted by Ralph Goers <ra...@dslextreme.com>.
If the graduation vote fails the project would be told why. They would continue in the incubator if they choose until whatever issues there were are addressed.
PPMC members usually continue on as PMC members although mentors frequently don’t stay on.
Ralph
> On Jun 18, 2016, at 7:01 AM, Daniel Dekany <dd...@freemail.hu> wrote:
>
> Saturday, June 18, 2016, 9:41:19 AM, Jacopo Cappellato wrote:
>
>> I agree that it is the right time to discuss graduation.
>> In my opinion the incubation process for Freemarker has been successful and
>> for this reason I will vote +1 for the graduation.
>> As anticipated when we initially discussed the incubation, one critical
>> aspect of the Freemarker project was its small committer's base; under this
>> aspect the incubation process didn't do any magic and frankly speaking I
>> was not expecting it to happen.
>> However, as mentioned by Daniel and Sergio, the project is mature but there
>> are plans for the future that will keep the community busy, not just
>> maintaining the old code.
>> This community has still to find a more effective way to attract new
>> committers but this should not be a blocker to become a top level project @
>> ASF.
>
> And for the record, I think that requires some substantial
> modernization/cleanup, which I have called FreeMarker 3 as it drops
> backward compatibility. There are many things where FreeMarker 2 can
> be evolved further without breaking backward compatibility, but making
> the project more attractive is also timely, and the resources are
> scarce, so I think we can't have both.
>
>> It is however important to verify that we will have, even after graduation,
>> a PMC group capable of casting at least 3 positive votes on releases.
>
> Is it customary for PPMC members of the poddling to be also in the PMC
> of the graduated project? If so, can any of you express his intent
> regarding that?
>
> What are the risks of failing the graduation vote?
>
> BTW, something that I can do to help it, to document some
> project-specific rules, and a step-by-step release tutorial.
>
> --
> Thanks,
> Daniel Dekany
>
>
>> Jacopo
>>
>> On Tue, Jun 14, 2016 at 1:55 PM, Sergio Fernández <wi...@apache.org> wrote:
>>
>>> Hi Daniel,
>>>
>>> On Mon, Jun 13, 2016 at 9:18 PM, Daniel Dekany <dd...@freemail.hu>
>>> wrote:
>>>
>>>> I think we can start some discussion about that even now. Or at least
>>>> I will tell what do I think about the state of the project.
>>>>
>>>
>>> Great step. Thanks.
>>>
>>> The main problem is the number of active developers, which is 1, me.
>>>>
>>>
>>> I'm aware...
>>>
>>> https://github.com/apache/incubator-freemarker/graphs/contributors?from=2015-07-01&type=c
>>>
>>>
>>>> What if I'm hit by a truck tomorrow? We can hope that if there's a bug
>>>> that concerns many, then someone will eventually fix it. After all the
>>>> owner (ASF) won't be gone, the release infrastructure is there, etc.
>>>> But as far as non-bugfix development goes, it's certain that things
>>>> would stop. Some may say that that's OK for a project that's
>>>> backward-compatibility-locked for 12 years now (the 2.x line is
>>>> actually 14 years old).
>>>
>>>
>>> Well, I'd say that's critical, but the community of a project is more than
>>> the developers who code. And the Freemarker community is much bigger than
>>> what you could think.
>>>
>>> For instance if you consider my personal case: I volunteered for mentor
>>> because I knew the project for so long. I even code some extensions (
>>> http://marmotta.apache.org/ldpath/template.html). Definitively I used
>>> Freemarker much more in the past than currently, but Web development has
>>> changed a lot, moving more stuff to the frontend (10 years ago we didn't
>>> have AngularJS).
>>>
>>> So I'd say there are many people like me out there, using every day
>>> solutions based on Freemarker. People who are not that close to the source
>>> base, but familiar enough to be able to jump in at any time a provide a
>>> patch.
>>>
>>>
>>>
>>>> But of course that's just slow death if a
>>>> project can't counter its old design problems and can't evolve to
>>>> tackle new problems anymore. So indeed 2.x should switch to
>>>> maintenance eventually (but ATM there are still things that can be
>>>> done in 2.x), but only to give place for 3.x. Anyway, how to catch
>>>> long standing developers? I don't think that 2.x have a real chance
>>>> for that, because of all the legacy code burden piled up. (Some Apache
>>>> projects have many paid contributors, but I think FM isn't the kind of
>>>> project that can have that, so it's important that the developers want
>>>> to fiddle with it for free.) So the 3.x jump will be necessary, and
>>>> then, maybe, we can have a developer base growth (template engines
>>>> isn't hot topic anymore, so I just mean having a few developers
>>>> around). But 3.x is far away (if it will happen at all), and we can't
>>>> hang around in the incubator forever.
>>>
>>>
>>> Well, we can consider 2.3.x feature-complete, and 2.3.25-incubating a
>>> maintenance release. The world has change a lot in template business in
>>> these 14 years. But I'm pretty sure FreeMarker has its place there, and 3.x
>>> could bring some many great ideas that may attract potential new
>>> contributors. And that's what I see as future of this project.
>>>
>>>
>>>> So, do you believe there's any chance to graduate with the current
>>>> developer base?
>>>>
>>>
>>> Definitively that has been always the major issue with this podling.
>>> Honestly I'm not sure. But following with all my argumentation that the
>>> community is much bigger that what shows the development team, I'd say
>>> could be at least discussed with the IPMC.
>>>
>>> Looking forward to hear every body else's opinions.
>>>
>>> Cheers,
>>>
>>> --
>>> Sergio Fernández
>>> Partner Technology Manager
>>> Redlink GmbH
>>> m: +43 6602747925
>>> e: sergio.fernandez@redlink.co
>>> w: http://redlink.co
>>>
>
>
Re: Graduation issues
Posted by Daniel Dekany <dd...@freemail.hu>.
Saturday, June 18, 2016, 9:41:19 AM, Jacopo Cappellato wrote:
> I agree that it is the right time to discuss graduation.
> In my opinion the incubation process for Freemarker has been successful and
> for this reason I will vote +1 for the graduation.
> As anticipated when we initially discussed the incubation, one critical
> aspect of the Freemarker project was its small committer's base; under this
> aspect the incubation process didn't do any magic and frankly speaking I
> was not expecting it to happen.
> However, as mentioned by Daniel and Sergio, the project is mature but there
> are plans for the future that will keep the community busy, not just
> maintaining the old code.
> This community has still to find a more effective way to attract new
> committers but this should not be a blocker to become a top level project @
> ASF.
And for the record, I think that requires some substantial
modernization/cleanup, which I have called FreeMarker 3 as it drops
backward compatibility. There are many things where FreeMarker 2 can
be evolved further without breaking backward compatibility, but making
the project more attractive is also timely, and the resources are
scarce, so I think we can't have both.
> It is however important to verify that we will have, even after graduation,
> a PMC group capable of casting at least 3 positive votes on releases.
Is it customary for PPMC members of the poddling to be also in the PMC
of the graduated project? If so, can any of you express his intent
regarding that?
What are the risks of failing the graduation vote?
BTW, something that I can do to help it, to document some
project-specific rules, and a step-by-step release tutorial.
--
Thanks,
Daniel Dekany
> Jacopo
>
> On Tue, Jun 14, 2016 at 1:55 PM, Sergio Fern�ndez <wi...@apache.org> wrote:
>
>> Hi Daniel,
>>
>> On Mon, Jun 13, 2016 at 9:18 PM, Daniel Dekany <dd...@freemail.hu>
>> wrote:
>>
>> > I think we can start some discussion about that even now. Or at least
>> > I will tell what do I think about the state of the project.
>> >
>>
>> Great step. Thanks.
>>
>> The main problem is the number of active developers, which is 1, me.
>> >
>>
>> I'm aware...
>>
>> https://github.com/apache/incubator-freemarker/graphs/contributors?from=2015-07-01&type=c
>>
>>
>> > What if I'm hit by a truck tomorrow? We can hope that if there's a bug
>> > that concerns many, then someone will eventually fix it. After all the
>> > owner (ASF) won't be gone, the release infrastructure is there, etc.
>> > But as far as non-bugfix development goes, it's certain that things
>> > would stop. Some may say that that's OK for a project that's
>> > backward-compatibility-locked for 12 years now (the 2.x line is
>> > actually 14 years old).
>>
>>
>> Well, I'd say that's critical, but the community of a project is more than
>> the developers who code. And the Freemarker community is much bigger than
>> what you could think.
>>
>> For instance if you consider my personal case: I volunteered for mentor
>> because I knew the project for so long. I even code some extensions (
>> http://marmotta.apache.org/ldpath/template.html). Definitively I used
>> Freemarker much more in the past than currently, but Web development has
>> changed a lot, moving more stuff to the frontend (10 years ago we didn't
>> have AngularJS).
>>
>> So I'd say there are many people like me out there, using every day
>> solutions based on Freemarker. People who are not that close to the source
>> base, but familiar enough to be able to jump in at any time a provide a
>> patch.
>>
>>
>>
>> > But of course that's just slow death if a
>> > project can't counter its old design problems and can't evolve to
>> > tackle new problems anymore. So indeed 2.x should switch to
>> > maintenance eventually (but ATM there are still things that can be
>> > done in 2.x), but only to give place for 3.x. Anyway, how to catch
>> > long standing developers? I don't think that 2.x have a real chance
>> > for that, because of all the legacy code burden piled up. (Some Apache
>> > projects have many paid contributors, but I think FM isn't the kind of
>> > project that can have that, so it's important that the developers want
>> > to fiddle with it for free.) So the 3.x jump will be necessary, and
>> > then, maybe, we can have a developer base growth (template engines
>> > isn't hot topic anymore, so I just mean having a few developers
>> > around). But 3.x is far away (if it will happen at all), and we can't
>> > hang around in the incubator forever.
>>
>>
>> Well, we can consider 2.3.x feature-complete, and 2.3.25-incubating a
>> maintenance release. The world has change a lot in template business in
>> these 14 years. But I'm pretty sure FreeMarker has its place there, and 3.x
>> could bring some many great ideas that may attract potential new
>> contributors. And that's what I see as future of this project.
>>
>>
>> > So, do you believe there's any chance to graduate with the current
>> > developer base?
>> >
>>
>> Definitively that has been always the major issue with this podling.
>> Honestly I'm not sure. But following with all my argumentation that the
>> community is much bigger that what shows the development team, I'd say
>> could be at least discussed with the IPMC.
>>
>> Looking forward to hear every body else's opinions.
>>
>> Cheers,
>>
>> --
>> Sergio Fern�ndez
>> Partner Technology Manager
>> Redlink GmbH
>> m: +43 6602747925
>> e: sergio.fernandez@redlink.co
>> w: http://redlink.co
>>
Re: Graduation issues
Posted by Jacopo Cappellato <ja...@gmail.com>.
I agree that it is the right time to discuss graduation.
In my opinion the incubation process for Freemarker has been successful and
for this reason I will vote +1 for the graduation.
As anticipated when we initially discussed the incubation, one critical
aspect of the Freemarker project was its small committer's base; under this
aspect the incubation process didn't do any magic and frankly speaking I
was not expecting it to happen.
However, as mentioned by Daniel and Sergio, the project is mature but there
are plans for the future that will keep the community busy, not just
maintaining the old code.
This community has still to find a more effective way to attract new
committers but this should not be a blocker to become a top level project @
ASF.
It is however important to verify that we will have, even after graduation,
a PMC group capable of casting at least 3 positive votes on releases.
Jacopo
On Tue, Jun 14, 2016 at 1:55 PM, Sergio Fernández <wi...@apache.org> wrote:
> Hi Daniel,
>
> On Mon, Jun 13, 2016 at 9:18 PM, Daniel Dekany <dd...@freemail.hu>
> wrote:
>
> > I think we can start some discussion about that even now. Or at least
> > I will tell what do I think about the state of the project.
> >
>
> Great step. Thanks.
>
> The main problem is the number of active developers, which is 1, me.
> >
>
> I'm aware...
>
> https://github.com/apache/incubator-freemarker/graphs/contributors?from=2015-07-01&type=c
>
>
> > What if I'm hit by a truck tomorrow? We can hope that if there's a bug
> > that concerns many, then someone will eventually fix it. After all the
> > owner (ASF) won't be gone, the release infrastructure is there, etc.
> > But as far as non-bugfix development goes, it's certain that things
> > would stop. Some may say that that's OK for a project that's
> > backward-compatibility-locked for 12 years now (the 2.x line is
> > actually 14 years old).
>
>
> Well, I'd say that's critical, but the community of a project is more than
> the developers who code. And the Freemarker community is much bigger than
> what you could think.
>
> For instance if you consider my personal case: I volunteered for mentor
> because I knew the project for so long. I even code some extensions (
> http://marmotta.apache.org/ldpath/template.html). Definitively I used
> Freemarker much more in the past than currently, but Web development has
> changed a lot, moving more stuff to the frontend (10 years ago we didn't
> have AngularJS).
>
> So I'd say there are many people like me out there, using every day
> solutions based on Freemarker. People who are not that close to the source
> base, but familiar enough to be able to jump in at any time a provide a
> patch.
>
>
>
> > But of course that's just slow death if a
> > project can't counter its old design problems and can't evolve to
> > tackle new problems anymore. So indeed 2.x should switch to
> > maintenance eventually (but ATM there are still things that can be
> > done in 2.x), but only to give place for 3.x. Anyway, how to catch
> > long standing developers? I don't think that 2.x have a real chance
> > for that, because of all the legacy code burden piled up. (Some Apache
> > projects have many paid contributors, but I think FM isn't the kind of
> > project that can have that, so it's important that the developers want
> > to fiddle with it for free.) So the 3.x jump will be necessary, and
> > then, maybe, we can have a developer base growth (template engines
> > isn't hot topic anymore, so I just mean having a few developers
> > around). But 3.x is far away (if it will happen at all), and we can't
> > hang around in the incubator forever.
>
>
> Well, we can consider 2.3.x feature-complete, and 2.3.25-incubating a
> maintenance release. The world has change a lot in template business in
> these 14 years. But I'm pretty sure FreeMarker has its place there, and 3.x
> could bring some many great ideas that may attract potential new
> contributors. And that's what I see as future of this project.
>
>
> > So, do you believe there's any chance to graduate with the current
> > developer base?
> >
>
> Definitively that has been always the major issue with this podling.
> Honestly I'm not sure. But following with all my argumentation that the
> community is much bigger that what shows the development team, I'd say
> could be at least discussed with the IPMC.
>
> Looking forward to hear every body else's opinions.
>
> Cheers,
>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 6602747925
> e: sergio.fernandez@redlink.co
> w: http://redlink.co
>
Re: Graduation issues
Posted by Pete Helgren <pe...@valadd.com>.
I am using the Liferay IDE plugin and the reference that I assume is the
syntax checking and highlighting is the "Liferay IDE Freemarker" plugin
reference in Eclipse (Luna) com.liferay.ide.freemarker that comes with
the Liferay IDE but I haven't opened up the source and taken a look. I
saw a few posts from the LR developers here a long while ago.
I do need to check out the debugging features (if any). That would be
helpful.
Pete Helgren
www.petesworkshop.com
GIAC Secure Software Programmer-Java
On 6/17/2016 1:35 AM, Daniel Dekany wrote:
> As far as I remember their plugin was based on the "FreeMarker IDE"
> JBoss plugin. Have you also tried that plugin? (In Eclipse, "Help" /
> "Install New Software...",
> http://download.jboss.org/jbosstools/neon/snapshots/builds/jbosstools-freemarker_master/latest/all/repo/)
> Is there much difference? I remember they have tried to add debugging
> support, but I don't know how far that got.
>
> BTW, contributing to the Eclipse plugin is an effective way of helping
> the project. It's at JBoss though, not at ASF. (But see on
> http://freemarker.org/contribute.html)
>
>
> Thursday, June 16, 2016, 8:54:41 PM, Pete Helgren wrote:
>
>> Well, "recent" IS recent. Like two weeks ago I pulled down Liferay 7.0
>> and started to see if we could migrate our stuff from 6.0.6 to 7.0.
>> 6.0.6 has support for both Velocity and Freemarker but most of the UI
>> templates were in Velocity although I think they used Freemarker pretty
>> extensively in their templates for their "service builder" application.
>> Supposedly there is parity in the out of the box templates for UI but I
>> already tripped across a couple of templates that had a more complete
>> Velocity implementation than FM.
>>
>> IOW it's too soon to have an opinion. You may not remember but I am
>> *still* using Jonathan Revusky's "Niggle" project, which wraps
>> Freemarker, so I use Freemarker nominally but will be using templates
>> more. Liferay developed, or enhanced, a Freemarker syntax highlighting
>> plugin which I have appreciated.
>>
>> Once I get my feet a bit more "wet" I'll probably have a better opinion
>> on the templating side.
>>
>> Pete Helgren
>> www.petesworkshop.com
>> GIAC Secure Software Programmer-Java
>>
>> On 6/16/2016 11:55 AM, Daniel Dekany wrote:
>>> Hi Pete,
>>>
>>> Liferay is one of the more important FM users today, based on the
>>> number of FM questions on StackOverflow that are Liferay related. So
>>> it would be interesting to know what are the top annoyances or other
>>> improvement ideas in that particular environment. Can you tell any?
>>>
>>>
>>> Wednesday, June 15, 2016, 4:19:18 PM, Pete Helgren wrote:
>>>
>>>> On 6/14/2016 12:20 PM, Daniel Dekany wrote:
>>>>> Tuesday, June 14, 2016, 1:55:05 PM, Sergio Fern�ndez wrote:
>>>>>
>>>>> [snip]
>>>>>> Definitively I used Freemarker much more in the past than currently,
>>>>>> but Web development has changed a lot, moving more stuff to the
>>>>>> frontend (10 years ago we didn't have AngularJS).
>>>>> Yip, that's why I intend to focus on non-Web applications much more in
>>>>> FM 3. There are some interesting challenges there. One is the common
>>>>> need for the much smarter handling of white-space. Another is entering
>>>>> templates in WYSIWYG editors (it has some tricky aspects). Would be
>>>>> fun to work on those instead of fighting with FM 2 legacy.
>>>>>
>>>> +1
>>>>
>>>> Most of my involvement is from a user perspective and I really haven't
>>>> used much template stuff in a while but in the past 4 years have worked
>>>> with Liferay portal and they use both Velocity and Freemarker and have
>>>> recently shifted more to Freemarker. So after being out of the template
>>>> arena for a while, I am back in.
>>>>
>>>> My Java skills aren't nearly at the level the rest of the group on this
>>>> list has but I will try to jump in on the stuff that can fit my skill level.
>>>>
>>>> Pete
>>
Re: Graduation issues
Posted by Daniel Dekany <dd...@freemail.hu>.
As far as I remember their plugin was based on the "FreeMarker IDE"
JBoss plugin. Have you also tried that plugin? (In Eclipse, "Help" /
"Install New Software...",
http://download.jboss.org/jbosstools/neon/snapshots/builds/jbosstools-freemarker_master/latest/all/repo/)
Is there much difference? I remember they have tried to add debugging
support, but I don't know how far that got.
BTW, contributing to the Eclipse plugin is an effective way of helping
the project. It's at JBoss though, not at ASF. (But see on
http://freemarker.org/contribute.html)
Thursday, June 16, 2016, 8:54:41 PM, Pete Helgren wrote:
> Well, "recent" IS recent. Like two weeks ago I pulled down Liferay 7.0
> and started to see if we could migrate our stuff from 6.0.6 to 7.0.
> 6.0.6 has support for both Velocity and Freemarker but most of the UI
> templates were in Velocity although I think they used Freemarker pretty
> extensively in their templates for their "service builder" application.
> Supposedly there is parity in the out of the box templates for UI but I
> already tripped across a couple of templates that had a more complete
> Velocity implementation than FM.
>
> IOW it's too soon to have an opinion. You may not remember but I am
> *still* using Jonathan Revusky's "Niggle" project, which wraps
> Freemarker, so I use Freemarker nominally but will be using templates
> more. Liferay developed, or enhanced, a Freemarker syntax highlighting
> plugin which I have appreciated.
>
> Once I get my feet a bit more "wet" I'll probably have a better opinion
> on the templating side.
>
> Pete Helgren
> www.petesworkshop.com
> GIAC Secure Software Programmer-Java
>
> On 6/16/2016 11:55 AM, Daniel Dekany wrote:
>> Hi Pete,
>>
>> Liferay is one of the more important FM users today, based on the
>> number of FM questions on StackOverflow that are Liferay related. So
>> it would be interesting to know what are the top annoyances or other
>> improvement ideas in that particular environment. Can you tell any?
>>
>>
>> Wednesday, June 15, 2016, 4:19:18 PM, Pete Helgren wrote:
>>
>>> On 6/14/2016 12:20 PM, Daniel Dekany wrote:
>>>> Tuesday, June 14, 2016, 1:55:05 PM, Sergio Fern�ndez wrote:
>>>>
>>>> [snip]
>>>>> Definitively I used Freemarker much more in the past than currently,
>>>>> but Web development has changed a lot, moving more stuff to the
>>>>> frontend (10 years ago we didn't have AngularJS).
>>>> Yip, that's why I intend to focus on non-Web applications much more in
>>>> FM 3. There are some interesting challenges there. One is the common
>>>> need for the much smarter handling of white-space. Another is entering
>>>> templates in WYSIWYG editors (it has some tricky aspects). Would be
>>>> fun to work on those instead of fighting with FM 2 legacy.
>>>>
>>> +1
>>>
>>> Most of my involvement is from a user perspective and I really haven't
>>> used much template stuff in a while but in the past 4 years have worked
>>> with Liferay portal and they use both Velocity and Freemarker and have
>>> recently shifted more to Freemarker. So after being out of the template
>>> arena for a while, I am back in.
>>>
>>> My Java skills aren't nearly at the level the rest of the group on this
>>> list has but I will try to jump in on the stuff that can fit my skill level.
>>>
>>> Pete
>
>
--
Thanks,
Daniel Dekany
Re: Graduation issues
Posted by Pete Helgren <pe...@valadd.com>.
Well, "recent" IS recent. Like two weeks ago I pulled down Liferay 7.0
and started to see if we could migrate our stuff from 6.0.6 to 7.0.
6.0.6 has support for both Velocity and Freemarker but most of the UI
templates were in Velocity although I think they used Freemarker pretty
extensively in their templates for their "service builder" application.
Supposedly there is parity in the out of the box templates for UI but I
already tripped across a couple of templates that had a more complete
Velocity implementation than FM.
IOW it's too soon to have an opinion. You may not remember but I am
*still* using Jonathan Revusky's "Niggle" project, which wraps
Freemarker, so I use Freemarker nominally but will be using templates
more. Liferay developed, or enhanced, a Freemarker syntax highlighting
plugin which I have appreciated.
Once I get my feet a bit more "wet" I'll probably have a better opinion
on the templating side.
Pete Helgren
www.petesworkshop.com
GIAC Secure Software Programmer-Java
On 6/16/2016 11:55 AM, Daniel Dekany wrote:
> Hi Pete,
>
> Liferay is one of the more important FM users today, based on the
> number of FM questions on StackOverflow that are Liferay related. So
> it would be interesting to know what are the top annoyances or other
> improvement ideas in that particular environment. Can you tell any?
>
>
> Wednesday, June 15, 2016, 4:19:18 PM, Pete Helgren wrote:
>
>> On 6/14/2016 12:20 PM, Daniel Dekany wrote:
>>> Tuesday, June 14, 2016, 1:55:05 PM, Sergio Fern�ndez wrote:
>>>
>>> [snip]
>>>> Definitively I used Freemarker much more in the past than currently,
>>>> but Web development has changed a lot, moving more stuff to the
>>>> frontend (10 years ago we didn't have AngularJS).
>>> Yip, that's why I intend to focus on non-Web applications much more in
>>> FM 3. There are some interesting challenges there. One is the common
>>> need for the much smarter handling of white-space. Another is entering
>>> templates in WYSIWYG editors (it has some tricky aspects). Would be
>>> fun to work on those instead of fighting with FM 2 legacy.
>>>
>> +1
>>
>> Most of my involvement is from a user perspective and I really haven't
>> used much template stuff in a while but in the past 4 years have worked
>> with Liferay portal and they use both Velocity and Freemarker and have
>> recently shifted more to Freemarker. So after being out of the template
>> arena for a while, I am back in.
>>
>> My Java skills aren't nearly at the level the rest of the group on this
>> list has but I will try to jump in on the stuff that can fit my skill level.
>>
>> Pete
Re: Graduation issues
Posted by Daniel Dekany <dd...@freemail.hu>.
Hi Pete,
Liferay is one of the more important FM users today, based on the
number of FM questions on StackOverflow that are Liferay related. So
it would be interesting to know what are the top annoyances or other
improvement ideas in that particular environment. Can you tell any?
Wednesday, June 15, 2016, 4:19:18 PM, Pete Helgren wrote:
> On 6/14/2016 12:20 PM, Daniel Dekany wrote:
>> Tuesday, June 14, 2016, 1:55:05 PM, Sergio Fern�ndez wrote:
>>
>> [snip]
>>> Definitively I used Freemarker much more in the past than currently,
>>> but Web development has changed a lot, moving more stuff to the
>>> frontend (10 years ago we didn't have AngularJS).
>> Yip, that's why I intend to focus on non-Web applications much more in
>> FM 3. There are some interesting challenges there. One is the common
>> need for the much smarter handling of white-space. Another is entering
>> templates in WYSIWYG editors (it has some tricky aspects). Would be
>> fun to work on those instead of fighting with FM 2 legacy.
>>
> +1
>
> Most of my involvement is from a user perspective and I really haven't
> used much template stuff in a while but in the past 4 years have worked
> with Liferay portal and they use both Velocity and Freemarker and have
> recently shifted more to Freemarker. So after being out of the template
> arena for a while, I am back in.
>
> My Java skills aren't nearly at the level the rest of the group on this
> list has but I will try to jump in on the stuff that can fit my skill level.
>
> Pete
--
Thanks,
Daniel Dekany
Re: Graduation issues
Posted by Pete Helgren <pe...@valadd.com>.
On 6/14/2016 12:20 PM, Daniel Dekany wrote:
> Tuesday, June 14, 2016, 1:55:05 PM, Sergio Fern�ndez wrote:
>
> [snip]
>> Definitively I used Freemarker much more in the past than currently,
>> but Web development has changed a lot, moving more stuff to the
>> frontend (10 years ago we didn't have AngularJS).
> Yip, that's why I intend to focus on non-Web applications much more in
> FM 3. There are some interesting challenges there. One is the common
> need for the much smarter handling of white-space. Another is entering
> templates in WYSIWYG editors (it has some tricky aspects). Would be
> fun to work on those instead of fighting with FM 2 legacy.
>
+1
Most of my involvement is from a user perspective and I really haven't
used much template stuff in a while but in the past 4 years have worked
with Liferay portal and they use both Velocity and Freemarker and have
recently shifted more to Freemarker. So after being out of the template
arena for a while, I am back in.
My Java skills aren't nearly at the level the rest of the group on this
list has but I will try to jump in on the stuff that can fit my skill level.
Pete
Re: Graduation issues
Posted by Daniel Dekany <dd...@freemail.hu>.
Tuesday, June 14, 2016, 1:55:05 PM, Sergio Fern�ndez wrote:
[snip]
> Definitively I used Freemarker much more in the past than currently,
> but Web development has changed a lot, moving more stuff to the
> frontend (10 years ago we didn't have AngularJS).
Yip, that's why I intend to focus on non-Web applications much more in
FM 3. There are some interesting challenges there. One is the common
need for the much smarter handling of white-space. Another is entering
templates in WYSIWYG editors (it has some tricky aspects). Would be
fun to work on those instead of fighting with FM 2 legacy.
--
Thanks,
Daniel Dekany
Re: Graduation issues
Posted by Sergio Fernández <wi...@apache.org>.
Hi Daniel,
On Mon, Jun 13, 2016 at 9:18 PM, Daniel Dekany <dd...@freemail.hu> wrote:
> I think we can start some discussion about that even now. Or at least
> I will tell what do I think about the state of the project.
>
Great step. Thanks.
The main problem is the number of active developers, which is 1, me.
>
I'm aware...
https://github.com/apache/incubator-freemarker/graphs/contributors?from=2015-07-01&type=c
> What if I'm hit by a truck tomorrow? We can hope that if there's a bug
> that concerns many, then someone will eventually fix it. After all the
> owner (ASF) won't be gone, the release infrastructure is there, etc.
> But as far as non-bugfix development goes, it's certain that things
> would stop. Some may say that that's OK for a project that's
> backward-compatibility-locked for 12 years now (the 2.x line is
> actually 14 years old).
Well, I'd say that's critical, but the community of a project is more than
the developers who code. And the Freemarker community is much bigger than
what you could think.
For instance if you consider my personal case: I volunteered for mentor
because I knew the project for so long. I even code some extensions (
http://marmotta.apache.org/ldpath/template.html). Definitively I used
Freemarker much more in the past than currently, but Web development has
changed a lot, moving more stuff to the frontend (10 years ago we didn't
have AngularJS).
So I'd say there are many people like me out there, using every day
solutions based on Freemarker. People who are not that close to the source
base, but familiar enough to be able to jump in at any time a provide a
patch.
> But of course that's just slow death if a
> project can't counter its old design problems and can't evolve to
> tackle new problems anymore. So indeed 2.x should switch to
> maintenance eventually (but ATM there are still things that can be
> done in 2.x), but only to give place for 3.x. Anyway, how to catch
> long standing developers? I don't think that 2.x have a real chance
> for that, because of all the legacy code burden piled up. (Some Apache
> projects have many paid contributors, but I think FM isn't the kind of
> project that can have that, so it's important that the developers want
> to fiddle with it for free.) So the 3.x jump will be necessary, and
> then, maybe, we can have a developer base growth (template engines
> isn't hot topic anymore, so I just mean having a few developers
> around). But 3.x is far away (if it will happen at all), and we can't
> hang around in the incubator forever.
Well, we can consider 2.3.x feature-complete, and 2.3.25-incubating a
maintenance release. The world has change a lot in template business in
these 14 years. But I'm pretty sure FreeMarker has its place there, and 3.x
could bring some many great ideas that may attract potential new
contributors. And that's what I see as future of this project.
> So, do you believe there's any chance to graduate with the current
> developer base?
>
Definitively that has been always the major issue with this podling.
Honestly I'm not sure. But following with all my argumentation that the
community is much bigger that what shows the development team, I'd say
could be at least discussed with the IPMC.
Looking forward to hear every body else's opinions.
Cheers,
--
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 6602747925
e: sergio.fernandez@redlink.co
w: http://redlink.co
Re: FM Online improvements
Posted by Daniel Dekany <dd...@apache.org>.
Any hope that you will continue work on this? (Now that we have the
try.freemarker.org at ASF, anything you do can be deployed pretty much
immediately.)
Thursday, August 18, 2016, 8:00:40 PM, Daniel Dekany wrote:
> Thursday, August 18, 2016, 9:11:34 AM, Pradeep Murugesan wrote:
>
>> Hey Daniel,
>>
>> I have made the changes you have mentioned in the UI side. Yet
>> a quick question, You have mentioned auto import shouldn't be a
>> checkbox. But you have mentioned like
>> "[name ] [ ] Auto import [ ] Auto include" .
>>
>> We should have it as text box right ?
>
> Right, only a text box, no checkbox is needed for auto-import.
> Something like:
>
> Auto import [prefix ] [ ] Auto include
>
>> Regarding the Configuration , I see that we have a freeMarkerConfig
>> (instance of Configuration) and we actually build a Template and
>> TemplateConfiguration and is attached to the freemarkerConfig.
>>
>> Now in case of additional templates, If we create a Template (with
>> name) and TemplateConfiguration for each and attach to the
>> freeMarkerConfig (main configuration).
>
> For now we have no reason to use separate TemplateConfiguration-s, as
> there are no UI controls to set any pre-template settings. What we
> will need is a separate Configuration for each request when(!) there
> are additional templates. That's because the TemplateLoader and
> template cache exists on the Configuration level, and each request
> will have a different set of additional templates.
>
>> Let me know if I am getting it wrong.
>>
>> Pradeep.
>>
>>
>>
>> From: Daniel Dekany <dd...@freemail.hu>
>> Sent: Wednesday, August 3, 2016 2:22 AM
>> To: Pradeep Murugesan
>> Subject: Re: FM Online improvements (Was: Graduation issues)
>>
>> Tuesday, August 2, 2016, 2:39:45 PM, Pradeep Murugesan wrote:
>>
>>>
>>> Hi Daniel,
>>>
>>> Got the client side changes and have pushed @
>>> https://github.com/pradeepmurugesan/freemarker-online/tree/additionalTemplates.
>>>
>>> Attached the screenshot of how it will look . Kindly let me know if there are any changes.
>>
>> I have just realized that auto-import shouldn't be a checkbox but a
>> text imput, as you have to specify the import prefix...
>>
>> Now that I see it with 2 additional templates, I think the "+" button
>> has some usability disadvantages. People expect the new template to
>> appear after the last template (as opposed to be inserted before the
>> first one). But the "+" button is always at top. So it would be better
>> after the last template. But then it's not entirely obvious what it
>> adds. So, how about having only this under the main template textarea
>> (note that there's no "Addition templates" title):
>>
>> [Add template] to #import/#include
>>
>> where [Add template] is a button, and the text after it is a gray
>> hint. Now if someone adds a template, you will have:
>>
>> Template to #import/#include:
>> [name ] [ ] Auto import [ ] Auto include
>> [Enter template, like <#macro greet name>Hello ${name}!</#macro>]
>>
>> [Add template] to #import/#include
>>
>> So as you can see, the the [Add template] button will be always at the
>> bottom, where the new template will be added if you press it. (If
>> someone adds multiple templates, there will be a "Template to
>> #import/#include:" label before each.)
>>
>> Note that I have also changed the textarea example text.
>>
>>
>>> I am going through the server side requirements/changes that needs
>>> to be done. Will come back once I have my questions ready.
>>
>> One tricky thing will be that FM-Online uses a shared singleton
>> Configuration currently, but the additional templates are named, so
>> the Configuration need to be aware of them. I guess the best will be
>> just creating a new drop-away Configuration instance in case there are
>> additional templates. (The other alternative is using a TLS-aware
>> TemplateChache, but that's probably too tricky for sparing those CPU
>> cycles.) (Yet another alternative is supporting Environment-local
>> named templates in FM 2.3.26... but that's the hardest of all.)
>>
>>> Pradeep.
>>>
>>>
>>>
>>> From: Daniel Dekany <dd...@freemail.hu>
>>> Sent: Tuesday, August 2, 2016 1:39:01 AM
>>> To: Pradeep Murugesan
>>> Subject: Re: FM Online improvements (Was: Graduation issues)
>>>
>>> Monday, August 1, 2016, 6:11:37 PM, Pradeep Murugesan wrote:
>>>
>>>> Hi Daniel,
>>>>
>>>> Got a chance to work on the task. I have come up with something
>>>> here http://codepen.io/pradeepmurugesan/pen/oLPNgQ.
>>>
>>> Looks fine.
>>>
>>>> I have the following questions.
>>>>
>>>> 1. The pure css used by the online validator is pretty old . Do we
>>>> have any idea to replace the same with the latest version of
>>>> pure(http://purecss.io/) or bootstrap.
>>>
>>> You can update Pure if you want to, or use Bootstrap CSS... I don't
>>> know either. If you have experience with them, I will trust your
>>> judgement.
>>>
>>>> 2. How many such template can the user add. like can he keep on
>>>> adding it or we are going to put any restrictions there.
>>>
>>> To keep users from killing the server, let's say, the main template
>>> plus at most 3 importable/includable templates.
>>>
>>>> Kindly let me know any changes in the pen and also answer to the above.
>>>>
>>>> Pradeep.
>>>>
>>>> From: Daniel Dekany <dd...@freemail.hu>
>>>> Sent: Monday, June 27, 2016 11:59:34 AM
>>>> To: Daniel Dekany
>>>> Subject: Re: FM Online improvements (Was: Graduation issues)
>>>>
>>>> Monday, June 27, 2016, 8:24:21 AM, Daniel Dekany wrote:
>>>>
>>>>> I should
>>>>
>>>> I meant "It should".
>>>>
>>>>> support adding arbitrary templates. As I imagine it, there
>>>>> would be an "Add template" button, and when you press it, it adds an
>>>>> extra text area, which has a template name input, an "auto import"
>>>>> checkbox, and an "auto include" checkbox, and a "Remove template"
>>>>> button over it.
>>>>
>>>> Another thing... we should add an "Incompatible improvements" dropdown
>>>> after the existing ones, which preselects the value of
>>>> Configuration.getVersion().
>>>>
>>>>
>>>>> Monday, June 27, 2016, 7:24:19 AM, Pradeep Murugesan wrote:
>>>>>
>>>>>> Hi Daniel,
>>>>>>
>>>>>>
>>>>>> Cool.. I will start with adding the extra template name thing to
>>>>>> the online template tester. (#import and #include) . I would need
>>>>>> more pointers on the same. How have you visualised the same.
>>>>>> Meaning , How the users can import other templates, we will give
>>>>>> provision to add other templates or we have some predefined
>>>>>> templates loaded , so that they can import the same ?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Pradeep.
>>>>>>
>>>>>> ________________________________
>>>>>> From: Daniel Dekany <dd...@freemail.hu>
>>>>>> Sent: Tuesday, June 14, 2016 11:02:38 PM
>>>>>> To: Pradeep Murugesan
>>>>>> Cc: dev@freemarker.incubator.apache.org
>>>>>> Subject: Re: Graduation issues
>>>>>>
>>>>>> Happy to see you back!
>>>>>>
>>>>>> There are things to do, of course.
>>>>>>
>>>>>> I haven't yet merged in your contribution with XML siblings (so it
>>>>>> won't be in 2.3.25 - sorry about that, next time), and AFAIR there
>>>>>> were some wrinkles to work on.
>>>>>>
>>>>>> I have done some of the planned improvements on
>>>>>> http://freemarker-online.kenshoo.com/ (mostly to draw attention to the
>>>>>> outputFormat setting of 2.3.24), but there are other things to do.
>>>>>> Apart from what was discussed earlier, I think supporting adding extra
>>>>>> templates with names would be handy, because then people can play
>>>>>> around with #import and #include.
>>>>>>
>>>>>> And then of course, there's http://freemarker.org/contribute.html with
>>>>>> even more things to do.
>>>>>>
>>>>>>
>>>>>> Tuesday, June 14, 2016, 12:27:01 PM, Pradeep Murugesan wrote:
>>>>>>
>>>>>>> Hi Daniel & team,
>>>>>>>
>>>>>>>
>>>>>>> Sorry that I was dormant for a long time after a very short tent
>>>>>>> @ Freemaker. I am out of some critical issues and have some bandwidth from now on.
>>>>>>>
>>>>>>>
>>>>>>> Kindly let me know if there is anything I could help.
>>>>>>>
>>>>>>>
>>>>>>> Pradeep.
>>>>>>>
>>>>>>> ________________________________
>>>>>>> From: Daniel Dekany <dd...@freemail.hu>
>>>>>>> Sent: Tuesday, June 14, 2016 12:48:55 AM
>>>>>>> To: Sergio Fernández
>>>>>>> Cc: dev@freemarker.incubator.apache.org
>>>>>>> Subject: Graduation issues
>>>>>>>
>>>>>>> I think we can start some discussion about that even now. Or at least
>>>>>>> I will tell what do I think about the state of the project.
>>>>>>>
>>>>>>> The main problem is the number of active developers, which is 1, me.
>>>>>>> What if I'm hit by a truck tomorrow? We can hope that if there's a bug
>>>>>>> that concerns many, then someone will eventually fix it. After all the
>>>>>>> owner (ASF) won't be gone, the release infrastructure is there, etc.
>>>>>>> But as far as non-bugfix development goes, it's certain that things
>>>>>>> would stop. Some may say that that's OK for a project that's
>>>>>>> backward-compatibility-locked for 12 years now (the 2.x line is
>>>>>>> actually 14 years old). But of course that's just slow death if a
>>>>>>> project can't counter its old design problems and can't evolve to
>>>>>>> tackle new problems anymore. So indeed 2.x should switch to
>>>>>>> maintenance eventually (but ATM there are still things that can be
>>>>>>> done in 2.x), but only to give place for 3.x. Anyway, how to catch
>>>>>>> long standing developers? I don't think that 2.x have a real chance
>>>>>>> for that, because of all the legacy code burden piled up. (Some Apache
>>>>>>> projects have many paid contributors, but I think FM isn't the kind of
>>>>>>> project that can have that, so it's important that the developers want
>>>>>>> to fiddle with it for free.) So the 3.x jump will be necessary, and
>>>>>>> then, maybe, we can have a developer base growth (template engines
>>>>>>> isn't hot topic anymore, so I just mean having a few developers
>>>>>>> around). But 3.x is far away (if it will happen at all), and we can't
>>>>>>> hang around in the incubator forever. So, do you believe there's any
>>>>>>> chance to graduate with the current developer base?
>>>>>>>
>>>>>>>
>>>>>>> Monday, June 13, 2016, 8:15:11 AM, Sergio Fernández wrote:
>>>>>>>
>>>>>>>> Besides the technical discussion for 2.3.25-incubating, after that release
>>>>>>>> you may start to discuss a possible graduation. We have to discuss many
>>>>>>>> aspects (specially growth of the community), but technically speaking the
>>>>>>>> podling is capable os casting releases.
>>>>>>>
>>>>>>> --
>>>>>>> Thanks,
>>>>>>> Daniel Dekany
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Thanks,
>>>>>> Daniel Dekany
>>>>>>
>>>>>
>>>>
>>>
>>
>
--
Thanks,
Daniel Dekany
Re: FM Online improvements (Was: Graduation issues)
Posted by Daniel Dekany <dd...@freemail.hu>.
Thursday, August 18, 2016, 9:11:34 AM, Pradeep Murugesan wrote:
> Hey Daniel,
>
> I have made the changes you have mentioned in the UI side. Yet
> a quick question, You have mentioned auto import shouldn't be a
> checkbox. But you have mentioned like
> "[name ] [ ] Auto import [ ] Auto include" .
>
> We should have it as text box right ?
Right, only a text box, no checkbox is needed for auto-import.
Something like:
Auto import [prefix ] [ ] Auto include
> Regarding the Configuration , I see that we have a freeMarkerConfig
> (instance of Configuration) and we actually build a Template and
> TemplateConfiguration and is attached to the freemarkerConfig.
>
> Now in case of additional templates, If we create a Template (with
> name) and TemplateConfiguration for each and attach to the
> freeMarkerConfig (main configuration).
For now we have no reason to use separate TemplateConfiguration-s, as
there are no UI controls to set any pre-template settings. What we
will need is a separate Configuration for each request when(!) there
are additional templates. That's because the TemplateLoader and
template cache exists on the Configuration level, and each request
will have a different set of additional templates.
> Let me know if I am getting it wrong.
>
> Pradeep.
>
>
>
> From: Daniel Dekany <dd...@freemail.hu>
> Sent: Wednesday, August 3, 2016 2:22 AM
> To: Pradeep Murugesan
> Subject: Re: FM Online improvements (Was: Graduation issues)
>
> Tuesday, August 2, 2016, 2:39:45 PM, Pradeep Murugesan wrote:
>
>>
>> Hi Daniel,
>>
>> Got the client side changes and have pushed @
>> https://github.com/pradeepmurugesan/freemarker-online/tree/additionalTemplates.
>>
>> Attached the screenshot of how it will look . Kindly let me know if there are any changes.
>
> I have just realized that auto-import shouldn't be a checkbox but a
> text imput, as you have to specify the import prefix...
>
> Now that I see it with 2 additional templates, I think the "+" button
> has some usability disadvantages. People expect the new template to
> appear after the last template (as opposed to be inserted before the
> first one). But the "+" button is always at top. So it would be better
> after the last template. But then it's not entirely obvious what it
> adds. So, how about having only this under the main template textarea
> (note that there's no "Addition templates" title):
>
> [Add template] to #import/#include
>
> where [Add template] is a button, and the text after it is a gray
> hint. Now if someone adds a template, you will have:
>
> Template to #import/#include:
> [name ] [ ] Auto import [ ] Auto include
> [Enter template, like <#macro greet name>Hello ${name}!</#macro>]
>
> [Add template] to #import/#include
>
> So as you can see, the the [Add template] button will be always at the
> bottom, where the new template will be added if you press it. (If
> someone adds multiple templates, there will be a "Template to
> #import/#include:" label before each.)
>
> Note that I have also changed the textarea example text.
>
>
>> I am going through the server side requirements/changes that needs
>> to be done. Will come back once I have my questions ready.
>
> One tricky thing will be that FM-Online uses a shared singleton
> Configuration currently, but the additional templates are named, so
> the Configuration need to be aware of them. I guess the best will be
> just creating a new drop-away Configuration instance in case there are
> additional templates. (The other alternative is using a TLS-aware
> TemplateChache, but that's probably too tricky for sparing those CPU
> cycles.) (Yet another alternative is supporting Environment-local
> named templates in FM 2.3.26... but that's the hardest of all.)
>
>> Pradeep.
>>
>>
>>
>> From: Daniel Dekany <dd...@freemail.hu>
>> Sent: Tuesday, August 2, 2016 1:39:01 AM
>> To: Pradeep Murugesan
>> Subject: Re: FM Online improvements (Was: Graduation issues)
>>
>> Monday, August 1, 2016, 6:11:37 PM, Pradeep Murugesan wrote:
>>
>>> Hi Daniel,
>>>
>>> Got a chance to work on the task. I have come up with something
>>> here http://codepen.io/pradeepmurugesan/pen/oLPNgQ.
>>
>> Looks fine.
>>
>>> I have the following questions.
>>>
>>> 1. The pure css used by the online validator is pretty old . Do we
>>> have any idea to replace the same with the latest version of
>>> pure(http://purecss.io/) or bootstrap.
>>
>> You can update Pure if you want to, or use Bootstrap CSS... I don't
>> know either. If you have experience with them, I will trust your
>> judgement.
>>
>>> 2. How many such template can the user add. like can he keep on
>>> adding it or we are going to put any restrictions there.
>>
>> To keep users from killing the server, let's say, the main template
>> plus at most 3 importable/includable templates.
>>
>>> Kindly let me know any changes in the pen and also answer to the above.
>>>
>>> Pradeep.
>>>
>>> From: Daniel Dekany <dd...@freemail.hu>
>>> Sent: Monday, June 27, 2016 11:59:34 AM
>>> To: Daniel Dekany
>>> Subject: Re: FM Online improvements (Was: Graduation issues)
>>>
>>> Monday, June 27, 2016, 8:24:21 AM, Daniel Dekany wrote:
>>>
>>>> I should
>>>
>>> I meant "It should".
>>>
>>>> support adding arbitrary templates. As I imagine it, there
>>>> would be an "Add template" button, and when you press it, it adds an
>>>> extra text area, which has a template name input, an "auto import"
>>>> checkbox, and an "auto include" checkbox, and a "Remove template"
>>>> button over it.
>>>
>>> Another thing... we should add an "Incompatible improvements" dropdown
>>> after the existing ones, which preselects the value of
>>> Configuration.getVersion().
>>>
>>>
>>>> Monday, June 27, 2016, 7:24:19 AM, Pradeep Murugesan wrote:
>>>>
>>>>> Hi Daniel,
>>>>>
>>>>>
>>>>> Cool.. I will start with adding the extra template name thing to
>>>>> the online template tester. (#import and #include) . I would need
>>>>> more pointers on the same. How have you visualised the same.
>>>>> Meaning , How the users can import other templates, we will give
>>>>> provision to add other templates or we have some predefined
>>>>> templates loaded , so that they can import the same ?
>>>>>
>>>>>
>>>>>
>>>>> Pradeep.
>>>>>
>>>>> ________________________________
>>>>> From: Daniel Dekany <dd...@freemail.hu>
>>>>> Sent: Tuesday, June 14, 2016 11:02:38 PM
>>>>> To: Pradeep Murugesan
>>>>> Cc: dev@freemarker.incubator.apache.org
>>>>> Subject: Re: Graduation issues
>>>>>
>>>>> Happy to see you back!
>>>>>
>>>>> There are things to do, of course.
>>>>>
>>>>> I haven't yet merged in your contribution with XML siblings (so it
>>>>> won't be in 2.3.25 - sorry about that, next time), and AFAIR there
>>>>> were some wrinkles to work on.
>>>>>
>>>>> I have done some of the planned improvements on
>>>>> http://freemarker-online.kenshoo.com/ (mostly to draw attention to the
>>>>> outputFormat setting of 2.3.24), but there are other things to do.
>>>>> Apart from what was discussed earlier, I think supporting adding extra
>>>>> templates with names would be handy, because then people can play
>>>>> around with #import and #include.
>>>>>
>>>>> And then of course, there's http://freemarker.org/contribute.html with
>>>>> even more things to do.
>>>>>
>>>>>
>>>>> Tuesday, June 14, 2016, 12:27:01 PM, Pradeep Murugesan wrote:
>>>>>
>>>>>> Hi Daniel & team,
>>>>>>
>>>>>>
>>>>>> Sorry that I was dormant for a long time after a very short tent
>>>>>> @ Freemaker. I am out of some critical issues and have some bandwidth from now on.
>>>>>>
>>>>>>
>>>>>> Kindly let me know if there is anything I could help.
>>>>>>
>>>>>>
>>>>>> Pradeep.
>>>>>>
>>>>>> ________________________________
>>>>>> From: Daniel Dekany <dd...@freemail.hu>
>>>>>> Sent: Tuesday, June 14, 2016 12:48:55 AM
>>>>>> To: Sergio Fernndez
>>>>>> Cc: dev@freemarker.incubator.apache.org
>>>>>> Subject: Graduation issues
>>>>>>
>>>>>> I think we can start some discussion about that even now. Or at least
>>>>>> I will tell what do I think about the state of the project.
>>>>>>
>>>>>> The main problem is the number of active developers, which is 1, me.
>>>>>> What if I'm hit by a truck tomorrow? We can hope that if there's a bug
>>>>>> that concerns many, then someone will eventually fix it. After all the
>>>>>> owner (ASF) won't be gone, the release infrastructure is there, etc.
>>>>>> But as far as non-bugfix development goes, it's certain that things
>>>>>> would stop. Some may say that that's OK for a project that's
>>>>>> backward-compatibility-locked for 12 years now (the 2.x line is
>>>>>> actually 14 years old). But of course that's just slow death if a
>>>>>> project can't counter its old design problems and can't evolve to
>>>>>> tackle new problems anymore. So indeed 2.x should switch to
>>>>>> maintenance eventually (but ATM there are still things that can be
>>>>>> done in 2.x), but only to give place for 3.x. Anyway, how to catch
>>>>>> long standing developers? I don't think that 2.x have a real chance
>>>>>> for that, because of all the legacy code burden piled up. (Some Apache
>>>>>> projects have many paid contributors, but I think FM isn't the kind of
>>>>>> project that can have that, so it's important that the developers want
>>>>>> to fiddle with it for free.) So the 3.x jump will be necessary, and
>>>>>> then, maybe, we can have a developer base growth (template engines
>>>>>> isn't hot topic anymore, so I just mean having a few developers
>>>>>> around). But 3.x is far away (if it will happen at all), and we can't
>>>>>> hang around in the incubator forever. So, do you believe there's any
>>>>>> chance to graduate with the current developer base?
>>>>>>
>>>>>>
>>>>>> Monday, June 13, 2016, 8:15:11 AM, Sergio Fernndez wrote:
>>>>>>
>>>>>>> Besides the technical discussion for 2.3.25-incubating, after that release
>>>>>>> you may start to discuss a possible graduation. We have to discuss many
>>>>>>> aspects (specially growth of the community), but technically speaking the
>>>>>>> podling is capable os casting releases.
>>>>>>
>>>>>> --
>>>>>> Thanks,
>>>>>> Daniel Dekany
>>>>>>
>>>>>
>>>>> --
>>>>> Thanks,
>>>>> Daniel Dekany
>>>>>
>>>>
>>>
>>
>
--
Thanks,
Daniel Dekany
Re: FM Online improvements (Was: Graduation issues)
Posted by Pradeep Murugesan <pr...@outlook.com>.
Hey Daniel,
I have made the changes you have mentioned in the UI side. Yet a quick question, You have mentioned auto import shouldn't be a checkbox. But you have mentioned like
"[name ] [ ] Auto import [ ] Auto include" .
We should have it as text box right ?
Regarding the Configuration , I see that we have a freeMarkerConfig (instance of Configuration) and we actually build a Template and TemplateConfiguration and is attached to the freemarkerConfig.
Now in case of additional templates, If we create a Template (with name) and TemplateConfiguration for each and attach to the freeMarkerConfig (main configuration).
Let me know if I am getting it wrong.
Pradeep.
________________________________
From: Daniel Dekany <dd...@freemail.hu>
Sent: Wednesday, August 3, 2016 2:22 AM
To: Pradeep Murugesan
Subject: Re: FM Online improvements (Was: Graduation issues)
Tuesday, August 2, 2016, 2:39:45 PM, Pradeep Murugesan wrote:
>
> Hi Daniel,
>
> Got the client side changes and have pushed @
> https://github.com/pradeepmurugesan/freemarker-online/tree/additionalTemplates.
>
> Attached the screenshot of how it will look . Kindly let me know if there are any changes.
I have just realized that auto-import shouldn't be a checkbox but a
text imput, as you have to specify the import prefix...
Now that I see it with 2 additional templates, I think the "+" button
has some usability disadvantages. People expect the new template to
appear after the last template (as opposed to be inserted before the
first one). But the "+" button is always at top. So it would be better
after the last template. But then it's not entirely obvious what it
adds. So, how about having only this under the main template textarea
(note that there's no "Addition templates" title):
[Add template] to #import/#include
where [Add template] is a button, and the text after it is a gray
hint. Now if someone adds a template, you will have:
Template to #import/#include:
[name ] [ ] Auto import [ ] Auto include
[Enter template, like <#macro greet name>Hello ${name}!</#macro>]
[Add template] to #import/#include
So as you can see, the the [Add template] button will be always at the
bottom, where the new template will be added if you press it. (If
someone adds multiple templates, there will be a "Template to
#import/#include:" label before each.)
Note that I have also changed the textarea example text.
> I am going through the server side requirements/changes that needs
> to be done. Will come back once I have my questions ready.
One tricky thing will be that FM-Online uses a shared singleton
Configuration currently, but the additional templates are named, so
the Configuration need to be aware of them. I guess the best will be
just creating a new drop-away Configuration instance in case there are
additional templates. (The other alternative is using a TLS-aware
TemplateChache, but that's probably too tricky for sparing those CPU
cycles.) (Yet another alternative is supporting Environment-local
named templates in FM 2.3.26... but that's the hardest of all.)
> Pradeep.
>
>
>
> From: Daniel Dekany <dd...@freemail.hu>
> Sent: Tuesday, August 2, 2016 1:39:01 AM
> To: Pradeep Murugesan
> Subject: Re: FM Online improvements (Was: Graduation issues)
>
> Monday, August 1, 2016, 6:11:37 PM, Pradeep Murugesan wrote:
>
>> Hi Daniel,
>>
>> Got a chance to work on the task. I have come up with something
>> here http://codepen.io/pradeepmurugesan/pen/oLPNgQ.
>
> Looks fine.
>
>> I have the following questions.
>>
>> 1. The pure css used by the online validator is pretty old . Do we
>> have any idea to replace the same with the latest version of
>> pure(http://purecss.io/) or bootstrap.
>
> You can update Pure if you want to, or use Bootstrap CSS... I don't
> know either. If you have experience with them, I will trust your
> judgement.
>
>> 2. How many such template can the user add. like can he keep on
>> adding it or we are going to put any restrictions there.
>
> To keep users from killing the server, let's say, the main template
> plus at most 3 importable/includable templates.
>
>> Kindly let me know any changes in the pen and also answer to the above.
>>
>> Pradeep.
>>
>> From: Daniel Dekany <dd...@freemail.hu>
>> Sent: Monday, June 27, 2016 11:59:34 AM
>> To: Daniel Dekany
>> Subject: Re: FM Online improvements (Was: Graduation issues)
>>
>> Monday, June 27, 2016, 8:24:21 AM, Daniel Dekany wrote:
>>
>>> I should
>>
>> I meant "It should".
>>
>>> support adding arbitrary templates. As I imagine it, there
>>> would be an "Add template" button, and when you press it, it adds an
>>> extra text area, which has a template name input, an "auto import"
>>> checkbox, and an "auto include" checkbox, and a "Remove template"
>>> button over it.
>>
>> Another thing... we should add an "Incompatible improvements" dropdown
>> after the existing ones, which preselects the value of
>> Configuration.getVersion().
>>
>>
>>> Monday, June 27, 2016, 7:24:19 AM, Pradeep Murugesan wrote:
>>>
>>>> Hi Daniel,
>>>>
>>>>
>>>> Cool.. I will start with adding the extra template name thing to
>>>> the online template tester. (#import and #include) . I would need
>>>> more pointers on the same. How have you visualised the same.
>>>> Meaning , How the users can import other templates, we will give
>>>> provision to add other templates or we have some predefined
>>>> templates loaded , so that they can import the same ?
>>>>
>>>>
>>>>
>>>> Pradeep.
>>>>
>>>> ________________________________
>>>> From: Daniel Dekany <dd...@freemail.hu>
>>>> Sent: Tuesday, June 14, 2016 11:02:38 PM
>>>> To: Pradeep Murugesan
>>>> Cc: dev@freemarker.incubator.apache.org
>>>> Subject: Re: Graduation issues
>>>>
>>>> Happy to see you back!
>>>>
>>>> There are things to do, of course.
>>>>
>>>> I haven't yet merged in your contribution with XML siblings (so it
>>>> won't be in 2.3.25 - sorry about that, next time), and AFAIR there
>>>> were some wrinkles to work on.
>>>>
>>>> I have done some of the planned improvements on
>>>> http://freemarker-online.kenshoo.com/ (mostly to draw attention to the
>>>> outputFormat setting of 2.3.24), but there are other things to do.
>>>> Apart from what was discussed earlier, I think supporting adding extra
>>>> templates with names would be handy, because then people can play
>>>> around with #import and #include.
>>>>
>>>> And then of course, there's http://freemarker.org/contribute.html with
>>>> even more things to do.
>>>>
>>>>
>>>> Tuesday, June 14, 2016, 12:27:01 PM, Pradeep Murugesan wrote:
>>>>
>>>>> Hi Daniel & team,
>>>>>
>>>>>
>>>>> Sorry that I was dormant for a long time after a very short tent
>>>>> @ Freemaker. I am out of some critical issues and have some bandwidth from now on.
>>>>>
>>>>>
>>>>> Kindly let me know if there is anything I could help.
>>>>>
>>>>>
>>>>> Pradeep.
>>>>>
>>>>> ________________________________
>>>>> From: Daniel Dekany <dd...@freemail.hu>
>>>>> Sent: Tuesday, June 14, 2016 12:48:55 AM
>>>>> To: Sergio Fernández
>>>>> Cc: dev@freemarker.incubator.apache.org
>>>>> Subject: Graduation issues
>>>>>
>>>>> I think we can start some discussion about that even now. Or at least
>>>>> I will tell what do I think about the state of the project.
>>>>>
>>>>> The main problem is the number of active developers, which is 1, me.
>>>>> What if I'm hit by a truck tomorrow? We can hope that if there's a bug
>>>>> that concerns many, then someone will eventually fix it. After all the
>>>>> owner (ASF) won't be gone, the release infrastructure is there, etc.
>>>>> But as far as non-bugfix development goes, it's certain that things
>>>>> would stop. Some may say that that's OK for a project that's
>>>>> backward-compatibility-locked for 12 years now (the 2.x line is
>>>>> actually 14 years old). But of course that's just slow death if a
>>>>> project can't counter its old design problems and can't evolve to
>>>>> tackle new problems anymore. So indeed 2.x should switch to
>>>>> maintenance eventually (but ATM there are still things that can be
>>>>> done in 2.x), but only to give place for 3.x. Anyway, how to catch
>>>>> long standing developers? I don't think that 2.x have a real chance
>>>>> for that, because of all the legacy code burden piled up. (Some Apache
>>>>> projects have many paid contributors, but I think FM isn't the kind of
>>>>> project that can have that, so it's important that the developers want
>>>>> to fiddle with it for free.) So the 3.x jump will be necessary, and
>>>>> then, maybe, we can have a developer base growth (template engines
>>>>> isn't hot topic anymore, so I just mean having a few developers
>>>>> around). But 3.x is far away (if it will happen at all), and we can't
>>>>> hang around in the incubator forever. So, do you believe there's any
>>>>> chance to graduate with the current developer base?
>>>>>
>>>>>
>>>>> Monday, June 13, 2016, 8:15:11 AM, Sergio Fernández wrote:
>>>>>
>>>>>> Besides the technical discussion for 2.3.25-incubating, after that release
>>>>>> you may start to discuss a possible graduation. We have to discuss many
>>>>>> aspects (specially growth of the community), but technically speaking the
>>>>>> podling is capable os casting releases.
>>>>>
>>>>> --
>>>>> Thanks,
>>>>> Daniel Dekany
>>>>>
>>>>
>>>> --
>>>> Thanks,
>>>> Daniel Dekany
>>>>
>>>
>>
>
--
Thanks,
Daniel Dekany
Re: FM Online improvements (Was: Graduation issues)
Posted by Daniel Dekany <dd...@freemail.hu>.
Tuesday, August 2, 2016, 2:39:45 PM, Pradeep Murugesan wrote:
>
> Hi Daniel,
>
> Got the client side changes and have pushed @
> https://github.com/pradeepmurugesan/freemarker-online/tree/additionalTemplates.
>
> Attached the screenshot of how it will look . Kindly let me know if there are any changes.
I have just realized that auto-import shouldn't be a checkbox but a
text imput, as you have to specify the import prefix...
Now that I see it with 2 additional templates, I think the "+" button
has some usability disadvantages. People expect the new template to
appear after the last template (as opposed to be inserted before the
first one). But the "+" button is always at top. So it would be better
after the last template. But then it's not entirely obvious what it
adds. So, how about having only this under the main template textarea
(note that there's no "Addition templates" title):
[Add template] to #import/#include
where [Add template] is a button, and the text after it is a gray
hint. Now if someone adds a template, you will have:
Template to #import/#include:
[name ] [ ] Auto import [ ] Auto include
[Enter template, like <#macro greet name>Hello ${name}!</#macro>]
[Add template] to #import/#include
So as you can see, the the [Add template] button will be always at the
bottom, where the new template will be added if you press it. (If
someone adds multiple templates, there will be a "Template to
#import/#include:" label before each.)
Note that I have also changed the textarea example text.
> I am going through the server side requirements/changes that needs
> to be done. Will come back once I have my questions ready.
One tricky thing will be that FM-Online uses a shared singleton
Configuration currently, but the additional templates are named, so
the Configuration need to be aware of them. I guess the best will be
just creating a new drop-away Configuration instance in case there are
additional templates. (The other alternative is using a TLS-aware
TemplateChache, but that's probably too tricky for sparing those CPU
cycles.) (Yet another alternative is supporting Environment-local
named templates in FM 2.3.26... but that's the hardest of all.)
> Pradeep.
>
>
>
> From: Daniel Dekany <dd...@freemail.hu>
> Sent: Tuesday, August 2, 2016 1:39:01 AM
> To: Pradeep Murugesan
> Subject: Re: FM Online improvements (Was: Graduation issues)
>
> Monday, August 1, 2016, 6:11:37 PM, Pradeep Murugesan wrote:
>
>> Hi Daniel,
>>
>> Got a chance to work on the task. I have come up with something
>> here http://codepen.io/pradeepmurugesan/pen/oLPNgQ.
>
> Looks fine.
>
>> I have the following questions.
>>
>> 1. The pure css used by the online validator is pretty old . Do we
>> have any idea to replace the same with the latest version of
>> pure(http://purecss.io/) or bootstrap.
>
> You can update Pure if you want to, or use Bootstrap CSS... I don't
> know either. If you have experience with them, I will trust your
> judgement.
>
>> 2. How many such template can the user add. like can he keep on
>> adding it or we are going to put any restrictions there.
>
> To keep users from killing the server, let's say, the main template
> plus at most 3 importable/includable templates.
>
>> Kindly let me know any changes in the pen and also answer to the above.
>>
>> Pradeep.
>>
>> From: Daniel Dekany <dd...@freemail.hu>
>> Sent: Monday, June 27, 2016 11:59:34 AM
>> To: Daniel Dekany
>> Subject: Re: FM Online improvements (Was: Graduation issues)
>>
>> Monday, June 27, 2016, 8:24:21 AM, Daniel Dekany wrote:
>>
>>> I should
>>
>> I meant "It should".
>>
>>> support adding arbitrary templates. As I imagine it, there
>>> would be an "Add template" button, and when you press it, it adds an
>>> extra text area, which has a template name input, an "auto import"
>>> checkbox, and an "auto include" checkbox, and a "Remove template"
>>> button over it.
>>
>> Another thing... we should add an "Incompatible improvements" dropdown
>> after the existing ones, which preselects the value of
>> Configuration.getVersion().
>>
>>
>>> Monday, June 27, 2016, 7:24:19 AM, Pradeep Murugesan wrote:
>>>
>>>> Hi Daniel,
>>>>
>>>>
>>>> Cool.. I will start with adding the extra template name thing to
>>>> the online template tester. (#import and #include) . I would need
>>>> more pointers on the same. How have you visualised the same.
>>>> Meaning , How the users can import other templates, we will give
>>>> provision to add other templates or we have some predefined
>>>> templates loaded , so that they can import the same ?
>>>>
>>>>
>>>>
>>>> Pradeep.
>>>>
>>>> ________________________________
>>>> From: Daniel Dekany <dd...@freemail.hu>
>>>> Sent: Tuesday, June 14, 2016 11:02:38 PM
>>>> To: Pradeep Murugesan
>>>> Cc: dev@freemarker.incubator.apache.org
>>>> Subject: Re: Graduation issues
>>>>
>>>> Happy to see you back!
>>>>
>>>> There are things to do, of course.
>>>>
>>>> I haven't yet merged in your contribution with XML siblings (so it
>>>> won't be in 2.3.25 - sorry about that, next time), and AFAIR there
>>>> were some wrinkles to work on.
>>>>
>>>> I have done some of the planned improvements on
>>>> http://freemarker-online.kenshoo.com/ (mostly to draw attention to the
>>>> outputFormat setting of 2.3.24), but there are other things to do.
>>>> Apart from what was discussed earlier, I think supporting adding extra
>>>> templates with names would be handy, because then people can play
>>>> around with #import and #include.
>>>>
>>>> And then of course, there's http://freemarker.org/contribute.html with
>>>> even more things to do.
>>>>
>>>>
>>>> Tuesday, June 14, 2016, 12:27:01 PM, Pradeep Murugesan wrote:
>>>>
>>>>> Hi Daniel & team,
>>>>>
>>>>>
>>>>> Sorry that I was dormant for a long time after a very short tent
>>>>> @ Freemaker. I am out of some critical issues and have some bandwidth from now on.
>>>>>
>>>>>
>>>>> Kindly let me know if there is anything I could help.
>>>>>
>>>>>
>>>>> Pradeep.
>>>>>
>>>>> ________________________________
>>>>> From: Daniel Dekany <dd...@freemail.hu>
>>>>> Sent: Tuesday, June 14, 2016 12:48:55 AM
>>>>> To: Sergio Fernndez
>>>>> Cc: dev@freemarker.incubator.apache.org
>>>>> Subject: Graduation issues
>>>>>
>>>>> I think we can start some discussion about that even now. Or at least
>>>>> I will tell what do I think about the state of the project.
>>>>>
>>>>> The main problem is the number of active developers, which is 1, me.
>>>>> What if I'm hit by a truck tomorrow? We can hope that if there's a bug
>>>>> that concerns many, then someone will eventually fix it. After all the
>>>>> owner (ASF) won't be gone, the release infrastructure is there, etc.
>>>>> But as far as non-bugfix development goes, it's certain that things
>>>>> would stop. Some may say that that's OK for a project that's
>>>>> backward-compatibility-locked for 12 years now (the 2.x line is
>>>>> actually 14 years old). But of course that's just slow death if a
>>>>> project can't counter its old design problems and can't evolve to
>>>>> tackle new problems anymore. So indeed 2.x should switch to
>>>>> maintenance eventually (but ATM there are still things that can be
>>>>> done in 2.x), but only to give place for 3.x. Anyway, how to catch
>>>>> long standing developers? I don't think that 2.x have a real chance
>>>>> for that, because of all the legacy code burden piled up. (Some Apache
>>>>> projects have many paid contributors, but I think FM isn't the kind of
>>>>> project that can have that, so it's important that the developers want
>>>>> to fiddle with it for free.) So the 3.x jump will be necessary, and
>>>>> then, maybe, we can have a developer base growth (template engines
>>>>> isn't hot topic anymore, so I just mean having a few developers
>>>>> around). But 3.x is far away (if it will happen at all), and we can't
>>>>> hang around in the incubator forever. So, do you believe there's any
>>>>> chance to graduate with the current developer base?
>>>>>
>>>>>
>>>>> Monday, June 13, 2016, 8:15:11 AM, Sergio Fernndez wrote:
>>>>>
>>>>>> Besides the technical discussion for 2.3.25-incubating, after that release
>>>>>> you may start to discuss a possible graduation. We have to discuss many
>>>>>> aspects (specially growth of the community), but technically speaking the
>>>>>> podling is capable os casting releases.
>>>>>
>>>>> --
>>>>> Thanks,
>>>>> Daniel Dekany
>>>>>
>>>>
>>>> --
>>>> Thanks,
>>>> Daniel Dekany
>>>>
>>>
>>
>
--
Thanks,
Daniel Dekany
Re: FM Online improvements (Was: Graduation issues)
Posted by Pradeep Murugesan <pr...@outlook.com>.
Hi Daniel,
Got the client side changes and have pushed @ https://github.com/pradeepmurugesan/freemarker-online/tree/additionalTemplates.
Attached the screenshot of how it will look . Kindly let me know if there are any changes.
I am going through the server side requirements/changes that needs to be done. Will come back once I have my questions ready.
Pradeep.
________________________________
From: Daniel Dekany <dd...@freemail.hu>
Sent: Tuesday, August 2, 2016 1:39:01 AM
To: Pradeep Murugesan
Subject: Re: FM Online improvements (Was: Graduation issues)
Monday, August 1, 2016, 6:11:37 PM, Pradeep Murugesan wrote:
> Hi Daniel,
>
> Got a chance to work on the task. I have come up with something
> here http://codepen.io/pradeepmurugesan/pen/oLPNgQ.
Looks fine.
> I have the following questions.
>
> 1. The pure css used by the online validator is pretty old . Do we
> have any idea to replace the same with the latest version of
> pure(http://purecss.io/) or bootstrap.
You can update Pure if you want to, or use Bootstrap CSS... I don't
know either. If you have experience with them, I will trust your
judgement.
> 2. How many such template can the user add. like can he keep on
> adding it or we are going to put any restrictions there.
To keep users from killing the server, let's say, the main template
plus at most 3 importable/includable templates.
> Kindly let me know any changes in the pen and also answer to the above.
>
> Pradeep.
>
> From: Daniel Dekany <dd...@freemail.hu>
> Sent: Monday, June 27, 2016 11:59:34 AM
> To: Daniel Dekany
> Subject: Re: FM Online improvements (Was: Graduation issues)
>
> Monday, June 27, 2016, 8:24:21 AM, Daniel Dekany wrote:
>
>> I should
>
> I meant "It should".
>
>> support adding arbitrary templates. As I imagine it, there
>> would be an "Add template" button, and when you press it, it adds an
>> extra text area, which has a template name input, an "auto import"
>> checkbox, and an "auto include" checkbox, and a "Remove template"
>> button over it.
>
> Another thing... we should add an "Incompatible improvements" dropdown
> after the existing ones, which preselects the value of
> Configuration.getVersion().
>
>
>> Monday, June 27, 2016, 7:24:19 AM, Pradeep Murugesan wrote:
>>
>>> Hi Daniel,
>>>
>>>
>>> Cool.. I will start with adding the extra template name thing to
>>> the online template tester. (#import and #include) . I would need
>>> more pointers on the same. How have you visualised the same.
>>> Meaning , How the users can import other templates, we will give
>>> provision to add other templates or we have some predefined
>>> templates loaded , so that they can import the same ?
>>>
>>>
>>>
>>> Pradeep.
>>>
>>> ________________________________
>>> From: Daniel Dekany <dd...@freemail.hu>
>>> Sent: Tuesday, June 14, 2016 11:02:38 PM
>>> To: Pradeep Murugesan
>>> Cc: dev@freemarker.incubator.apache.org
>>> Subject: Re: Graduation issues
>>>
>>> Happy to see you back!
>>>
>>> There are things to do, of course.
>>>
>>> I haven't yet merged in your contribution with XML siblings (so it
>>> won't be in 2.3.25 - sorry about that, next time), and AFAIR there
>>> were some wrinkles to work on.
>>>
>>> I have done some of the planned improvements on
>>> http://freemarker-online.kenshoo.com/ (mostly to draw attention to the
>>> outputFormat setting of 2.3.24), but there are other things to do.
>>> Apart from what was discussed earlier, I think supporting adding extra
>>> templates with names would be handy, because then people can play
>>> around with #import and #include.
>>>
>>> And then of course, there's http://freemarker.org/contribute.html with
>>> even more things to do.
>>>
>>>
>>> Tuesday, June 14, 2016, 12:27:01 PM, Pradeep Murugesan wrote:
>>>
>>>> Hi Daniel & team,
>>>>
>>>>
>>>> Sorry that I was dormant for a long time after a very short tent
>>>> @ Freemaker. I am out of some critical issues and have some bandwidth from now on.
>>>>
>>>>
>>>> Kindly let me know if there is anything I could help.
>>>>
>>>>
>>>> Pradeep.
>>>>
>>>> ________________________________
>>>> From: Daniel Dekany <dd...@freemail.hu>
>>>> Sent: Tuesday, June 14, 2016 12:48:55 AM
>>>> To: Sergio Fernández
>>>> Cc: dev@freemarker.incubator.apache.org
>>>> Subject: Graduation issues
>>>>
>>>> I think we can start some discussion about that even now. Or at least
>>>> I will tell what do I think about the state of the project.
>>>>
>>>> The main problem is the number of active developers, which is 1, me.
>>>> What if I'm hit by a truck tomorrow? We can hope that if there's a bug
>>>> that concerns many, then someone will eventually fix it. After all the
>>>> owner (ASF) won't be gone, the release infrastructure is there, etc.
>>>> But as far as non-bugfix development goes, it's certain that things
>>>> would stop. Some may say that that's OK for a project that's
>>>> backward-compatibility-locked for 12 years now (the 2.x line is
>>>> actually 14 years old). But of course that's just slow death if a
>>>> project can't counter its old design problems and can't evolve to
>>>> tackle new problems anymore. So indeed 2.x should switch to
>>>> maintenance eventually (but ATM there are still things that can be
>>>> done in 2.x), but only to give place for 3.x. Anyway, how to catch
>>>> long standing developers? I don't think that 2.x have a real chance
>>>> for that, because of all the legacy code burden piled up. (Some Apache
>>>> projects have many paid contributors, but I think FM isn't the kind of
>>>> project that can have that, so it's important that the developers want
>>>> to fiddle with it for free.) So the 3.x jump will be necessary, and
>>>> then, maybe, we can have a developer base growth (template engines
>>>> isn't hot topic anymore, so I just mean having a few developers
>>>> around). But 3.x is far away (if it will happen at all), and we can't
>>>> hang around in the incubator forever. So, do you believe there's any
>>>> chance to graduate with the current developer base?
>>>>
>>>>
>>>> Monday, June 13, 2016, 8:15:11 AM, Sergio Fernández wrote:
>>>>
>>>>> Besides the technical discussion for 2.3.25-incubating, after that release
>>>>> you may start to discuss a possible graduation. We have to discuss many
>>>>> aspects (specially growth of the community), but technically speaking the
>>>>> podling is capable os casting releases.
>>>>
>>>> --
>>>> Thanks,
>>>> Daniel Dekany
>>>>
>>>
>>> --
>>> Thanks,
>>> Daniel Dekany
>>>
>>
>
--
Thanks,
Daniel Dekany
Re: FM Online improvements (Was: Graduation issues)
Posted by Daniel Dekany <dd...@freemail.hu>.
Monday, August 1, 2016, 6:11:37 PM, Pradeep Murugesan wrote:
> Hi Daniel,
>
> Got a chance to work on the task. I have come up with something
> here http://codepen.io/pradeepmurugesan/pen/oLPNgQ.
Looks fine.
> I have the following questions.
>
> 1. The pure css used by the online validator is pretty old . Do we
> have any idea to replace the same with the latest version of
> pure(http://purecss.io/) or bootstrap.
You can update Pure if you want to, or use Bootstrap CSS... I don't
know either. If you have experience with them, I will trust your
judgement.
> 2. How many such template can the user add. like can he keep on
> adding it or we are going to put any restrictions there.
To keep users from killing the server, let's say, the main template
plus at most 3 importable/includable templates.
> Kindly let me know any changes in the pen and also answer to the above.
>
> Pradeep.
>
> From: Daniel Dekany <dd...@freemail.hu>
> Sent: Monday, June 27, 2016 11:59:34 AM
> To: Daniel Dekany
> Subject: Re: FM Online improvements (Was: Graduation issues)
>
> Monday, June 27, 2016, 8:24:21 AM, Daniel Dekany wrote:
>
>> I should
>
> I meant "It should".
>
>> support adding arbitrary templates. As I imagine it, there
>> would be an "Add template" button, and when you press it, it adds an
>> extra text area, which has a template name input, an "auto import"
>> checkbox, and an "auto include" checkbox, and a "Remove template"
>> button over it.
>
> Another thing... we should add an "Incompatible improvements" dropdown
> after the existing ones, which preselects the value of
> Configuration.getVersion().
>
>
>> Monday, June 27, 2016, 7:24:19 AM, Pradeep Murugesan wrote:
>>
>>> Hi Daniel,
>>>
>>>
>>> Cool.. I will start with adding the extra template name thing to
>>> the online template tester. (#import and #include) . I would need
>>> more pointers on the same. How have you visualised the same.
>>> Meaning , How the users can import other templates, we will give
>>> provision to add other templates or we have some predefined
>>> templates loaded , so that they can import the same ?
>>>
>>>
>>>
>>> Pradeep.
>>>
>>> ________________________________
>>> From: Daniel Dekany <dd...@freemail.hu>
>>> Sent: Tuesday, June 14, 2016 11:02:38 PM
>>> To: Pradeep Murugesan
>>> Cc: dev@freemarker.incubator.apache.org
>>> Subject: Re: Graduation issues
>>>
>>> Happy to see you back!
>>>
>>> There are things to do, of course.
>>>
>>> I haven't yet merged in your contribution with XML siblings (so it
>>> won't be in 2.3.25 - sorry about that, next time), and AFAIR there
>>> were some wrinkles to work on.
>>>
>>> I have done some of the planned improvements on
>>> http://freemarker-online.kenshoo.com/ (mostly to draw attention to the
>>> outputFormat setting of 2.3.24), but there are other things to do.
>>> Apart from what was discussed earlier, I think supporting adding extra
>>> templates with names would be handy, because then people can play
>>> around with #import and #include.
>>>
>>> And then of course, there's http://freemarker.org/contribute.html with
>>> even more things to do.
>>>
>>>
>>> Tuesday, June 14, 2016, 12:27:01 PM, Pradeep Murugesan wrote:
>>>
>>>> Hi Daniel & team,
>>>>
>>>>
>>>> Sorry that I was dormant for a long time after a very short tent
>>>> @ Freemaker. I am out of some critical issues and have some bandwidth from now on.
>>>>
>>>>
>>>> Kindly let me know if there is anything I could help.
>>>>
>>>>
>>>> Pradeep.
>>>>
>>>> ________________________________
>>>> From: Daniel Dekany <dd...@freemail.hu>
>>>> Sent: Tuesday, June 14, 2016 12:48:55 AM
>>>> To: Sergio Fernndez
>>>> Cc: dev@freemarker.incubator.apache.org
>>>> Subject: Graduation issues
>>>>
>>>> I think we can start some discussion about that even now. Or at least
>>>> I will tell what do I think about the state of the project.
>>>>
>>>> The main problem is the number of active developers, which is 1, me.
>>>> What if I'm hit by a truck tomorrow? We can hope that if there's a bug
>>>> that concerns many, then someone will eventually fix it. After all the
>>>> owner (ASF) won't be gone, the release infrastructure is there, etc.
>>>> But as far as non-bugfix development goes, it's certain that things
>>>> would stop. Some may say that that's OK for a project that's
>>>> backward-compatibility-locked for 12 years now (the 2.x line is
>>>> actually 14 years old). But of course that's just slow death if a
>>>> project can't counter its old design problems and can't evolve to
>>>> tackle new problems anymore. So indeed 2.x should switch to
>>>> maintenance eventually (but ATM there are still things that can be
>>>> done in 2.x), but only to give place for 3.x. Anyway, how to catch
>>>> long standing developers? I don't think that 2.x have a real chance
>>>> for that, because of all the legacy code burden piled up. (Some Apache
>>>> projects have many paid contributors, but I think FM isn't the kind of
>>>> project that can have that, so it's important that the developers want
>>>> to fiddle with it for free.) So the 3.x jump will be necessary, and
>>>> then, maybe, we can have a developer base growth (template engines
>>>> isn't hot topic anymore, so I just mean having a few developers
>>>> around). But 3.x is far away (if it will happen at all), and we can't
>>>> hang around in the incubator forever. So, do you believe there's any
>>>> chance to graduate with the current developer base?
>>>>
>>>>
>>>> Monday, June 13, 2016, 8:15:11 AM, Sergio Fernndez wrote:
>>>>
>>>>> Besides the technical discussion for 2.3.25-incubating, after that release
>>>>> you may start to discuss a possible graduation. We have to discuss many
>>>>> aspects (specially growth of the community), but technically speaking the
>>>>> podling is capable os casting releases.
>>>>
>>>> --
>>>> Thanks,
>>>> Daniel Dekany
>>>>
>>>
>>> --
>>> Thanks,
>>> Daniel Dekany
>>>
>>
>
--
Thanks,
Daniel Dekany
Re: FM Online improvements (Was: Graduation issues)
Posted by Pradeep Murugesan <pr...@outlook.com>.
Hi Daniel,
Got a chance to work on the task. I have come up with something here http://codepen.io/pradeepmurugesan/pen/oLPNgQ.
I have the following questions.
1. The pure css used by the online validator is pretty old . Do we have any idea to replace the same with the latest version of pure(http://purecss.io/) or bootstrap.
2. How many such template can the user add. like can he keep on adding it or we are going to put any restrictions there.
Kindly let me know any changes in the pen and also answer to the above.
Pradeep.
________________________________
From: Daniel Dekany <dd...@freemail.hu>
Sent: Monday, June 27, 2016 11:59:34 AM
To: Daniel Dekany
Subject: Re: FM Online improvements (Was: Graduation issues)
Monday, June 27, 2016, 8:24:21 AM, Daniel Dekany wrote:
> I should
I meant "It should".
> support adding arbitrary templates. As I imagine it, there
> would be an "Add template" button, and when you press it, it adds an
> extra text area, which has a template name input, an "auto import"
> checkbox, and an "auto include" checkbox, and a "Remove template"
> button over it.
Another thing... we should add an "Incompatible improvements" dropdown
after the existing ones, which preselects the value of
Configuration.getVersion().
> Monday, June 27, 2016, 7:24:19 AM, Pradeep Murugesan wrote:
>
>> Hi Daniel,
>>
>>
>> Cool.. I will start with adding the extra template name thing to
>> the online template tester. (#import and #include) . I would need
>> more pointers on the same. How have you visualised the same.
>> Meaning , How the users can import other templates, we will give
>> provision to add other templates or we have some predefined
>> templates loaded , so that they can import the same ?
>>
>>
>>
>> Pradeep.
>>
>> ________________________________
>> From: Daniel Dekany <dd...@freemail.hu>
>> Sent: Tuesday, June 14, 2016 11:02:38 PM
>> To: Pradeep Murugesan
>> Cc: dev@freemarker.incubator.apache.org
>> Subject: Re: Graduation issues
>>
>> Happy to see you back!
>>
>> There are things to do, of course.
>>
>> I haven't yet merged in your contribution with XML siblings (so it
>> won't be in 2.3.25 - sorry about that, next time), and AFAIR there
>> were some wrinkles to work on.
>>
>> I have done some of the planned improvements on
>> http://freemarker-online.kenshoo.com/ (mostly to draw attention to the
>> outputFormat setting of 2.3.24), but there are other things to do.
>> Apart from what was discussed earlier, I think supporting adding extra
>> templates with names would be handy, because then people can play
>> around with #import and #include.
>>
>> And then of course, there's http://freemarker.org/contribute.html with
>> even more things to do.
>>
>>
>> Tuesday, June 14, 2016, 12:27:01 PM, Pradeep Murugesan wrote:
>>
>>> Hi Daniel & team,
>>>
>>>
>>> Sorry that I was dormant for a long time after a very short tent
>>> @ Freemaker. I am out of some critical issues and have some bandwidth from now on.
>>>
>>>
>>> Kindly let me know if there is anything I could help.
>>>
>>>
>>> Pradeep.
>>>
>>> ________________________________
>>> From: Daniel Dekany <dd...@freemail.hu>
>>> Sent: Tuesday, June 14, 2016 12:48:55 AM
>>> To: Sergio Fernández
>>> Cc: dev@freemarker.incubator.apache.org
>>> Subject: Graduation issues
>>>
>>> I think we can start some discussion about that even now. Or at least
>>> I will tell what do I think about the state of the project.
>>>
>>> The main problem is the number of active developers, which is 1, me.
>>> What if I'm hit by a truck tomorrow? We can hope that if there's a bug
>>> that concerns many, then someone will eventually fix it. After all the
>>> owner (ASF) won't be gone, the release infrastructure is there, etc.
>>> But as far as non-bugfix development goes, it's certain that things
>>> would stop. Some may say that that's OK for a project that's
>>> backward-compatibility-locked for 12 years now (the 2.x line is
>>> actually 14 years old). But of course that's just slow death if a
>>> project can't counter its old design problems and can't evolve to
>>> tackle new problems anymore. So indeed 2.x should switch to
>>> maintenance eventually (but ATM there are still things that can be
>>> done in 2.x), but only to give place for 3.x. Anyway, how to catch
>>> long standing developers? I don't think that 2.x have a real chance
>>> for that, because of all the legacy code burden piled up. (Some Apache
>>> projects have many paid contributors, but I think FM isn't the kind of
>>> project that can have that, so it's important that the developers want
>>> to fiddle with it for free.) So the 3.x jump will be necessary, and
>>> then, maybe, we can have a developer base growth (template engines
>>> isn't hot topic anymore, so I just mean having a few developers
>>> around). But 3.x is far away (if it will happen at all), and we can't
>>> hang around in the incubator forever. So, do you believe there's any
>>> chance to graduate with the current developer base?
>>>
>>>
>>> Monday, June 13, 2016, 8:15:11 AM, Sergio Fernández wrote:
>>>
>>>> Besides the technical discussion for 2.3.25-incubating, after that release
>>>> you may start to discuss a possible graduation. We have to discuss many
>>>> aspects (specially growth of the community), but technically speaking the
>>>> podling is capable os casting releases.
>>>
>>> --
>>> Thanks,
>>> Daniel Dekany
>>>
>>
>> --
>> Thanks,
>> Daniel Dekany
>>
>
--
Thanks,
Daniel Dekany
Re: FM Online improvements (Was: Graduation issues)
Posted by Daniel Dekany <dd...@freemail.hu>.
Monday, June 27, 2016, 8:24:21 AM, Daniel Dekany wrote:
> I should
I meant "It should".
> support adding arbitrary templates. As I imagine it, there
> would be an "Add template" button, and when you press it, it adds an
> extra text area, which has a template name input, an "auto import"
> checkbox, and an "auto include" checkbox, and a "Remove template"
> button over it.
Another thing... we should add an "Incompatible improvements" dropdown
after the existing ones, which preselects the value of
Configuration.getVersion().
> Monday, June 27, 2016, 7:24:19 AM, Pradeep Murugesan wrote:
>
>> Hi Daniel,
>>
>>
>> Cool.. I will start with adding the extra template name thing to
>> the online template tester. (#import and #include) . I would need
>> more pointers on the same. How have you visualised the same.
>> Meaning , How the users can import other templates, we will give
>> provision to add other templates or we have some predefined
>> templates loaded , so that they can import the same ?
>>
>>
>>
>> Pradeep.
>>
>> ________________________________
>> From: Daniel Dekany <dd...@freemail.hu>
>> Sent: Tuesday, June 14, 2016 11:02:38 PM
>> To: Pradeep Murugesan
>> Cc: dev@freemarker.incubator.apache.org
>> Subject: Re: Graduation issues
>>
>> Happy to see you back!
>>
>> There are things to do, of course.
>>
>> I haven't yet merged in your contribution with XML siblings (so it
>> won't be in 2.3.25 - sorry about that, next time), and AFAIR there
>> were some wrinkles to work on.
>>
>> I have done some of the planned improvements on
>> http://freemarker-online.kenshoo.com/ (mostly to draw attention to the
>> outputFormat setting of 2.3.24), but there are other things to do.
>> Apart from what was discussed earlier, I think supporting adding extra
>> templates with names would be handy, because then people can play
>> around with #import and #include.
>>
>> And then of course, there's http://freemarker.org/contribute.html with
>> even more things to do.
>>
>>
>> Tuesday, June 14, 2016, 12:27:01 PM, Pradeep Murugesan wrote:
>>
>>> Hi Daniel & team,
>>>
>>>
>>> Sorry that I was dormant for a long time after a very short tent
>>> @ Freemaker. I am out of some critical issues and have some bandwidth from now on.
>>>
>>>
>>> Kindly let me know if there is anything I could help.
>>>
>>>
>>> Pradeep.
>>>
>>> ________________________________
>>> From: Daniel Dekany <dd...@freemail.hu>
>>> Sent: Tuesday, June 14, 2016 12:48:55 AM
>>> To: Sergio Fernndez
>>> Cc: dev@freemarker.incubator.apache.org
>>> Subject: Graduation issues
>>>
>>> I think we can start some discussion about that even now. Or at least
>>> I will tell what do I think about the state of the project.
>>>
>>> The main problem is the number of active developers, which is 1, me.
>>> What if I'm hit by a truck tomorrow? We can hope that if there's a bug
>>> that concerns many, then someone will eventually fix it. After all the
>>> owner (ASF) won't be gone, the release infrastructure is there, etc.
>>> But as far as non-bugfix development goes, it's certain that things
>>> would stop. Some may say that that's OK for a project that's
>>> backward-compatibility-locked for 12 years now (the 2.x line is
>>> actually 14 years old). But of course that's just slow death if a
>>> project can't counter its old design problems and can't evolve to
>>> tackle new problems anymore. So indeed 2.x should switch to
>>> maintenance eventually (but ATM there are still things that can be
>>> done in 2.x), but only to give place for 3.x. Anyway, how to catch
>>> long standing developers? I don't think that 2.x have a real chance
>>> for that, because of all the legacy code burden piled up. (Some Apache
>>> projects have many paid contributors, but I think FM isn't the kind of
>>> project that can have that, so it's important that the developers want
>>> to fiddle with it for free.) So the 3.x jump will be necessary, and
>>> then, maybe, we can have a developer base growth (template engines
>>> isn't hot topic anymore, so I just mean having a few developers
>>> around). But 3.x is far away (if it will happen at all), and we can't
>>> hang around in the incubator forever. So, do you believe there's any
>>> chance to graduate with the current developer base?
>>>
>>>
>>> Monday, June 13, 2016, 8:15:11 AM, Sergio Fernndez wrote:
>>>
>>>> Besides the technical discussion for 2.3.25-incubating, after that release
>>>> you may start to discuss a possible graduation. We have to discuss many
>>>> aspects (specially growth of the community), but technically speaking the
>>>> podling is capable os casting releases.
>>>
>>> --
>>> Thanks,
>>> Daniel Dekany
>>>
>>
>> --
>> Thanks,
>> Daniel Dekany
>>
>
--
Thanks,
Daniel Dekany
FM Online improvements (Was: Graduation issues)
Posted by Daniel Dekany <dd...@freemail.hu>.
I should support adding arbitrary templates. As I imagine it, there
would be an "Add template" button, and when you press it, it adds an
extra text area, which has a template name input, an "auto import"
checkbox, and an "auto include" checkbox, and a "Remove template"
button over it.
Monday, June 27, 2016, 7:24:19 AM, Pradeep Murugesan wrote:
> Hi Daniel,
>
>
> Cool.. I will start with adding the extra template name thing to
> the online template tester. (#import and #include) . I would need
> more pointers on the same. How have you visualised the same.
> Meaning , How the users can import other templates, we will give
> provision to add other templates or we have some predefined
> templates loaded , so that they can import the same ?
>
>
>
> Pradeep.
>
> ________________________________
> From: Daniel Dekany <dd...@freemail.hu>
> Sent: Tuesday, June 14, 2016 11:02:38 PM
> To: Pradeep Murugesan
> Cc: dev@freemarker.incubator.apache.org
> Subject: Re: Graduation issues
>
> Happy to see you back!
>
> There are things to do, of course.
>
> I haven't yet merged in your contribution with XML siblings (so it
> won't be in 2.3.25 - sorry about that, next time), and AFAIR there
> were some wrinkles to work on.
>
> I have done some of the planned improvements on
> http://freemarker-online.kenshoo.com/ (mostly to draw attention to the
> outputFormat setting of 2.3.24), but there are other things to do.
> Apart from what was discussed earlier, I think supporting adding extra
> templates with names would be handy, because then people can play
> around with #import and #include.
>
> And then of course, there's http://freemarker.org/contribute.html with
> even more things to do.
>
>
> Tuesday, June 14, 2016, 12:27:01 PM, Pradeep Murugesan wrote:
>
>> Hi Daniel & team,
>>
>>
>> Sorry that I was dormant for a long time after a very short tent
>> @ Freemaker. I am out of some critical issues and have some bandwidth from now on.
>>
>>
>> Kindly let me know if there is anything I could help.
>>
>>
>> Pradeep.
>>
>> ________________________________
>> From: Daniel Dekany <dd...@freemail.hu>
>> Sent: Tuesday, June 14, 2016 12:48:55 AM
>> To: Sergio Fernndez
>> Cc: dev@freemarker.incubator.apache.org
>> Subject: Graduation issues
>>
>> I think we can start some discussion about that even now. Or at least
>> I will tell what do I think about the state of the project.
>>
>> The main problem is the number of active developers, which is 1, me.
>> What if I'm hit by a truck tomorrow? We can hope that if there's a bug
>> that concerns many, then someone will eventually fix it. After all the
>> owner (ASF) won't be gone, the release infrastructure is there, etc.
>> But as far as non-bugfix development goes, it's certain that things
>> would stop. Some may say that that's OK for a project that's
>> backward-compatibility-locked for 12 years now (the 2.x line is
>> actually 14 years old). But of course that's just slow death if a
>> project can't counter its old design problems and can't evolve to
>> tackle new problems anymore. So indeed 2.x should switch to
>> maintenance eventually (but ATM there are still things that can be
>> done in 2.x), but only to give place for 3.x. Anyway, how to catch
>> long standing developers? I don't think that 2.x have a real chance
>> for that, because of all the legacy code burden piled up. (Some Apache
>> projects have many paid contributors, but I think FM isn't the kind of
>> project that can have that, so it's important that the developers want
>> to fiddle with it for free.) So the 3.x jump will be necessary, and
>> then, maybe, we can have a developer base growth (template engines
>> isn't hot topic anymore, so I just mean having a few developers
>> around). But 3.x is far away (if it will happen at all), and we can't
>> hang around in the incubator forever. So, do you believe there's any
>> chance to graduate with the current developer base?
>>
>>
>> Monday, June 13, 2016, 8:15:11 AM, Sergio Fernndez wrote:
>>
>>> Besides the technical discussion for 2.3.25-incubating, after that release
>>> you may start to discuss a possible graduation. We have to discuss many
>>> aspects (specially growth of the community), but technically speaking the
>>> podling is capable os casting releases.
>>
>> --
>> Thanks,
>> Daniel Dekany
>>
>
> --
> Thanks,
> Daniel Dekany
>
--
Thanks,
Daniel Dekany
Re: Graduation issues
Posted by Pradeep Murugesan <pr...@outlook.com>.
Hi Daniel,
Cool.. I will start with adding the extra template name thing to the online template tester. (#import and #include) . I would need more pointers on the same. How have you visualised the same. Meaning , How the users can import other templates, we will give provision to add other templates or we have some predefined templates loaded , so that they can import the same ?
Pradeep.
________________________________
From: Daniel Dekany <dd...@freemail.hu>
Sent: Tuesday, June 14, 2016 11:02:38 PM
To: Pradeep Murugesan
Cc: dev@freemarker.incubator.apache.org
Subject: Re: Graduation issues
Happy to see you back!
There are things to do, of course.
I haven't yet merged in your contribution with XML siblings (so it
won't be in 2.3.25 - sorry about that, next time), and AFAIR there
were some wrinkles to work on.
I have done some of the planned improvements on
http://freemarker-online.kenshoo.com/ (mostly to draw attention to the
outputFormat setting of 2.3.24), but there are other things to do.
Apart from what was discussed earlier, I think supporting adding extra
templates with names would be handy, because then people can play
around with #import and #include.
And then of course, there's http://freemarker.org/contribute.html with
even more things to do.
Tuesday, June 14, 2016, 12:27:01 PM, Pradeep Murugesan wrote:
> Hi Daniel & team,
>
>
> Sorry that I was dormant for a long time after a very short tent
> @ Freemaker. I am out of some critical issues and have some bandwidth from now on.
>
>
> Kindly let me know if there is anything I could help.
>
>
> Pradeep.
>
> ________________________________
> From: Daniel Dekany <dd...@freemail.hu>
> Sent: Tuesday, June 14, 2016 12:48:55 AM
> To: Sergio Fernández
> Cc: dev@freemarker.incubator.apache.org
> Subject: Graduation issues
>
> I think we can start some discussion about that even now. Or at least
> I will tell what do I think about the state of the project.
>
> The main problem is the number of active developers, which is 1, me.
> What if I'm hit by a truck tomorrow? We can hope that if there's a bug
> that concerns many, then someone will eventually fix it. After all the
> owner (ASF) won't be gone, the release infrastructure is there, etc.
> But as far as non-bugfix development goes, it's certain that things
> would stop. Some may say that that's OK for a project that's
> backward-compatibility-locked for 12 years now (the 2.x line is
> actually 14 years old). But of course that's just slow death if a
> project can't counter its old design problems and can't evolve to
> tackle new problems anymore. So indeed 2.x should switch to
> maintenance eventually (but ATM there are still things that can be
> done in 2.x), but only to give place for 3.x. Anyway, how to catch
> long standing developers? I don't think that 2.x have a real chance
> for that, because of all the legacy code burden piled up. (Some Apache
> projects have many paid contributors, but I think FM isn't the kind of
> project that can have that, so it's important that the developers want
> to fiddle with it for free.) So the 3.x jump will be necessary, and
> then, maybe, we can have a developer base growth (template engines
> isn't hot topic anymore, so I just mean having a few developers
> around). But 3.x is far away (if it will happen at all), and we can't
> hang around in the incubator forever. So, do you believe there's any
> chance to graduate with the current developer base?
>
>
> Monday, June 13, 2016, 8:15:11 AM, Sergio Fernández wrote:
>
>> Besides the technical discussion for 2.3.25-incubating, after that release
>> you may start to discuss a possible graduation. We have to discuss many
>> aspects (specially growth of the community), but technically speaking the
>> podling is capable os casting releases.
>
> --
> Thanks,
> Daniel Dekany
>
--
Thanks,
Daniel Dekany
Re: Graduation issues
Posted by Daniel Dekany <dd...@freemail.hu>.
Happy to see you back!
There are things to do, of course.
I haven't yet merged in your contribution with XML siblings (so it
won't be in 2.3.25 - sorry about that, next time), and AFAIR there
were some wrinkles to work on.
I have done some of the planned improvements on
http://freemarker-online.kenshoo.com/ (mostly to draw attention to the
outputFormat setting of 2.3.24), but there are other things to do.
Apart from what was discussed earlier, I think supporting adding extra
templates with names would be handy, because then people can play
around with #import and #include.
And then of course, there's http://freemarker.org/contribute.html with
even more things to do.
Tuesday, June 14, 2016, 12:27:01 PM, Pradeep Murugesan wrote:
> Hi Daniel & team,
>
>
> Sorry that I was dormant for a long time after a very short tent
> @ Freemaker. I am out of some critical issues and have some bandwidth from now on.
>
>
> Kindly let me know if there is anything I could help.
>
>
> Pradeep.
>
> ________________________________
> From: Daniel Dekany <dd...@freemail.hu>
> Sent: Tuesday, June 14, 2016 12:48:55 AM
> To: Sergio Fernndez
> Cc: dev@freemarker.incubator.apache.org
> Subject: Graduation issues
>
> I think we can start some discussion about that even now. Or at least
> I will tell what do I think about the state of the project.
>
> The main problem is the number of active developers, which is 1, me.
> What if I'm hit by a truck tomorrow? We can hope that if there's a bug
> that concerns many, then someone will eventually fix it. After all the
> owner (ASF) won't be gone, the release infrastructure is there, etc.
> But as far as non-bugfix development goes, it's certain that things
> would stop. Some may say that that's OK for a project that's
> backward-compatibility-locked for 12 years now (the 2.x line is
> actually 14 years old). But of course that's just slow death if a
> project can't counter its old design problems and can't evolve to
> tackle new problems anymore. So indeed 2.x should switch to
> maintenance eventually (but ATM there are still things that can be
> done in 2.x), but only to give place for 3.x. Anyway, how to catch
> long standing developers? I don't think that 2.x have a real chance
> for that, because of all the legacy code burden piled up. (Some Apache
> projects have many paid contributors, but I think FM isn't the kind of
> project that can have that, so it's important that the developers want
> to fiddle with it for free.) So the 3.x jump will be necessary, and
> then, maybe, we can have a developer base growth (template engines
> isn't hot topic anymore, so I just mean having a few developers
> around). But 3.x is far away (if it will happen at all), and we can't
> hang around in the incubator forever. So, do you believe there's any
> chance to graduate with the current developer base?
>
>
> Monday, June 13, 2016, 8:15:11 AM, Sergio Fernndez wrote:
>
>> Besides the technical discussion for 2.3.25-incubating, after that release
>> you may start to discuss a possible graduation. We have to discuss many
>> aspects (specially growth of the community), but technically speaking the
>> podling is capable os casting releases.
>
> --
> Thanks,
> Daniel Dekany
>
--
Thanks,
Daniel Dekany
Re: Graduation issues
Posted by Pradeep Murugesan <pr...@outlook.com>.
Hi Daniel & team,
Sorry that I was dormant for a long time after a very short tent @ Freemaker. I am out of some critical issues and have some bandwidth from now on.
Kindly let me know if there is anything I could help.
Pradeep.
________________________________
From: Daniel Dekany <dd...@freemail.hu>
Sent: Tuesday, June 14, 2016 12:48:55 AM
To: Sergio Fernández
Cc: dev@freemarker.incubator.apache.org
Subject: Graduation issues
I think we can start some discussion about that even now. Or at least
I will tell what do I think about the state of the project.
The main problem is the number of active developers, which is 1, me.
What if I'm hit by a truck tomorrow? We can hope that if there's a bug
that concerns many, then someone will eventually fix it. After all the
owner (ASF) won't be gone, the release infrastructure is there, etc.
But as far as non-bugfix development goes, it's certain that things
would stop. Some may say that that's OK for a project that's
backward-compatibility-locked for 12 years now (the 2.x line is
actually 14 years old). But of course that's just slow death if a
project can't counter its old design problems and can't evolve to
tackle new problems anymore. So indeed 2.x should switch to
maintenance eventually (but ATM there are still things that can be
done in 2.x), but only to give place for 3.x. Anyway, how to catch
long standing developers? I don't think that 2.x have a real chance
for that, because of all the legacy code burden piled up. (Some Apache
projects have many paid contributors, but I think FM isn't the kind of
project that can have that, so it's important that the developers want
to fiddle with it for free.) So the 3.x jump will be necessary, and
then, maybe, we can have a developer base growth (template engines
isn't hot topic anymore, so I just mean having a few developers
around). But 3.x is far away (if it will happen at all), and we can't
hang around in the incubator forever. So, do you believe there's any
chance to graduate with the current developer base?
Monday, June 13, 2016, 8:15:11 AM, Sergio Fernández wrote:
> Besides the technical discussion for 2.3.25-incubating, after that release
> you may start to discuss a possible graduation. We have to discuss many
> aspects (specially growth of the community), but technically speaking the
> podling is capable os casting releases.
--
Thanks,
Daniel Dekany
Graduation issues
Posted by Daniel Dekany <dd...@freemail.hu>.
I think we can start some discussion about that even now. Or at least
I will tell what do I think about the state of the project.
The main problem is the number of active developers, which is 1, me.
What if I'm hit by a truck tomorrow? We can hope that if there's a bug
that concerns many, then someone will eventually fix it. After all the
owner (ASF) won't be gone, the release infrastructure is there, etc.
But as far as non-bugfix development goes, it's certain that things
would stop. Some may say that that's OK for a project that's
backward-compatibility-locked for 12 years now (the 2.x line is
actually 14 years old). But of course that's just slow death if a
project can't counter its old design problems and can't evolve to
tackle new problems anymore. So indeed 2.x should switch to
maintenance eventually (but ATM there are still things that can be
done in 2.x), but only to give place for 3.x. Anyway, how to catch
long standing developers? I don't think that 2.x have a real chance
for that, because of all the legacy code burden piled up. (Some Apache
projects have many paid contributors, but I think FM isn't the kind of
project that can have that, so it's important that the developers want
to fiddle with it for free.) So the 3.x jump will be necessary, and
then, maybe, we can have a developer base growth (template engines
isn't hot topic anymore, so I just mean having a few developers
around). But 3.x is far away (if it will happen at all), and we can't
hang around in the incubator forever. So, do you believe there's any
chance to graduate with the current developer base?
Monday, June 13, 2016, 8:15:11 AM, Sergio Fern�ndez wrote:
> Besides the technical discussion for 2.3.25-incubating, after that release
> you may start to discuss a possible graduation. We have to discuss many
> aspects (specially growth of the community), but technically speaking the
> podling is capable os casting releases.
--
Thanks,
Daniel Dekany
Re: Anybody wants anything before 2.3.25? Also, current release notes.
Posted by Daniel Dekany <dd...@freemail.hu>.
Yeah, I wanted to talk about those things, especially because of the
developer community concerns. So I will return to this.
Monday, June 13, 2016, 8:15:11 AM, Sergio Fern�ndez wrote:
> Besides the technical discussion for 2.3.25-incubating, after that
> release you may start to discuss a possible graduation. We have to
> discuss many aspects (specially growth of the community), but
> technically speaking the podling is capable os casting releases.
>
> On Mon, Jun 13, 2016 at 3:55 AM, Albert Kam <mo...@gmail.com> wrote:
> Hello Daniel,
>
> Thanks for the great updates !
>
> I have something in mind concerning the <#sep> directive. Is it
> possible to add a startSeparator only when the previous loop produces
> content ?
> This happens a lot when printing json hash entries. Example :
>
> <#local hobbies=['read', 'code', 'walk']>
> {
> <#list hobbies as hobby>
> <#if hobby != 'walk>
> 'prop${hobby_index}': '${hobby}'<#sep>,<#sep>
> </#if>
> </#list>
> }
>
> This will result in
> {
> 'prop0': 'read',
> 'prop1': 'walk',
> }
> Notice the extra comma after 'walk'.
>
> I have a workaround for this issue with adding the comma at the head
> if already had an entry:
> <#local hasEntry=false>
> <#list hobbies as hobby>
> <#if hobby != 'walk>
> <#if hasEntry>,</#if>
> 'prop${hobby_index}': '${hobby}'
> <#local hasEntry=true>
> </#if>
> </#list>
>
> This will result in
> {
> 'prop0': 'read'
> ,
> 'prop1': 'walk'
> }
>
> The ideal directive to emultate the workaround above would look
> something like this:
> <#list hobbies as hobby>
> <#if hobby != 'walk>
> <#head_sep>,<#head_sep>
> 'prop${hobby_index}': '${hobby}'
> </#if>
> </#list>
> Where <#head_sep> renderes the comma only if the previous loop had an entry.
>
> Just a suggestion.
>
> Thanks !
>
>
> On Mon, Jun 13, 2016 at 3:32 AM, Daniel Dekany <dd...@freemail.hu> wrote:
>> I plan to start a voting here on 2016-06-14, for releasing 2.3.25. So
>> if anyone wants to add anything before that, inform me.
>>
>> This is what we have so far:
>> - Version history: http://freemarker.org/builds/2.3.25-nightly/documentation/_html/versions_2_3_25.html
>> - Last build: http://freemarker.org/builds/2.3.25-nightly/freemarker.jar
>>
>> --
>> Thanks,
>> Daniel Dekany
>>
>
>
>
> --
> Do not pursue the past. Do not lose yourself in the future.
> The past no longer is. The future has not yet come.
> Looking deeply at life as it is in the very here and now,
> the practitioner dwells in stability and freedom.
> (Thich Nhat Hanh)
>
>
>
--
Thanks,
Daniel Dekany
Re: Anybody wants anything before 2.3.25? Also, current release notes.
Posted by Jacopo Cappellato <ja...@gmail.com>.
I second Sergio's proposal: the podling is clearly capable and autonomous
to manage the various aspects of the project's life and most of all the
releases (kudos). As anticipated when the project joined the Incubator, the
community is small and this will be a topic to discuss for the graduation.
Jacopo
On Mon, Jun 13, 2016 at 8:15 AM, Sergio Fernández <wi...@apache.org> wrote:
> Besides the technical discussion for 2.3.25-incubating, after that release
> you may start to discuss a possible graduation. We have to discuss many
> aspects (specially growth of the community), but technically speaking the
> podling is capable os casting releases.
>
> On Mon, Jun 13, 2016 at 3:55 AM, Albert Kam <mo...@gmail.com>
> wrote:
>
> > Hello Daniel,
> >
> > Thanks for the great updates !
> >
> > I have something in mind concerning the <#sep> directive. Is it
> > possible to add a startSeparator only when the previous loop produces
> > content ?
> > This happens a lot when printing json hash entries. Example :
> >
> > <#local hobbies=['read', 'code', 'walk']>
> > {
> > <#list hobbies as hobby>
> > <#if hobby != 'walk>
> > 'prop${hobby_index}': '${hobby}'<#sep>,<#sep>
> > </#if>
> > </#list>
> > }
> >
> > This will result in
> > {
> > 'prop0': 'read',
> > 'prop1': 'walk',
> > }
> > Notice the extra comma after 'walk'.
> >
> > I have a workaround for this issue with adding the comma at the head
> > if already had an entry:
> > <#local hasEntry=false>
> > <#list hobbies as hobby>
> > <#if hobby != 'walk>
> > <#if hasEntry>,</#if>
> > 'prop${hobby_index}': '${hobby}'
> > <#local hasEntry=true>
> > </#if>
> > </#list>
> >
> > This will result in
> > {
> > 'prop0': 'read'
> > ,
> > 'prop1': 'walk'
> > }
> >
> > The ideal directive to emultate the workaround above would look
> > something like this:
> > <#list hobbies as hobby>
> > <#if hobby != 'walk>
> > <#head_sep>,<#head_sep>
> > 'prop${hobby_index}': '${hobby}'
> > </#if>
> > </#list>
> > Where <#head_sep> renderes the comma only if the previous loop had an
> > entry.
> >
> > Just a suggestion.
> >
> > Thanks !
> >
> >
> > On Mon, Jun 13, 2016 at 3:32 AM, Daniel Dekany <dd...@freemail.hu>
> > wrote:
> > > I plan to start a voting here on 2016-06-14, for releasing 2.3.25. So
> > > if anyone wants to add anything before that, inform me.
> > >
> > > This is what we have so far:
> > > - Version history:
> >
> http://freemarker.org/builds/2.3.25-nightly/documentation/_html/versions_2_3_25.html
> > > - Last build:
> http://freemarker.org/builds/2.3.25-nightly/freemarker.jar
> > >
> > > --
> > > Thanks,
> > > Daniel Dekany
> > >
> >
> >
> >
> > --
> > Do not pursue the past. Do not lose yourself in the future.
> > The past no longer is. The future has not yet come.
> > Looking deeply at life as it is in the very here and now,
> > the practitioner dwells in stability and freedom.
> > (Thich Nhat Hanh)
> >
>
>
>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 6602747925
> e: sergio.fernandez@redlink.co
> w: http://redlink.co
>
Re: Anybody wants anything before 2.3.25? Also, current release notes.
Posted by Sergio Fernández <wi...@apache.org>.
Besides the technical discussion for 2.3.25-incubating, after that release
you may start to discuss a possible graduation. We have to discuss many
aspects (specially growth of the community), but technically speaking the
podling is capable os casting releases.
On Mon, Jun 13, 2016 at 3:55 AM, Albert Kam <mo...@gmail.com>
wrote:
> Hello Daniel,
>
> Thanks for the great updates !
>
> I have something in mind concerning the <#sep> directive. Is it
> possible to add a startSeparator only when the previous loop produces
> content ?
> This happens a lot when printing json hash entries. Example :
>
> <#local hobbies=['read', 'code', 'walk']>
> {
> <#list hobbies as hobby>
> <#if hobby != 'walk>
> 'prop${hobby_index}': '${hobby}'<#sep>,<#sep>
> </#if>
> </#list>
> }
>
> This will result in
> {
> 'prop0': 'read',
> 'prop1': 'walk',
> }
> Notice the extra comma after 'walk'.
>
> I have a workaround for this issue with adding the comma at the head
> if already had an entry:
> <#local hasEntry=false>
> <#list hobbies as hobby>
> <#if hobby != 'walk>
> <#if hasEntry>,</#if>
> 'prop${hobby_index}': '${hobby}'
> <#local hasEntry=true>
> </#if>
> </#list>
>
> This will result in
> {
> 'prop0': 'read'
> ,
> 'prop1': 'walk'
> }
>
> The ideal directive to emultate the workaround above would look
> something like this:
> <#list hobbies as hobby>
> <#if hobby != 'walk>
> <#head_sep>,<#head_sep>
> 'prop${hobby_index}': '${hobby}'
> </#if>
> </#list>
> Where <#head_sep> renderes the comma only if the previous loop had an
> entry.
>
> Just a suggestion.
>
> Thanks !
>
>
> On Mon, Jun 13, 2016 at 3:32 AM, Daniel Dekany <dd...@freemail.hu>
> wrote:
> > I plan to start a voting here on 2016-06-14, for releasing 2.3.25. So
> > if anyone wants to add anything before that, inform me.
> >
> > This is what we have so far:
> > - Version history:
> http://freemarker.org/builds/2.3.25-nightly/documentation/_html/versions_2_3_25.html
> > - Last build: http://freemarker.org/builds/2.3.25-nightly/freemarker.jar
> >
> > --
> > Thanks,
> > Daniel Dekany
> >
>
>
>
> --
> Do not pursue the past. Do not lose yourself in the future.
> The past no longer is. The future has not yet come.
> Looking deeply at life as it is in the very here and now,
> the practitioner dwells in stability and freedom.
> (Thich Nhat Hanh)
>
--
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 6602747925
e: sergio.fernandez@redlink.co
w: http://redlink.co
Re: Anybody wants anything before 2.3.25? Also, current release notes.
Posted by Albert Kam <mo...@gmail.com>.
Hello Daniel,
Thanks for the great updates !
I have something in mind concerning the <#sep> directive. Is it
possible to add a startSeparator only when the previous loop produces
content ?
This happens a lot when printing json hash entries. Example :
<#local hobbies=['read', 'code', 'walk']>
{
<#list hobbies as hobby>
<#if hobby != 'walk>
'prop${hobby_index}': '${hobby}'<#sep>,<#sep>
</#if>
</#list>
}
This will result in
{
'prop0': 'read',
'prop1': 'walk',
}
Notice the extra comma after 'walk'.
I have a workaround for this issue with adding the comma at the head
if already had an entry:
<#local hasEntry=false>
<#list hobbies as hobby>
<#if hobby != 'walk>
<#if hasEntry>,</#if>
'prop${hobby_index}': '${hobby}'
<#local hasEntry=true>
</#if>
</#list>
This will result in
{
'prop0': 'read'
,
'prop1': 'walk'
}
The ideal directive to emultate the workaround above would look
something like this:
<#list hobbies as hobby>
<#if hobby != 'walk>
<#head_sep>,<#head_sep>
'prop${hobby_index}': '${hobby}'
</#if>
</#list>
Where <#head_sep> renderes the comma only if the previous loop had an entry.
Just a suggestion.
Thanks !
On Mon, Jun 13, 2016 at 3:32 AM, Daniel Dekany <dd...@freemail.hu> wrote:
> I plan to start a voting here on 2016-06-14, for releasing 2.3.25. So
> if anyone wants to add anything before that, inform me.
>
> This is what we have so far:
> - Version history: http://freemarker.org/builds/2.3.25-nightly/documentation/_html/versions_2_3_25.html
> - Last build: http://freemarker.org/builds/2.3.25-nightly/freemarker.jar
>
> --
> Thanks,
> Daniel Dekany
>
--
Do not pursue the past. Do not lose yourself in the future.
The past no longer is. The future has not yet come.
Looking deeply at life as it is in the very here and now,
the practitioner dwells in stability and freedom.
(Thich Nhat Hanh)