5.5 anyone?

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

5.5 anyone?

Jochen Kemnade-3
Hi,

I'd like to hear some opinions about how we should proceed with the
Tapestry development.

Which are the things we want to do for 5.5?
What are the things we want to do for 5.4.x?
Do we want to create a 5.4 branch and start progress on 5.5 right away?

I'll go ahead and open the discussion with this proposal:

I'd like to start working toward 5.5 pretty soon and I'd like it to take
much less time than 5.4 did.
For 5.5, I'd like to require Java 8, update some libraries, maybe add
support for Geb tests, and remove some deprecated code. That's basically it.
As Java 8 and some library updates can't be done for 5.4.x, I'd create a
5.4 branch right now and do the updates in master.
I'd prefer if we concentrated on the 5.5 release and only backport bug
fixes to the 5.4 branch. I hope we can get 5.5.0 out soon so we won't
need to do too many 5.4.x releases.

Now let's hear some other opinions. :-)

Jochen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 5.5 anyone?

JumpStart
Hi Jochen,

For 5.4.x:

I think there are some loose ends that trip up the newbie and the experienced alike:

- Grid needs a context to properly participate in AJAX pages
        https://issues.apache.org/jira/browse/TAP5-2297 
        Please note that the issue has a link to a working solution.

- type="number" fails when decimal separator isn't "."
        https://issues.apache.org/jira/browse/TAP5-2409

- Form and BeanEditForm differ in JSR-303 detection
        https://issues.apache.org/jira/browse/TAP5-2255

- Checkbox doesn't trigger VALIDATE event
        https://issues.apache.org/jira/browse/TAP5-2075

- Tree's standard use case needs to be documented
        https://issues.apache.org/jira/browse/TAP5-1921

For 5.5:

I like your 5.5 list, and I like that it’s short and very quickly achievable, but I’d also like people to consider the following item. Without it, we’re holding back AJAX users or sending them off to client-side frameworks.

- Client-side publish/subscribe mechanism
        https://issues.apache.org/jira/browse/TAP5-2416

Geoff

> On 29 Dec 2015, at 11:41 PM, Jochen Kemnade <[hidden email]> wrote:
>
> Hi,
>
> I'd like to hear some opinions about how we should proceed with the Tapestry development.
>
> Which are the things we want to do for 5.5?
> What are the things we want to do for 5.4.x?
> Do we want to create a 5.4 branch and start progress on 5.5 right away?
>
> I'll go ahead and open the discussion with this proposal:
>
> I'd like to start working toward 5.5 pretty soon and I'd like it to take much less time than 5.4 did.
> For 5.5, I'd like to require Java 8, update some libraries, maybe add support for Geb tests, and remove some deprecated code. That's basically it.
> As Java 8 and some library updates can't be done for 5.4.x, I'd create a 5.4 branch right now and do the updates in master.
> I'd prefer if we concentrated on the 5.5 release and only backport bug fixes to the 5.4 branch. I hope we can get 5.5.0 out soon so we won't need to do too many 5.4.x releases.
>
> Now let's hear some other opinions. :-)
>
> Jochen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 5.5 anyone?

Kalle Korhonen-2
In reply to this post by Jochen Kemnade-3
I like your plan actually. Generally, I'd like to make it better and easier
to use Tapestry as a REST backend (as related to the recent discussions on
the user list) but I really don't want to bring in another dependency and
in all honesty, most of the integrations to third-party libraries are much
better of at Github than at Apache.

Kalle

On Tue, Dec 29, 2015 at 7:41 AM, Jochen Kemnade <[hidden email]>
wrote:

> Hi,
>
> I'd like to hear some opinions about how we should proceed with the
> Tapestry development.
>
> Which are the things we want to do for 5.5?
> What are the things we want to do for 5.4.x?
> Do we want to create a 5.4 branch and start progress on 5.5 right away?
>
> I'll go ahead and open the discussion with this proposal:
>
> I'd like to start working toward 5.5 pretty soon and I'd like it to take
> much less time than 5.4 did.
> For 5.5, I'd like to require Java 8, update some libraries, maybe add
> support for Geb tests, and remove some deprecated code. That's basically it.
> As Java 8 and some library updates can't be done for 5.4.x, I'd create a
> 5.4 branch right now and do the updates in master.
> I'd prefer if we concentrated on the 5.5 release and only backport bug
> fixes to the 5.4 branch. I hope we can get 5.5.0 out soon so we won't need
> to do too many 5.4.x releases.
>
> Now let's hear some other opinions. :-)
>
> Jochen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: 5.5 anyone?

