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 <da...@gmail.com> on 2020/03/29 22:12:24 UTC
Re: Contributing to FREEMARKER-35: JSR 310 support for java8
java.time.temporal DateTimeFormatter
Hi Teun,
Did you submit the CLI?
On Wed, Feb 26, 2020 at 4:17 PM Teun <te...@betterbe.com> wrote:
> Fixed the two random small things.
> I'll try to submit the CLA request.
>
> Regards, Teun
>
> > On 2020-02-24, at 22:04, Daniel Dekany <da...@gmail.com> wrote:
> >
> > OK, great!
> >
> > Two random small things that I happened to spot (but eventually I will go
> > through all this properly):
> >
> > - Instead of things like YEARMONTH_FORMAT_KEY_CAMEL_CASE,
> > "yearmonth_format", and "year_month_format", let's use the more natural
> > YEAR_MONTH_FORMAT, "year_month_format", and "yearMonthFormat". Same
> for the
> > other temporal types as well. I assume you just tried to be consistent
> with
> > "datetime", but that's actually a mistake (that's the SQL-ish name of
> the
> > type, that somehow get into releases unfortunately... maybe we should
> add
> > date_time etc. as an alias).
> > - String getTemporalFormat(Temporal temporal): Maybe fine for
> > convenience, but the basic overload should be String
> > getTemporalFormat(Class<? extends Temporal> temporalClass), as this
> > function doesn't really care about the instance.
> >
> >
> > When you have the CLA (and are yo sure that your employee can't claim
> this
> > or such), we can merge into the FREEMARKER-35 branch. When it's finished,
> > which also means the me or some others here went through it, polished it,
> > etc., then it will be merged into the 2.3-gae branch.
> >
> > Thanks!
>
>
--
Best regards,
Daniel Dekany
Re: Contributing to FREEMARKER-35: JSR 310 support for java8
java.time.temporal DateTimeFormatter
Posted by Daniel Dekany <da...@gmail.com>.
Thanks Teun! Your PR was merged into the FREEMARKER-35 feature branch.
This branch will need further work to be mergeable back to a released
branch of course. I, for one, will work on it.
Note this feature will raise the minimum Java version to 8, because the
Java 8 time API is statically referred from TemplateTemporalModel. So new
FreeMarker release, if this will be in it (and it should), will require
Java 8.
On Fri, Apr 10, 2020 at 6:13 PM Teun <te...@betterbe.com> wrote:
> Progress so far:
> CLA has been submitted (and accepted i think?)
> Pull request was made (see https://github.com/apache/freemarker/pull/65 )
>
> Regards, Teun
>
> > On 2020-03-30, at 00:33, Teun <te...@be.nl> wrote:
> >
> > Ahh not yet.
> > The company i work for said they'd sign the CCLA but i haven't checked
> the progress on that lately.
> > Will check.
> >
> >> On 2020-03-30, at 00:13, Daniel Dekany <da...@gmail.com> wrote:
> >>
> >> Err.. I mean, the CLA.
> >>
> >> On Mon, Mar 30, 2020 at 12:12 AM Daniel Dekany <daniel.dekany@gmail.com
> >
> >> wrote:
> >>
> >>> Hi Teun,
> >>>
> >>> Did you submit the CLI?
> >>>
> >>> On Wed, Feb 26, 2020 at 4:17 PM Teun <te...@betterbe.com> wrote:
> >>>
> >>>> Fixed the two random small things.
> >>>> I'll try to submit the CLA request.
> >>>>
> >>>> Regards, Teun
> >>>>
> >>>>> On 2020-02-24, at 22:04, Daniel Dekany <da...@gmail.com>
> wrote:
> >>>>>
> >>>>> OK, great!
> >>>>>
> >>>>> Two random small things that I happened to spot (but eventually I
> will
> >>>> go
> >>>>> through all this properly):
> >>>>>
> >>>>> - Instead of things like YEARMONTH_FORMAT_KEY_CAMEL_CASE,
> >>>>> "yearmonth_format", and "year_month_format", let's use the more
> >>>> natural
> >>>>> YEAR_MONTH_FORMAT, "year_month_format", and "yearMonthFormat". Same
> >>>> for the
> >>>>> other temporal types as well. I assume you just tried to be
> >>>> consistent with
> >>>>> "datetime", but that's actually a mistake (that's the SQL-ish name of
> >>>> the
> >>>>> type, that somehow get into releases unfortunately... maybe we should
> >>>> add
> >>>>> date_time etc. as an alias).
> >>>>> - String getTemporalFormat(Temporal temporal): Maybe fine for
> >>>>> convenience, but the basic overload should be String
> >>>>> getTemporalFormat(Class<? extends Temporal> temporalClass), as this
> >>>>> function doesn't really care about the instance.
> >>>>>
> >>>>>
> >>>>> When you have the CLA (and are yo sure that your employee can't claim
> >>>> this
> >>>>> or such), we can merge into the FREEMARKER-35 branch. When it's
> >>>> finished,
> >>>>> which also means the me or some others here went through it, polished
> >>>> it,
> >>>>> etc., then it will be merged into the 2.3-gae branch.
> >>>>>
> >>>>> Thanks!
> >>>>
> >>>>
> >>>
> >>> --
> >>> Best regards,
> >>> Daniel Dekany
> >>>
> >>
> >>
> >> --
> >> Best regards,
> >> Daniel Dekany
> >
>
>
--
Best regards,
Daniel Dekany
Re: Contributing to FREEMARKER-35: JSR 310 support for java8
java.time.temporal DateTimeFormatter
Posted by Teun <te...@betterbe.com>.
Progress so far:
CLA has been submitted (and accepted i think?)
Pull request was made (see https://github.com/apache/freemarker/pull/65 )
Regards, Teun
> On 2020-03-30, at 00:33, Teun <te...@be.nl> wrote:
>
> Ahh not yet.
> The company i work for said they'd sign the CCLA but i haven't checked the progress on that lately.
> Will check.
>
>> On 2020-03-30, at 00:13, Daniel Dekany <da...@gmail.com> wrote:
>>
>> Err.. I mean, the CLA.
>>
>> On Mon, Mar 30, 2020 at 12:12 AM Daniel Dekany <da...@gmail.com>
>> wrote:
>>
>>> Hi Teun,
>>>
>>> Did you submit the CLI?
>>>
>>> On Wed, Feb 26, 2020 at 4:17 PM Teun <te...@betterbe.com> wrote:
>>>
>>>> Fixed the two random small things.
>>>> I'll try to submit the CLA request.
>>>>
>>>> Regards, Teun
>>>>
>>>>> On 2020-02-24, at 22:04, Daniel Dekany <da...@gmail.com> wrote:
>>>>>
>>>>> OK, great!
>>>>>
>>>>> Two random small things that I happened to spot (but eventually I will
>>>> go
>>>>> through all this properly):
>>>>>
>>>>> - Instead of things like YEARMONTH_FORMAT_KEY_CAMEL_CASE,
>>>>> "yearmonth_format", and "year_month_format", let's use the more
>>>> natural
>>>>> YEAR_MONTH_FORMAT, "year_month_format", and "yearMonthFormat". Same
>>>> for the
>>>>> other temporal types as well. I assume you just tried to be
>>>> consistent with
>>>>> "datetime", but that's actually a mistake (that's the SQL-ish name of
>>>> the
>>>>> type, that somehow get into releases unfortunately... maybe we should
>>>> add
>>>>> date_time etc. as an alias).
>>>>> - String getTemporalFormat(Temporal temporal): Maybe fine for
>>>>> convenience, but the basic overload should be String
>>>>> getTemporalFormat(Class<? extends Temporal> temporalClass), as this
>>>>> function doesn't really care about the instance.
>>>>>
>>>>>
>>>>> When you have the CLA (and are yo sure that your employee can't claim
>>>> this
>>>>> or such), we can merge into the FREEMARKER-35 branch. When it's
>>>> finished,
>>>>> which also means the me or some others here went through it, polished
>>>> it,
>>>>> etc., then it will be merged into the 2.3-gae branch.
>>>>>
>>>>> Thanks!
>>>>
>>>>
>>>
>>> --
>>> Best regards,
>>> Daniel Dekany
>>>
>>
>>
>> --
>> Best regards,
>> Daniel Dekany
>
Re: Contributing to FREEMARKER-35: JSR 310 support for java8
java.time.temporal DateTimeFormatter
Posted by Teun <te...@betterbe.com>.
Ahh not yet.
The company i work for said they'd sign the CCLA but i haven't checked the progress on that lately.
Will check.
> On 2020-03-30, at 00:13, Daniel Dekany <da...@gmail.com> wrote:
>
> Err.. I mean, the CLA.
>
> On Mon, Mar 30, 2020 at 12:12 AM Daniel Dekany <da...@gmail.com>
> wrote:
>
>> Hi Teun,
>>
>> Did you submit the CLI?
>>
>> On Wed, Feb 26, 2020 at 4:17 PM Teun <te...@betterbe.com> wrote:
>>
>>> Fixed the two random small things.
>>> I'll try to submit the CLA request.
>>>
>>> Regards, Teun
>>>
>>>> On 2020-02-24, at 22:04, Daniel Dekany <da...@gmail.com> wrote:
>>>>
>>>> OK, great!
>>>>
>>>> Two random small things that I happened to spot (but eventually I will
>>> go
>>>> through all this properly):
>>>>
>>>> - Instead of things like YEARMONTH_FORMAT_KEY_CAMEL_CASE,
>>>> "yearmonth_format", and "year_month_format", let's use the more
>>> natural
>>>> YEAR_MONTH_FORMAT, "year_month_format", and "yearMonthFormat". Same
>>> for the
>>>> other temporal types as well. I assume you just tried to be
>>> consistent with
>>>> "datetime", but that's actually a mistake (that's the SQL-ish name of
>>> the
>>>> type, that somehow get into releases unfortunately... maybe we should
>>> add
>>>> date_time etc. as an alias).
>>>> - String getTemporalFormat(Temporal temporal): Maybe fine for
>>>> convenience, but the basic overload should be String
>>>> getTemporalFormat(Class<? extends Temporal> temporalClass), as this
>>>> function doesn't really care about the instance.
>>>>
>>>>
>>>> When you have the CLA (and are yo sure that your employee can't claim
>>> this
>>>> or such), we can merge into the FREEMARKER-35 branch. When it's
>>> finished,
>>>> which also means the me or some others here went through it, polished
>>> it,
>>>> etc., then it will be merged into the 2.3-gae branch.
>>>>
>>>> Thanks!
>>>
>>>
>>
>> --
>> Best regards,
>> Daniel Dekany
>>
>
>
> --
> Best regards,
> Daniel Dekany
Re: Contributing to FREEMARKER-35: JSR 310 support for java8
java.time.temporal DateTimeFormatter
Posted by Daniel Dekany <da...@gmail.com>.
Err.. I mean, the CLA.
On Mon, Mar 30, 2020 at 12:12 AM Daniel Dekany <da...@gmail.com>
wrote:
> Hi Teun,
>
> Did you submit the CLI?
>
> On Wed, Feb 26, 2020 at 4:17 PM Teun <te...@betterbe.com> wrote:
>
>> Fixed the two random small things.
>> I'll try to submit the CLA request.
>>
>> Regards, Teun
>>
>> > On 2020-02-24, at 22:04, Daniel Dekany <da...@gmail.com> wrote:
>> >
>> > OK, great!
>> >
>> > Two random small things that I happened to spot (but eventually I will
>> go
>> > through all this properly):
>> >
>> > - Instead of things like YEARMONTH_FORMAT_KEY_CAMEL_CASE,
>> > "yearmonth_format", and "year_month_format", let's use the more
>> natural
>> > YEAR_MONTH_FORMAT, "year_month_format", and "yearMonthFormat". Same
>> for the
>> > other temporal types as well. I assume you just tried to be
>> consistent with
>> > "datetime", but that's actually a mistake (that's the SQL-ish name of
>> the
>> > type, that somehow get into releases unfortunately... maybe we should
>> add
>> > date_time etc. as an alias).
>> > - String getTemporalFormat(Temporal temporal): Maybe fine for
>> > convenience, but the basic overload should be String
>> > getTemporalFormat(Class<? extends Temporal> temporalClass), as this
>> > function doesn't really care about the instance.
>> >
>> >
>> > When you have the CLA (and are yo sure that your employee can't claim
>> this
>> > or such), we can merge into the FREEMARKER-35 branch. When it's
>> finished,
>> > which also means the me or some others here went through it, polished
>> it,
>> > etc., then it will be merged into the 2.3-gae branch.
>> >
>> > Thanks!
>>
>>
>
> --
> Best regards,
> Daniel Dekany
>
--
Best regards,
Daniel Dekany