11:57 p.m.
Hey guys,
There are currently 2 outstanding issues in the RichFaces 4.5.0.Beta1
effort:
1) Object-based autocomplete (RF-11453/RF-11332)
2) Placeholder duplicate rendering (RF-13769)
I've got a PoC of 1) working locally. At least it's a select component
that starts out with an empty suggestion list, and updates it via ajax
once you start typing. I just need to work out the server-side
filtering function and resolve some buggy behavior on the client. I
expect to finish tomorrow and it should make a reasonable initial
implementation.
I have not yet had a chance to look into 2). @Michal if you could dive
a little deeper into that issue tomorrow that would be great. I can
pick it up with you once I resolve 1).
Cody Lerum has a pull request in with a guava update. I'll merge that
tomorrow.
With the above issues resolved Beta1 should be in shape for QA.
Brian
12:08 a.m.
We'll we've had a significant amount of scope creep into 4.5.0.Beta1.
Things seem to be well in-hand now though. The remaining issues can be
seen in the rapid board:
https://issues.jboss.org/secure/RapidBoard.jspa?rapidView=331&view=de...
We'll wrap up the remaining issues next week and then get started on QA.
Brian
On 14-08-12 09:57 PM, Brian Leathem wrote:
Hey guys,
There are currently 2 outstanding issues in the RichFaces 4.5.0.Beta1
effort:
1) Object-based autocomplete (RF-11453/RF-11332)
2) Placeholder duplicate rendering (RF-13769)
I've got a PoC of 1) working locally. At least it's a select component
that starts out with an empty suggestion list, and updates it via ajax
once you start typing. I just need to work out the server-side
filtering function and resolve some buggy behavior on the client. I
expect to finish tomorrow and it should make a reasonable initial
implementation.
I have not yet had a chance to look into 2). @Michal if you could dive
a little deeper into that issue tomorrow that would be great. I can
pick it up with you once I resolve 1).
Cody Lerum has a pull request in with a guava update. I'll merge that
tomorrow.
With the above issues resolved Beta1 should be in shape for QA.
Brian
6:27 a.m.
There's now one remaining RFPL issue which I'll sort tomorrow. I see the last few
Jenkins builds have failed on javadoc generation but my local release verification of
Beta1 passed fine (and the generated javadoc seems to be ok). Assuming this is not a
serious issue I can stage 4.5.0.Beta1 tomorrow.
Posted by forums
Original post: https://community.jboss.org/message/901571#901571
12:23 a.m.
Nice work Michal and QE team!
On Aug 21, 2014 8:27 AM, "Michal Petrov" <richfaces-dev(a)lists.jboss.org>
wrote:
There's now one remaining RFPL issue which I'll sort
tomorrow. I see the
last few Jenkins builds have failed on javadoc generation but my local
release verification of Beta1 passed fine (and the generated javadoc seems
to be ok). Assuming this is not a serious issue I can stage 4.5.0.Beta1
tomorrow.
Posted by forums
Original post: https://community.jboss.org/message/901571#901571
_______________________________________________
richfaces-dev mailing list
richfaces-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/richfaces-dev
7:17 a.m.
New subject: Showcase integration test - one difference to framework tests
Hello all,
during migrating of Showcase tests, I have encounter a problem with choosing the right
showcase classifier (jbas71, tomcat6) for deployed tests.
Therefore, when executing tests, one has to provide -Dcontainer.classifier=jbas71 or
-Dcontainer.classifier among the others properties. It applies only when executing tests
with different than -Dintegration=wildfly81 profile.
It is caused with Maven insufficient job regarding to the <activation> property for
profiles. That is why release profile is triggered once integration property is set.
I just wanted point out this thing. Do you think my solution is enough (the only one at
lease somehow nice among the very ugly ones) ? Should I document it ?
Thanks
Best regards
Juro
7:34 a.m.
New subject: Showcase integration test - one difference to framework tests
I think this is a good viable solution.
And yea, I totally think this should be documented in order to avoid future
misunderstandings.
Matej
----- Original Message -----
From: "Juraj Huska" <jhuska(a)redhat.com>
To: richfaces-dev(a)lists.jboss.org
Sent: Monday, August 25, 2014 2:17:32 PM
Subject: Showcase integration test - one difference to framework tests
Hello all,
during migrating of Showcase tests, I have encounter a problem with choosing the right
showcase classifier (jbas71, tomcat6) for deployed tests.
Therefore, when executing tests, one has to provide -Dcontainer.classifier=jbas71 or
-Dcontainer.classifier among the others properties. It applies only when executing tests
with different than -Dintegration=wildfly81 profile.
It is caused with Maven insufficient job regarding to the <activation> property for
profiles. That is why release profile is triggered once integration property is set.
I just wanted point out this thing. Do you think my solution is enough (the only one at
lease somehow nice among the very ugly ones) ? Should I document it ?
Thanks
Best regards
Juro
_______________________________________________
richfaces-dev mailing list
richfaces-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/richfaces-dev
4055
days inactive
4067
days old
5 comments
4 participants
participants (4)
-
Brian Leathem -
Juraj Huska -
Matej Novotny -
Michal Petrov