Jochen Kemnade-3
In reply to this post by JumpStart
Hi Geoff,

thanks for sharing your thoughts.

----- On Dec 30, 2015, at 3:04 AM, JumpStart [hidden email] wrote:
> - Grid needs a context to properly participate in AJAX pages
> https://issues.apache.org/jira/browse/TAP5-2297
> Please note that the issue has a link to a working solution.

I haven't had the chance to look into this issue. I'd appreciate a patch or some code snippets that demonstrate the problem.

> - type="number" fails when decimal separator isn't "."
> https://issues.apache.org/jira/browse/TAP5-2409

I'll have another look at that one.

> - Form and BeanEditForm differ in JSR-303 detection
> https://issues.apache.org/jira/browse/TAP5-2255

That one's actually waiting for a comment from you, Geoff. ;-) Can you find a simpler example that doesn't need Joda-Time?

> - Checkbox doesn't trigger VALIDATE event
> https://issues.apache.org/jira/browse/TAP5-2075

That one has a patch but no test. I really like tests. ;-)

> - Tree's standard use case needs to be documented
> https://issues.apache.org/jira/browse/TAP5-1921

Everyone's invited to help out with that one. There are some sources linked that can provide some inspiration.

> For 5.5:
>
> I like your 5.5 list, and I like that it’s short and very quickly achievable,
> but I’d also like people to consider the following item. Without it, we’re
> holding back AJAX users or sending them off to client-side frameworks.
>
> - Client-side publish/subscribe mechanism
> https://issues.apache.org/jira/browse/TAP5-2416

I have outlined a solution on the issue. If we agree on a solution, we can probably wrap it into an API.

Jochen


>> On 29 Dec 2015, at 11:41 PM, Jochen Kemnade <[hidden email]> wrote:
>>
>> Hi,
>>
>> I'd like to hear some opinions about how we should proceed with the Tapestry
>> development.
>>
>> Which are the things we want to do for 5.5?
>> What are the things we want to do for 5.4.x?
>> Do we want to create a 5.4 branch and start progress on 5.5 right away?
>>
>> I'll go ahead and open the discussion with this proposal:
>>
>> I'd like to start working toward 5.5 pretty soon and I'd like it to take much
>> less time than 5.4 did.
>> For 5.5, I'd like to require Java 8, update some libraries, maybe add support
>> for Geb tests, and remove some deprecated code. That's basically it.
>> As Java 8 and some library updates can't be done for 5.4.x, I'd create a 5.4
>> branch right now and do the updates in master.
>> I'd prefer if we concentrated on the 5.5 release and only backport bug fixes to
>> the 5.4 branch. I hope we can get 5.5.0 out soon so we won't need to do too
>> many 5.4.x releases.
>>
>> Now let's hear some other opinions. :-)
>>
>> Jochen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 5.5 anyone?

Jochen Kemnade-3
In reply to this post by Kalle Korhonen-2
Kalle,

----- On Dec 30, 2015, at 7:38 AM, Kalle Korhonen [hidden email] wrote:
> I like your plan actually. Generally, I'd like to make it better and easier
> to use Tapestry as a REST backend (as related to the recent discussions on
> the user list) but I really don't want to bring in another dependency and
> in all honesty, most of the integrations to third-party libraries are much
> better of at Github than at Apache.

So true. Talking about third-party libraries, I think https://tapestry.apache.org/third-party-modules.html is a bit out of date.
Maybe we should re-organize the list by the Tapestry version(s) that the libraries are compatible with.
But I also wonder if Confluence is the best way for this kind of information and which alternatives we have.

Jochen

>
> Kalle
>
> On Tue, Dec 29, 2015 at 7:41 AM, Jochen Kemnade <[hidden email]>
> wrote:
>
>> Hi,
>>
>> I'd like to hear some opinions about how we should proceed with the
>> Tapestry development.
>>
>> Which are the things we want to do for 5.5?
>> What are the things we want to do for 5.4.x?
>> Do we want to create a 5.4 branch and start progress on 5.5 right away?
>>
>> I'll go ahead and open the discussion with this proposal:
>>
>> I'd like to start working toward 5.5 pretty soon and I'd like it to take
>> much less time than 5.4 did.
>> For 5.5, I'd like to require Java 8, update some libraries, maybe add
>> support for Geb tests, and remove some deprecated code. That's basically it.
>> As Java 8 and some library updates can't be done for 5.4.x, I'd create a
>> 5.4 branch right now and do the updates in master.
>> I'd prefer if we concentrated on the 5.5 release and only backport bug
>> fixes to the 5.4 branch. I hope we can get 5.5.0 out soon so we won't need
>> to do too many 5.4.x releases.
>>
>> Now let's hear some other opinions. :-)
>>
>> Jochen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 5.5 anyone?

