Re: Build failed in Jenkins: tapestry-trunk-freestyle #1204
We could simply take a vote on this - case like this is exactly what the voting procedures at Apache were originally designed for. We'd need to vote on a clearly defined issue, like "do we want to require Java 6 for T5.4 so we can upgrade dependencies that require Java 6, such as the newer closure compiler". Kalle On Tue, May 13, 2014 at 8:31 AM, Jochen Kemnade wrote: > Any new insights on this one? The current master will still FTBFS on Java > 5. > > Am 02.05.2014 18:18, schrieb Kalle Korhonen: > > On Fri, May 2, 2014 at 12:57 AM, Ulrich Stärk wrote: >> >> I don't see the benefits in this. As I said earlier, Java 6 and 7 IMO >>> don't provide enough benefits >>> to justify the change. >>> >>> >> A newer Java version is required if we want to update the closure >> compiler. >> >> Kalle >> >> >> On 2014-05-01 19:01, Kalle Korhonen wrote: >> >>> I agree with Rob. A common sense approach would be to require 1.6 for >>> T5.4 >>> and then require 1.8 in a future version. Kalle On Thu, May 1, 2014 at 9:54 AM, Robert Zeigler wrote: Not opposed to an upgrade to Java 8, but not sure 5.4 is the right time > for it. 5.4 has been long-enough in coming that I feel it would be > better >>> to release 5.4, and use 5.5 as the java8 upgrade, possibly with a fairly > short release time between 5.4 and 5.5. Basically, 5.5 could be “5.4 > with >>> java 8 compatibility” (and whatever new features (like the httpOnly > cookie >>> flag ticket you commented on recently) that would need > java 1.5 to > support). > > Robert > > On May 1, 2014, at 5/111:38 AM , Ulrich Stärk > wrote: > > Historically I have been a strong opponent to Java version upgrades >> for >> > Tapestry because IMO the > >> disadvantages outweighed the advantages by far. >> >> Now that we have lambda expressions, default methods, Nashorn and many >> > other useful features I'm > >> leaning towards making a radical break and switch to Java 8. >> >> We should have a formal vote for such a radical change and a >> discussion >> > firstin order to gather > >> comments and opinions from the community. >> >> Uli >> >> On 2014-04-30 12:57, Jochen Kemnade wrote: >> >>> Am 29.04.2014 21:07, schrieb Jochen Kemnade: >>> I'll downgrade it tomorrow and get myself a Java 1.5 compiler... >>> >>> Which is much harder than I thought it was. I managed to find old >>> >> rt.jar and jce.jar files and to > >> make Gradle use them. >>> Now I'm getting compile errors, e.g. in VirtualResource:88, >>> >> MacOutputStream:45 and others. Mostly, > >> it's Java 6 methods being used. >>> First of all, do we still want to stick with Java 5 now that Java 8 >>> is >>> >> out and even Java 6 is EOL? > >> Second, I wonder why it builds in Jenkins. What JDK is used there? >>> >>> Jochen >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: dev-h...@tapestry.apache.org >>> >>> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: dev-h...@tapestry.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > > > >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: dev-h...@tapestry.apache.org >>> >>> >>> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > >
Re: New beta soon?
I think that's a good idea, thanks for all the work! On Tue, May 13, 2014 at 8:48 AM, Jochen Kemnade wrote: > Hi, > > we have closed 29 issues since the last beta (beta-5) and 52 issues since > the last public one (beta-3). > I think we should create a new beta release soon and maybe even see if we > want to make it a public one. > > Jochen > > - > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com @hlship
Re: Build failed in Jenkins: tapestry-trunk-freestyle #1204
Any new insights on this one? The current master will still FTBFS on Java 5. Am 02.05.2014 18:18, schrieb Kalle Korhonen: On Fri, May 2, 2014 at 12:57 AM, Ulrich Stärk wrote: I don't see the benefits in this. As I said earlier, Java 6 and 7 IMO don't provide enough benefits to justify the change. A newer Java version is required if we want to update the closure compiler. Kalle On 2014-05-01 19:01, Kalle Korhonen wrote: I agree with Rob. A common sense approach would be to require 1.6 for T5.4 and then require 1.8 in a future version. Kalle On Thu, May 1, 2014 at 9:54 AM, Robert Zeigler wrote: Not opposed to an upgrade to Java 8, but not sure 5.4 is the right time for it. 5.4 has been long-enough in coming that I feel it would be better to release 5.4, and use 5.5 as the java8 upgrade, possibly with a fairly short release time between 5.4 and 5.5. Basically, 5.5 could be “5.4 with java 8 compatibility” (and whatever new features (like the httpOnly cookie flag ticket you commented on recently) that would need > java 1.5 to support). Robert On May 1, 2014, at 5/111:38 AM , Ulrich Stärk wrote: Historically I have been a strong opponent to Java version upgrades for Tapestry because IMO the disadvantages outweighed the advantages by far. Now that we have lambda expressions, default methods, Nashorn and many other useful features I'm leaning towards making a radical break and switch to Java 8. We should have a formal vote for such a radical change and a discussion firstin order to gather comments and opinions from the community. Uli On 2014-04-30 12:57, Jochen Kemnade wrote: Am 29.04.2014 21:07, schrieb Jochen Kemnade: I'll downgrade it tomorrow and get myself a Java 1.5 compiler... Which is much harder than I thought it was. I managed to find old rt.jar and jce.jar files and to make Gradle use them. Now I'm getting compile errors, e.g. in VirtualResource:88, MacOutputStream:45 and others. Mostly, it's Java 6 methods being used. First of all, do we still want to stick with Java 5 now that Java 8 is out and even Java 6 is EOL? Second, I wonder why it builds in Jenkins. What JDK is used there? Jochen - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
New beta soon?
Hi, we have closed 29 issues since the last beta (beta-5) and 52 issues since the last public one (beta-3). I think we should create a new beta release soon and maybe even see if we want to make it a public one. Jochen - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Issues with bulk-close-candidate label
Alright, I just closed the issues that have not been modified since Uli's comment. I also removed the bulk-close-candidate from the ones that had newer changes. Now, do we want to repeat the process with project = TAP5 AND status = Open AND assignee in (EMPTY) and affectedVersion not in (5.4, 5.3, 5.3.0, 5.3.1, 5.3.2, 5.3.3, 5.3.4, 5.3.5, 5.3.6, 5.3.7) and updatedDate < "2013-01-01" ? Jochen - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Make more fields/methods of service classes protected
On Tue, 13 May 2014 05:25:22 -0300, Michael Wyraz wrote: Hi Thiago, Hi! I didn't want to argue with you, just wanted to explain my opinion (and understand yours). I can accept the decision to stay with private methods althought I do not agree with you reasons ^^ I'm more than happy to discuss anything related to Tapestry, even the reasons, in which the past and image of Tapestry are a huge factor. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Accessing generic type information of bound parameters
I have added a comment there concerning the behaviour for literal
bindings. But I dont have permission to change the affected version.
Thanks Lance, you're correct of course.
Michael, as this is still relevant to you, could you please update the
"Affects Version/s:" field of your JIRA issue (TAP5-1213) accordingly?
Am 13.05.2014 11:38, schrieb Lance Java:
No, there is no way to access the generic type, this information is
lost
during the compilation process.
That's not actually correct. Lets consider the following class:
public class MyClass {
private List foos;
public List getBars() {
...
}
public void doStuffWithBaz() {
List bazs = new ArrayList();
...
}
}
In this example, the ONLY generic that will be lost after compilation
(due
to type erasure) is Baz. Both Foo and Bar ARE available at runtime.
@see
http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Method.html#getGenericReturnType()
http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Field.html#getGenericType()
-
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
--
Mit freundlichen Grüßen / Kind regards
Michael Wyraz
evermind GmbH
Schorlemmerstraße 1
04155 Leipzig
Tel.: +49 (0)341-25 39 66 - 0
Fax:+49 (0)341-25 39 66 - 1
Funk: +49 (0)177-73 00 00 3
E-Mail: michael.wy...@evermind.de
HRB: 21586
Amtsgericht Leipzig
Geschäftsführer:
Christoph Klemm
-
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: contributeMarkupRenderer missing JavaScriptSupport
Hi Thiago,
thank you a lot. I changed it to
configuration.add("ImportUIStack", importUIStack,
"after:JavaScriptSupport");
This contribution comes from Tapestry's JavaScriptModule. The problem
did not occur in the last hour - I guess it's solved with this change.
Kind Regards,
MIchael.
configuration.add("ImportUIStack", importUIStack);
We run Tapestry 5.4-beta3. The problem is that randomly after
application start JavaScriptSupport is not set on environment. If this
happens, we must restart the apllication to get it work again.
Does anyone have an idea what the problem might be?
You provided your contribution without any ordering constraint. I
cannot look up what's the exact contribution that adds
JavaScriptSupport, but you need to add yours after or before it, I
cannot recall which.
--
Mit freundlichen Grüßen / Kind regards
Michael Wyraz
evermind GmbH
Schorlemmerstraße 1
04155 Leipzig
Tel.: +49 (0)341-25 39 66 - 0
Fax:+49 (0)341-25 39 66 - 1
Funk: +49 (0)177-73 00 00 3
E-Mail: michael.wy...@evermind.de
HRB: 21586
Amtsgericht Leipzig
Geschäftsführer:
Christoph Klemm
Re: Accessing generic type information of bound parameters
Hi Michel, Am 12.05.2014 10:58, schrieb Michael Wyraz: I can access the type of a bound parameter using ComponentResources.getBoundType(parameterName). But for List it returns (of course) List.class. Is there a way to access the generic parameters of the bound type somehow? No, there is no way to access the generic type, this information is lost during the compilation process. I need this for correct (automatic) type coercion in some special cases. You could create custom sub-classes for that purpose, e.g. StringList extends ArrayList. If you have any more questions or suggestions, please take the discussion to the users mailing list. Jochen - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Accessing generic type information of bound parameters
Thanks Lance, you're correct of course.
Michael, as this is still relevant to you, could you please update the
"Affects Version/s:" field of your JIRA issue (TAP5-1213) accordingly?
Am 13.05.2014 11:38, schrieb Lance Java:
No, there is no way to access the generic type, this information is lost
during the compilation process.
That's not actually correct. Lets consider the following class:
public class MyClass {
private List foos;
public List getBars() {
...
}
public void doStuffWithBaz() {
List bazs = new ArrayList();
...
}
}
In this example, the ONLY generic that will be lost after compilation (due
to type erasure) is Baz. Both Foo and Bar ARE available at runtime.
@see
http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Method.html#getGenericReturnType()
http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Field.html#getGenericType()
-
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Accessing generic type information of bound parameters
Just having a quick poke through the code this could be fixed by adding the following methods to the public API. java.lang.reflect.Type PropertyConduit.getPropertyGenericType() java.lang.reflect.Type Binding.getBindingGenericType() java.lang.reflect.Type ComponentResources.getBoundGenericType(String parameterName) I'm guessing that only PropBinding would return a type from getBindingGenericType(). All other bindings would return null.
Re: Accessing generic type information of bound parameters
> No, there is no way to access the generic type, this information is lost
during the compilation process.
That's not actually correct. Lets consider the following class:
public class MyClass {
private List foos;
public List getBars() {
...
}
public void doStuffWithBaz() {
List bazs = new ArrayList();
...
}
}
In this example, the ONLY generic that will be lost after compilation (due
to type erasure) is Baz. Both Foo and Bar ARE available at runtime.
@see
http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Method.html#getGenericReturnType()
http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Field.html#getGenericType()
Re: Make more fields/methods of service classes protected
Hi Thiago, I didn't want to argue with you, just wanted to explain my opinion (and understand yours). I can accept the decision to stay with private methods althought I do not agree with you reasons ^^ I'll continue to discuss smaller changes (in behaviour) here. Kind regards, Michael. Tapestry internal service implementations and all services (unless stated otherwise, as Autocomplete) were written with the assumption that they won't be subclasses. They're not part of the public API and shouldn't be used directly. Period. Why don't you post here what changes of behavior you want to be done in Tapestry sources and, if we all agree, have it done in the source code itself instead of asking us for something too broad as changing methods and fields visibilities? -- Mit freundlichen Grüßen / Kind regards Michael Wyraz evermind GmbH Schorlemmerstraße 1 04155 Leipzig Tel.: +49 (0)341-25 39 66 - 0 Fax:+49 (0)341-25 39 66 - 1 Funk: +49 (0)177-73 00 00 3 E-Mail: michael.wy...@evermind.de HRB: 21586 Amtsgericht Leipzig Geschäftsführer: Christoph Klemm - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
