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.
Tape
> 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() {
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(Stri
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 lo
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
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.
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 (TAP
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 t
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,
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
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 cha
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 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
13 matches
Mail list logo