JumpStart
In reply to this post by Jochen Kemnade-3
Thanks for the quick response. Unfortunately I’m really tied up at the moment, so even JumpStart for Tapestry 5.4 has to wait for a bit.

> On 30 Dec 2015, at 3:30 PM, Jochen Kemnade <[hidden email]> wrote:
>
> Hi Geoff,
>
> thanks for sharing your thoughts.
>
> ----- On Dec 30, 2015, at 3:04 AM, JumpStart [hidden email] wrote:
>> - Grid needs a context to properly participate in AJAX pages
>> https://issues.apache.org/jira/browse/TAP5-2297
>> Please note that the issue has a link to a working solution.
>
> I haven't had the chance to look into this issue. I'd appreciate a patch or some code snippets that demonstrate the problem.
>
>> - type="number" fails when decimal separator isn't "."
>> https://issues.apache.org/jira/browse/TAP5-2409
>
> I'll have another look at that one.
>
>> - Form and BeanEditForm differ in JSR-303 detection
>> https://issues.apache.org/jira/browse/TAP5-2255
>
> That one's actually waiting for a comment from you, Geoff. ;-) Can you find a simpler example that doesn't need Joda-Time?
>
>> - Checkbox doesn't trigger VALIDATE event
>> https://issues.apache.org/jira/browse/TAP5-2075
>
> That one has a patch but no test. I really like tests. ;-)
>
>> - Tree's standard use case needs to be documented
>> https://issues.apache.org/jira/browse/TAP5-1921
>
> Everyone's invited to help out with that one. There are some sources linked that can provide some inspiration.
>
>> For 5.5:
>>
>> I like your 5.5 list, and I like that it’s short and very quickly achievable,
>> but I’d also like people to consider the following item. Without it, we’re
>> holding back AJAX users or sending them off to client-side frameworks.
>>
>> - Client-side publish/subscribe mechanism
>> https://issues.apache.org/jira/browse/TAP5-2416
>
> I have outlined a solution on the issue. If we agree on a solution, we can probably wrap it into an API.
>
> Jochen
>
>
>>> On 29 Dec 2015, at 11:41 PM, Jochen Kemnade <[hidden email]> wrote:
>>>
>>> Hi,
>>>
>>> I'd like to hear some opinions about how we should proceed with the Tapestry
>>> development.
>>>
>>> Which are the things we want to do for 5.5?
>>> What are the things we want to do for 5.4.x?
>>> Do we want to create a 5.4 branch and start progress on 5.5 right away?
>>>
>>> I'll go ahead and open the discussion with this proposal:
>>>
>>> I'd like to start working toward 5.5 pretty soon and I'd like it to take much
>>> less time than 5.4 did.
>>> For 5.5, I'd like to require Java 8, update some libraries, maybe add support
>>> for Geb tests, and remove some deprecated code. That's basically it.
>>> As Java 8 and some library updates can't be done for 5.4.x, I'd create a 5.4
>>> branch right now and do the updates in master.
>>> I'd prefer if we concentrated on the 5.5 release and only backport bug fixes to
>>> the 5.4 branch. I hope we can get 5.5.0 out soon so we won't need to do too
>>> many 5.4.x releases.
>>>
>>> Now let's hear some other opinions. :-)
>>>
>>> Jochen
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 5.5 anyone?

Thiago H de Paula Figueiredo
In reply to this post by Jochen Kemnade-3
On Tue, 29 Dec 2015 13:41:55 -0200, Jochen Kemnade  
<[hidden email]> wrote:

> Hi,

Hello, guys! I'm sorry for the very belated answer . . .

> I'd like to hear some opinions about how we should proceed with the  
> Tapestry development.
>
> Which are the things we want to do for 5.5?

I'd like to see an easier way to invoke Tapestry server-side events from  
JavaScript (https://issues.apache.org/jira/browse/TAP5-2225 has me and  
Jochen discussing some ideas) and better REST support (not just GET and  
POST). That's my main wishes. The AJAX thing could be easily backported to  
5.4.x when it's done.

> Do we want to create a 5.4 branch and start progress on 5.5 right away?

Yes. :)

> For 5.5, I'd like to require Java 8, update some libraries, maybe add  
> support for Geb tests, and remove some deprecated code. That's basically  
> it.

Regarding requiring Java 8 for 5.5, I think we need to discuss what are  
the pros and cons and then check the cost-benefit ratio. So far, Java 6 is  
required. Unfortunately, some companies are still stuck with pre-8 Java  
versions, even if 7 was already end-of-lined in April 2015  
(http://www.oracle.com/technetwork/java/eol-135779.html). I'm not against  
it. Java 8 is great. It's just about not imposing a requirement without  
disregarding the consequences.

> As Java 8 and some library updates can't be done for 5.4.x,

I don't think we can.

> I'd create a 5.4 branch right now and do the updates in master.

Thanks!

> I'd prefer if we concentrated on the 5.5 release and only backport bug  
> fixes to the 5.4 branch.

Some more important issues may need to be backported, like the ones Geoff  
mentioned. But I guess they're bugs anyway . . .

> I hope we can get 5.5.0 out soon so we won't need to do too many 5.4.x  
> releases.

Agreed.

--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 5.5 anyone?

Michael Gentry-2
On Fri, Jan 22, 2016 at 8:31 AM, Thiago H de Paula Figueiredo <
[hidden email]> wrote:

> Regarding requiring Java 8 for 5.5, I think we need to discuss what are
> the pros and cons and then check the cost-benefit ratio. So far, Java 6 is
> required. Unfortunately, some companies are still stuck with pre-8 Java
> versions, even if 7 was already end-of-lined in April 2015 (
> http://www.oracle.com/technetwork/java/eol-135779.html). I'm not against
> it. Java 8 is great. It's just about not imposing a requirement without
> disregarding the consequences.


I recently worked at a place (hi Bob!) that finally got all of their
developers off Java 6 (there were some stragglers due to hardware issues).
Given that Tapestry 5.5 won't be out for a bit, I think Java 7 as a minimum
would be quite acceptable to most end users and would not prohibit them
from using Java 8+ for their Tapestry development/deployment while still
supporting those "stuck" on Java 7.  Generally, I think it is better for a
framework to support an older Java version for greater compatibility with
the user base, even if the majority of the user community is using a higher
version.

Thanks,

mrg
Reply | Threaded
Open this post in threaded view
|

Re: 5.5 anyone?

Jochen Kemnade-3
Hi,

I expected that someone would bring up this point. I know how hard it is
to get a large company to use up-to-date software.
However, I don't think that this should stop us from requiring Java 8.
First of all, you can use a separate JRE/JDK to run your Tapestry
application, you just need to set your JAVA_HOME accordingly, and
second, if we switch to Java 8, that doen't mean that we force anyone to
use Java 8 features, it should still compile and run Java 5 code fine.
But it would give us the possibility to use Java 8 features inside
Tapestry and update some outdated libraries that require it.
By the way, if we don't switch to Java 8, I guess we don't need to
branch and create a 5.5 release in the first place. I don't think that
we would benefit much from requiring Java 7.

Jochen

Am 22.01.2016 um 16:03 schrieb Michael Gentry:

> I recently worked at a place (hi Bob!) that finally got all of their
> developers off Java 6 (there were some stragglers due to hardware issues).
> Given that Tapestry 5.5 won't be out for a bit, I think Java 7 as a minimum
> would be quite acceptable to most end users and would not prohibit them
> from using Java 8+ for their Tapestry development/deployment while still
> supporting those "stuck" on Java 7.  Generally, I think it is better for a
> framework to support an older Java version for greater compatibility with
> the user base, even if the majority of the user community is using a higher
> version.
>
> Thanks,
>
> mrg
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 5.5 anyone?

JumpStart
+1 for using Java 8 for all the reasons you mention, Jochen. Java 8 is almost 2 years old and Java 7 had its final public update almost a year ago.

+1 for supporting users on older versions, but no need to consider earlier than Java 5. Java 5 is 12 years old and had its final public update 6 years ago!

> On 26 Jan 2016, at 4:29 PM, Jochen Kemnade <[hidden email]> wrote:
>
> Hi,
>
> I expected that someone would bring up this point. I know how hard it is to get a large company to use up-to-date software.
> However, I don't think that this should stop us from requiring Java 8. First of all, you can use a separate JRE/JDK to run your Tapestry application, you just need to set your JAVA_HOME accordingly, and second, if we switch to Java 8, that doen't mean that we force anyone to use Java 8 features, it should still compile and run Java 5 code fine. But it would give us the possibility to use Java 8 features inside Tapestry and update some outdated libraries that require it.
> By the way, if we don't switch to Java 8, I guess we don't need to branch and create a 5.5 release in the first place. I don't think that we would benefit much from requiring Java 7.
>
> Jochen
>
> Am 22.01.2016 um 16:03 schrieb Michael Gentry:
>
>> I recently worked at a place (hi Bob!) that finally got all of their
>> developers off Java 6 (there were some stragglers due to hardware issues).
>> Given that Tapestry 5.5 won't be out for a bit, I think Java 7 as a minimum
>> would be quite acceptable to most end users and would not prohibit them
>> from using Java 8+ for their Tapestry development/deployment while still
>> supporting those "stuck" on Java 7.  Generally, I think it is better for a
>> framework to support an older Java version for greater compatibility with
>> the user base, even if the majority of the user community is using a higher
>> version.
>>
>> Thanks,
>>
>> mrg
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 5.5 anyone?

Thiago H de Paula Figueiredo
In reply to this post by Jochen Kemnade-3
On Tue, 26 Jan 2016 06:29:58 -0200, Jochen Kemnade  
<[hidden email]> wrote:

> Hi,

Hi!

> I expected that someone would bring up this point. I know how hard it is  
> to get a large company to use up-to-date software.
> However, I don't think that this should stop us from requiring Java 8.  
> First of all, you can use a separate JRE/JDK to run your Tapestry  
> application, you just need to set your JAVA_HOME accordingly, and  
> second, if we switch to Java 8, that doen't mean that we force anyone to  
> use Java 8 features, it should still compile and run Java 5 code fine.

But, in order to have Tapestry using Java 8 in its sources and compile to  
Java 6 or 7 we will be able to use most of the new syntax, but none of the  
Java 8-introduced classes and interfaces like streams. I'm not sure how  
much we can use Java 8 in Tapestry keeping it runnable under Java 7. Of  
course, this is someone we should research.

--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 5.5 anyone?

bobharner
I don't think Jochen was proposing compiling Tapestry to anything other
that a 1.8 level, only that if Tapestry forces users to use a 1.8 runtime
then it doesn't mean they are forced to use 1.8 features.

I'm +1 with 5.4 being maintained for jre 1.6 or 1.7 and Tapestry 5.5 being
for jre 1.8 users, because 1) it's a way to keep devs interested, and 2)
the potential advantages of 1.8 are huge for Tapestry. One of the biggest
would be the ability to change interfaces without breaking backward
compatibility (via default methods).
On Jan 26, 2016 7:32 AM, "Thiago H de Paula Figueiredo" <[hidden email]>
wrote:

> On Tue, 26 Jan 2016 06:29:58 -0200, Jochen Kemnade <
> [hidden email]> wrote:
>
> Hi,
>>
>
> Hi!
>
> I expected that someone would bring up this point. I know how hard it is
>> to get a large company to use up-to-date software.
>> However, I don't think that this should stop us from requiring Java 8.
>> First of all, you can use a separate JRE/JDK to run your Tapestry
>> application, you just need to set your JAVA_HOME accordingly, and second,
>> if we switch to Java 8, that doen't mean that we force anyone to use Java 8
>> features, it should still compile and run Java 5 code fine.
>>
>
> But, in order to have Tapestry using Java 8 in its sources and compile to
> Java 6 or 7 we will be able to use most of the new syntax, but none of the
> Java 8-introduced classes and interfaces like streams. I'm not sure how
> much we can use Java 8 in Tapestry keeping it runnable under Java 7. Of
> course, this is someone we should research.
>
> --
> Thiago H. de Paula Figueiredo
> Tapestry, Java and Hibernate consultant and developer
> http://machina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: 5.5 anyone?

Jochen Kemnade-4
Yes, I meant compiling for 1.8, but Thiago's idea is interesting. Can
default methods and lambdas actually be compiled to binary code that runs
on Java 7 or even 6? That would indeed be a viable option, maybe even for
5.4.

Bob Harner <[hidden email]> schrieb am Di., 26. Jan. 2016 17:52:

> I don't think Jochen was proposing compiling Tapestry to anything other
> that a 1.8 level, only that if Tapestry forces users to use a 1.8 runtime
> then it doesn't mean they are forced to use 1.8 features.
>
> I'm +1 with 5.4 being maintained for jre 1.6 or 1.7 and Tapestry 5.5 being
> for jre 1.8 users, because 1) it's a way to keep devs interested, and 2)
> the potential advantages of 1.8 are huge for Tapestry. One of the biggest
> would be the ability to change interfaces without breaking backward
> compatibility (via default methods).
> On Jan 26, 2016 7:32 AM, "Thiago H de Paula Figueiredo" <
> [hidden email]>
> wrote:
>
> > On Tue, 26 Jan 2016 06:29:58 -0200, Jochen Kemnade <
> > [hidden email]> wrote:
> >
> > Hi,
> >>
> >
> > Hi!
> >
> > I expected that someone would bring up this point. I know how hard it is
> >> to get a large company to use up-to-date software.
> >> However, I don't think that this should stop us from requiring Java 8.
> >> First of all, you can use a separate JRE/JDK to run your Tapestry
> >> application, you just need to set your JAVA_HOME accordingly, and
> second,
> >> if we switch to Java 8, that doen't mean that we force anyone to use
> Java 8
> >> features, it should still compile and run Java 5 code fine.
> >>
> >
> > But, in order to have Tapestry using Java 8 in its sources and compile to
> > Java 6 or 7 we will be able to use most of the new syntax, but none of
> the
> > Java 8-introduced classes and interfaces like streams. I'm not sure how
> > much we can use Java 8 in Tapestry keeping it runnable under Java 7. Of
> > course, this is someone we should research.
> >
> > --
> > Thiago H. de Paula Figueiredo
> > Tapestry, Java and Hibernate consultant and developer
> > http://machina.com.br
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: 5.5 anyone?

Jochen Kemnade-4
However, I know of at least one issue that I'd like to address soon and for
which at least my preferred solution will require Java 8 classes: The
datefield / timezone issue (I'm currently afk so I can't look up the ID).
I'd like to use the new date/time API for that.

Jochen Kemnade <[hidden email]> schrieb am Di., 26. Jan. 2016 18:00:

> Yes, I meant compiling for 1.8, but Thiago's idea is interesting. Can
> default methods and lambdas actually be compiled to binary code that runs
> on Java 7 or even 6? That would indeed be a viable option, maybe even for
> 5.4.
>
> Bob Harner <[hidden email]> schrieb am Di., 26. Jan. 2016 17:52:
>
>> I don't think Jochen was proposing compiling Tapestry to anything other
>> that a 1.8 level, only that if Tapestry forces users to use a 1.8 runtime
>> then it doesn't mean they are forced to use 1.8 features.
>>
>> I'm +1 with 5.4 being maintained for jre 1.6 or 1.7 and Tapestry 5.5 being
>> for jre 1.8 users, because 1) it's a way to keep devs interested, and 2)
>> the potential advantages of 1.8 are huge for Tapestry. One of the biggest
>> would be the ability to change interfaces without breaking backward
>> compatibility (via default methods).
>> On Jan 26, 2016 7:32 AM, "Thiago H de Paula Figueiredo" <
>> [hidden email]>
>> wrote:
>>
>> > On Tue, 26 Jan 2016 06:29:58 -0200, Jochen Kemnade <
>> > [hidden email]> wrote:
>> >
>> > Hi,
>> >>
>> >
>> > Hi!
>> >
>> > I expected that someone would bring up this point. I know how hard it is
>> >> to get a large company to use up-to-date software.
>> >> However, I don't think that this should stop us from requiring Java 8.
>> >> First of all, you can use a separate JRE/JDK to run your Tapestry
>> >> application, you just need to set your JAVA_HOME accordingly, and
>> second,
>> >> if we switch to Java 8, that doen't mean that we force anyone to use
>> Java 8
>> >> features, it should still compile and run Java 5 code fine.
>> >>
>> >
>> > But, in order to have Tapestry using Java 8 in its sources and compile
>> to
>> > Java 6 or 7 we will be able to use most of the new syntax, but none of
>> the
>> > Java 8-introduced classes and interfaces like streams. I'm not sure how
>> > much we can use Java 8 in Tapestry keeping it runnable under Java 7. Of
>> > course, this is someone we should research.
>> >
>> > --
>> > Thiago H. de Paula Figueiredo
>> > Tapestry, Java and Hibernate consultant and developer
>> > http://machina.com.br
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>> >
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: 5.5 anyone?

Martin Grigorov
Hi Jochen,

For Thiago's idea you can try with https://github.com/orfjackal/retrolambda.

On Tue, Jan 26, 2016 at 6:04 PM, Jochen Kemnade <[hidden email]> wrote:

> However, I know of at least one issue that I'd like to address soon and for
> which at least my preferred solution will require Java 8 classes: The
> datefield / timezone issue (I'm currently afk so I can't look up the ID).
> I'd like to use the new date/time API for that.
>

If you use classes which are not available in older JDKs then retrolambda
won't help.
If you want to support older JDKs for this specific case you may use
http://www.threeten.org/ - same classes but in a separate library, not part
of JDK.


>
> Jochen Kemnade <[hidden email]> schrieb am Di., 26. Jan. 2016 18:00:
>
> > Yes, I meant compiling for 1.8, but Thiago's idea is interesting. Can
> > default methods and lambdas actually be compiled to binary code that runs
> > on Java 7 or even 6? That would indeed be a viable option, maybe even for
> > 5.4.
> >
> > Bob Harner <[hidden email]> schrieb am Di., 26. Jan. 2016 17:52:
> >
> >> I don't think Jochen was proposing compiling Tapestry to anything other
> >> that a 1.8 level, only that if Tapestry forces users to use a 1.8
> runtime
> >> then it doesn't mean they are forced to use 1.8 features.
> >>
> >> I'm +1 with 5.4 being maintained for jre 1.6 or 1.7 and Tapestry 5.5
> being
> >> for jre 1.8 users, because 1) it's a way to keep devs interested, and 2)
> >> the potential advantages of 1.8 are huge for Tapestry. One of the
> biggest
> >> would be the ability to change interfaces without breaking backward
> >> compatibility (via default methods).
> >> On Jan 26, 2016 7:32 AM, "Thiago H de Paula Figueiredo" <
> >> [hidden email]>
> >> wrote:
> >>
> >> > On Tue, 26 Jan 2016 06:29:58 -0200, Jochen Kemnade <
> >> > [hidden email]> wrote:
> >> >
> >> > Hi,
> >> >>
> >> >
> >> > Hi!
> >> >
> >> > I expected that someone would bring up this point. I know how hard it
> is
> >> >> to get a large company to use up-to-date software.
> >> >> However, I don't think that this should stop us from requiring Java
> 8.
> >> >> First of all, you can use a separate JRE/JDK to run your Tapestry
> >> >> application, you just need to set your JAVA_HOME accordingly, and
> >> second,
> >> >> if we switch to Java 8, that doen't mean that we force anyone to use
> >> Java 8
> >> >> features, it should still compile and run Java 5 code fine.
> >> >>
> >> >
> >> > But, in order to have Tapestry using Java 8 in its sources and compile
> >> to
> >> > Java 6 or 7 we will be able to use most of the new syntax, but none of
> >> the
> >> > Java 8-introduced classes and interfaces like streams. I'm not sure
> how
> >> > much we can use Java 8 in Tapestry keeping it runnable under Java 7.
> Of
> >> > course, this is someone we should research.
> >> >
> >> > --
> >> > Thiago H. de Paula Figueiredo
> >> > Tapestry, Java and Hibernate consultant and developer
> >> > http://machina.com.br
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: [hidden email]
> >> > For additional commands, e-mail: [hidden email]
> >> >
> >> >
> >>
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: 5.5 anyone?

Thiago H de Paula Figueiredo
In reply to this post by bobharner
On Tue, 26 Jan 2016 14:51:51 -0200, Bob Harner <[hidden email]> wrote:

> I don't think Jochen was proposing compiling Tapestry to anything other
> that a 1.8 level, only that if Tapestry forces users to use a 1.8 runtime
> then it doesn't mean they are forced to use 1.8 features.

Oh, I see that now. I didn't interpret it that way.
But, if we're going to force users to use a 1.8 runtime, I don't see the  
point of not using everything it provides. If someone is already using  
Java 8, I'd expect them to use the full set of features of the language.

> I'm +1 with 5.4 being maintained for jre 1.6 or 1.7 and Tapestry 5.5  
> being for jre 1.8 users, because 1) it's a way to keep devs interested,

I didn't think about this before. Good catch, Bob! I agree with you.

> and 2)
> the potential advantages of 1.8 are huge for Tapestry. One of the biggest
> would be the ability to change interfaces without breaking backward
> compatibility (via default methods).

Agreed. Another thing you've thought and I didn't, Bob. You're making me  
feel embarrassed! hehehe

--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 5.5 anyone?

Kalle Korhonen-2
Having had the luxury of using Java 8 now for a few months in a new green
field project, I fully agree we should go for Java 8 in T5.5. At times,
this version of Java almost feels like a modern language ;) T5.4 is
perfectly fine alternative for those who are not ready to move onto Java 8
and in general, I doubt that there are that many Tapestry users who
couldn't or wouldn't be willing to use the latest and greatest. For better
or worse, Tapestry doesn't quite have the penetration in large
organizations that tend to be more conservative.

On a separate note, I'd like to consider including Dmitry Gusev's excellent
jpa-transactions (https://github.com/satago/tapestry-jpa-transactions) into
T5.5 core. It's a drop-in replacement under Apache license so there
shouldn't be a problem. I'm willing to work on it.

Kalle

On Wed, Jan 27, 2016 at 4:14 AM, Thiago H de Paula Figueiredo <
[hidden email]> wrote:

> On Tue, 26 Jan 2016 14:51:51 -0200, Bob Harner <[hidden email]>
> wrote:
>
> I don't think Jochen was proposing compiling Tapestry to anything other
>> that a 1.8 level, only that if Tapestry forces users to use a 1.8 runtime
>> then it doesn't mean they are forced to use 1.8 features.
>>
>
> Oh, I see that now. I didn't interpret it that way.
> But, if we're going to force users to use a 1.8 runtime, I don't see the
> point of not using everything it provides. If someone is already using Java
> 8, I'd expect them to use the full set of features of the language.
>
> I'm +1 with 5.4 being maintained for jre 1.6 or 1.7 and Tapestry 5.5 being
>> for jre 1.8 users, because 1) it's a way to keep devs interested,
>>
>
> I didn't think about this before. Good catch, Bob! I agree with you.
>
> and 2)
>> the potential advantages of 1.8 are huge for Tapestry. One of the biggest
>> would be the ability to change interfaces without breaking backward
>> compatibility (via default methods).
>>
>
> Agreed. Another thing you've thought and I didn't, Bob. You're making me
> feel embarrassed! hehehe
>
>
> --
> Thiago H. de Paula Figueiredo
> Tapestry, Java and Hibernate consultant and developer
> http://machina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: 5.5 anyone?

Jochen Kemnade-3
> I'm +1 with 5.4 being maintained for jre 1.6 or 1.7 and Tapestry 5.5 being
> for jre 1.8 users

Of course, that means that someone will need to maintain it. I'm not
overly confident that we are going to be able to maintain two release
branches.

So, what do we do now? Do we need a vote?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 5.5 anyone?

bobharner
I'd say just proceed. I don't think a vote is required, especially since
there has been more than a month of discussion and no real objections.
On Feb 2, 2016 6:31 AM, "Jochen Kemnade" <[hidden email]> wrote:

> I'm +1 with 5.4 being maintained for jre 1.6 or 1.7 and Tapestry 5.5 being
>> for jre 1.8 users
>>
>
> Of course, that means that someone will need to maintain it. I'm not
> overly confident that we are going to be able to maintain two release
> branches.
>
> So, what do we do now? Do we need a vote?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: 5.5 anyone?

Kalle Korhonen-2
Now that 5.4.1 is out, it might be a good time to move ahead with this
plan, create a branch for 5.4.x and reserve the master for 5.5 development
with Java 8. I'm much more concerned with degradation of the test suite
(since the tests aren't being run until we can upgrade Selenium) than
merging/backporting everything from 5.5 to 5.4.

Kalle

On Tue, Feb 2, 2016 at 4:28 AM, Bob Harner <[hidden email]> wrote:

> I'd say just proceed. I don't think a vote is required, especially since
> there has been more than a month of discussion and no real objections.
> On Feb 2, 2016 6:31 AM, "Jochen Kemnade" <[hidden email]>
> wrote:
>
> > I'm +1 with 5.4 being maintained for jre 1.6 or 1.7 and Tapestry 5.5
> being
> >> for jre 1.8 users
> >>
> >
> > Of course, that means that someone will need to maintain it. I'm not
> > overly confident that we are going to be able to maintain two release
> > branches.
> >
> > So, what do we do now? Do we need a vote?
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
12