Now it fails for me;
not sure if you were expecting that :-)
On Dec 5, 2007 12:10 AM, Andrew Robinson [EMAIL PROTECTED] wrote:
I just checked in the pom.xml that uncovers the broken test cases.
Once they are all fixed, we can set the forkMode back to once for
performance reasons.
Committed
[
https://issues.apache.org/jira/browse/MYFACES-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Weßendorf updated MYFACES-1785:
Resolution: Fixed
Status: Resolved (was: Patch Available)
thx Hazem
On Dec 5, 2007 10:40 AM, Volker Weber [EMAIL PROTECTED] wrote:
Hi,
why should a jsf1.1 extension library require java1.4 support?
+1
tobago requires java1.5.
Trinidad is also requiring Java5.
like in Tobago land, we have a retro-weaver profile in the pom.
it is totally fine running jsf
Hi,
why should a jsf1.1 extension library require java1.4 support?
tobago requires java1.5.
it is totally fine running jsf 1.1 on a java 1.6 environment.
I don't know the details of jsf 1.2 spec, but it seems to me that the
api for javax.faces.convert.Converter is the same, so why must we
a bit higher in the stack trace, I just saw this:
[INFO] [surefire:test]
[INFO] Surefire report directory:
D:\work\Apache\___TRINIDAD_TRUNK\trinidad-impl\target\surefire-reports
javax.faces.FacesException: java.lang.ClassNotFoundException:
But,
I like font and the graphic, of course!!
thx for doing that.
-M
On Dec 5, 2007 2:24 PM, Adonis Raduca [EMAIL PROTECTED] wrote:
Hello
We have a final logo for MyFaces project and also a font that will be used
in all MyFaces projects logo.
Was difficult to choose one from those tree
Thanks Adonis! I don't dislike the lower case m. Even if the name is
officially Apache MyFaces, I guess for the logo a lower case m is just
fine...
Thank you very much! I think it is a great logo.
Bruno
On 05/12/2007, Matthias Wessendorf [EMAIL PROTECTED] wrote:
But,
I like font and the
Hi Simon,
you should add this comment to the JIRA, i don't think Dara is reading here.
and someone @irian should do this at the demo.
Regards,
Volker
2007/12/5, Simon Lessard [EMAIL PROTECTED]:
Hello,
You can set the right timezone in trinidad-config.xml to fix it. However,
use the
Hi,
On Dec 4, 2007 10:45 PM, simon [EMAIL PROTECTED] wrote:
Ok, there's a bug to fix. Yet another reason to get a release out after
it is dealt with. I'll try to look into that bug report sometime in the
next few days if someone else doesn't beat me to it.
not managed to do that, yet.
I
the impl is little different;
ConverterTag is deprecated;
good folks would use ConverterELTag
(same for validator)
which are generated classes (that depend on a JSF 1.1 TAG or a JSF 1.2 one).
Which means that can be done via param (which is now hard-coded in the POM).
-M
I can't agree with this one. If you look at
https://issues.apache.org/jira/browse/TRINIDAD-817 then you'll see that
right timezone in trinidad-config.xml with long time zone name isn't
solving the issue.
Simon Lessard wrote:
Hello,
You can set the right timezone in trinidad-config.xml to
I guess the other option is to take a more segmented approach (like for
configurators) and rate the minimum requirements for each module
separately. But I kind of like the idea of not including a bunch of
different jars if we can help it.
Scott
Scott O'Bryan wrote:
Yeah I agree.
So to
this is great news ?
Is there a blog entry for this ? :)
Please ping the Seam-users (via their forum).
Thanks!!
Next weekend, there is the hackaton, let's wait till then, ok ?
-Matthias
On Dec 5, 2007 7:08 PM, Grant Smith [EMAIL PROTECTED] wrote:
OK I managed to get MyFaces 1.2.1-SNAPSHOT and
[
https://issues.apache.org/jira/browse/ORCHESTRA-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548721
]
Mario Ivankovits commented on ORCHESTRA-13:
---
But the RequestParameterProvidedManager should not see any
this fix is to late;
the release vote is already out.
And for a demo, I am not doing an undo.
-M
On Dec 5, 2007 7:49 PM, [EMAIL PROTECTED] wrote:
Author: slessard
Date: Wed Dec 5 10:49:39 2007
New Revision: 601466
URL: http://svn.apache.org/viewvc?rev=601466view=rev
Log:
Fix in the
+1
On Dec 5, 2007 1:46 PM, Andrew Robinson [EMAIL PROTECTED] wrote:
Lets make the myfaces commons JSF API an official vote so we can have
a fixed time frame on this decision
+1 [ ] -- make JSF 1.2 the minimum requirement for the new myfaces
commons project
+0 [ ] -- you don't mind
Virtual Attributes in Component Generator hard-code accessKey
-
Key: TRINIDAD-850
URL: https://issues.apache.org/jira/browse/TRINIDAD-850
Project: MyFaces Trinidad
Issue Type: Bug
That looks good.
On Dec 5, 2007 6:16 PM, Scott O'Bryan [EMAIL PROTECTED] wrote:
Yeah I agree.
So to summarize here is what I'm understanding from people:
Common Converters
* JDK 1.5
* Should work on either JSF 1.1 JSF 1.2
Common Validators
* JDK 1.5
* Should work on
Sorry to be frank, but that wasn't an answer to the question.
Maintaining two code lines far outweighs the work to flip the plug-in
configuration, and that reason alone should be enough to discourage
any new 1.1 projects. The question still remains of why we need to
support 1.1.
On Dec 5, 2007
OK I managed to get MyFaces 1.2.1-SNAPSHOT and Seam 2.0.0GA working without
problem !
I would say it is a great time to release :)
On Nov 30, 2007 1:58 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
cool!
a nice wiki page!!
On Nov 30, 2007 7:43 PM, Bruno Aranda [EMAIL PROTECTED] wrote:
here we go;
my understanding is, that 1.1 is a must
Why? Is it really necessary for us to create new projects on legacy
specifications?
[
https://issues.apache.org/jira/browse/TOBAGO-569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arvid Hülsebus resolved TOBAGO-569.
---
Resolution: Fixed
tc:selectManyCheckbox does not support value binding of type List
:-)
On Dec 5, 2007 8:18 PM, Andrew Robinson [EMAIL PROTECTED] wrote:
there is no next merge :)
all 1.2 merges are done. Please merge this onto the trunk_1.2.x if did
not already
On Dec 5, 2007 12:13 PM, Simon Lessard [EMAIL PROTECTED] wrote:
oups, yeah, I didn't mean to commit the 1.2
there is no next merge :)
all 1.2 merges are done. Please merge this onto the trunk_1.2.x if did
not already
On Dec 5, 2007 12:13 PM, Simon Lessard [EMAIL PROTECTED] wrote:
oups, yeah, I didn't mean to commit the 1.2 code as well, brain fart on my
side, it should have been added with the next
+1
On Dec 5, 2007 1:57 PM, Mike Kienenberger [EMAIL PROTECTED] wrote:
+1
On Dec 5, 2007 1:46 PM, Andrew Robinson [EMAIL PROTECTED]
wrote:
Lets make the myfaces commons JSF API an official vote so we can have
a fixed time frame on this decision
+1 [ ] -- make JSF 1.2 the minimum
+1
Andrew Robinson wrote:
Lets make the myfaces commons JSF API an official vote so we can have
a fixed time frame on this decision
+1 [ ] -- make JSF 1.2 the minimum requirement for the new myfaces
commons project
+0 [ ] -- you don't mind supporting a 1.1 trunk in addition to a 1.2 trunk
-1 [
I'd vote +0 on supporting JSF 1.1
if that does answer your question.
(and in case some guys do need the converters/validators, they can
always fork it)
-m
On Dec 5, 2007 7:14 PM, Andrew Robinson [EMAIL PROTECTED] wrote:
Sorry to be frank, but that wasn't an answer to the question.
Maintaining
+1
Mario Ivankovits wrote:
+1
Lets make the myfaces commons JSF API an official vote so we can have
a fixed time frame on this decision
+1 [ ] -- make JSF 1.2 the minimum requirement for the new myfaces
commons project
+0 [ ] -- you don't mind supporting a 1.1 trunk in addition to a 1.2
RequestParameterProviderManager fails when template URL includes EL expressions
---
Key: ORCHESTRA-13
URL: https://issues.apache.org/jira/browse/ORCHESTRA-13
Project: MyFaces
tc:selectManyCheckbox does not support value binding of type List
-
Key: TOBAGO-569
URL: https://issues.apache.org/jira/browse/TOBAGO-569
Project: MyFaces Tobago
Issue Type:
+1
On 05/12/2007, Simon Lessard [EMAIL PROTECTED] wrote:
+1
On Dec 5, 2007 1:57 PM, Mike Kienenberger [EMAIL PROTECTED] wrote:
+1
On Dec 5, 2007 1:46 PM, Andrew Robinson [EMAIL PROTECTED]
wrote:
Lets make the myfaces commons JSF API an official vote so we can have
a fixed
[
https://issues.apache.org/jira/browse/TRINIDAD-851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548825
]
Gary Kind commented on TRINIDAD-851:
The plugin's release can already be set by using the jdev.release
As the vote states, if -1, please provide a reason why 1.1 has to be
supported. An argument of why not is not enough.
On Dec 5, 2007 2:14 PM, Bernd Bohmann [EMAIL PROTECTED] wrote:
-1
I don't see any reason why a commons fileupload should not support 1.1
Can someone define what commons API
On Dec 5, 2007 6:18 PM, Andrew Robinson [EMAIL PROTECTED] wrote:
here we go;
my understanding is, that 1.1 is a must
Why? Is it really necessary for us to create new projects on legacy
specifications?
Well a must is a bit too much. I think I said that, having Tomahawk
1.1.x in mind...
-1
I don't see any reason why a commons fileupload should not support 1.1
Can someone define what commons API means?
Is this just a subproject of commons like commons validator or commons
converter?
Scott O'Bryan schrieb:
+1
Mario Ivankovits wrote:
+1
Lets make the myfaces commons JSF
[
https://issues.apache.org/jira/browse/TRINIDAD-851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aino Andriessen updated TRINIDAD-851:
-
Status: Patch Available (was: Open)
JDev Plugin - configure the release
[
https://issues.apache.org/jira/browse/TRINIDAD-846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aino Andriessen updated TRINIDAD-846:
-
Status: Patch Available (was: Open)
JDev plugin - compiler configuration 11g
Hello Volker,
Well as Luka mentioned, the date picker IS bugged so this is only a poor
man's solution (although always worked fine for me on New York timezone) so
it's more like a temporary hack than a good solution so it doesn't really
deserve a JIRA comment. I actually got to rewrite the
[
https://issues.apache.org/jira/browse/TRINIDAD-846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548818
]
Gary Kind commented on TRINIDAD-846:
When you create a .jpr file, can it be loaded into JDev without
JDev Plugin - configure the release
---
Key: TRINIDAD-851
URL: https://issues.apache.org/jira/browse/TRINIDAD-851
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Plugins
Affects
That is the exception that happens with the forking. Once the
CoreRenderKitTest is fixed (I cannot do it today), we can set the fork
to once or none and this error will go away. The real problem is that
CoreRenderKitTest is broken.
-Andrew
On Dec 5, 2007 3:41 AM, Matthias Wessendorf [EMAIL
Mike, the reason for the API's I'm proposing is to solve a usecase we
can't currently support. Largely because of file uploads (but also some
other things as well), it is impossible for two renderkits to somtimes
even exist in the same webapplication as each other.
For instance, let's say
One thing I do agree on is that end-user components belong in the
renderkits. I see these utilities as being API's that the renderkit
developers could use in common.
Scott
Scott O'Bryan wrote:
Mike, the reason for the API's I'm proposing is to solve a usecase we
can't currently support.
Well it was mainly for the API's (not the other pieces). So are you
asking for us to have both a 1.1 and a 1.2 jsf commons api?
Scott
Bernd Bohmann wrote:
Ok,
I'm fine if we are starting with 1.2 only. We can look for 1.1
interesting parts later.
But I don't like a commons jsf 1.2 only
I think that is a good compromise;
by that we also can filter later on the interesting parts for 1.1
(which can be done, by those, that actually care on 1.1)
which is easier... since the most do care on 1.2 (since it is a NEWER api)
-M
On Dec 5, 2007 11:39 PM, Bernd Bohmann [EMAIL PROTECTED]
+1 :-) i don't like filters and don't like depending on the class-path
ordering
Scott O'Bryan schrieb:
Mike, the reason for the API's I'm proposing is to solve a usecase we
can't currently support. Largely because of file uploads (but also some
other things as well), it is impossible for two
There is another option if this gets vetoed...
All myfaces commons trunks - 1.2
1.1 branch that is only maintained by those willing to perform back ports
-Andrew
On Dec 5, 2007 3:43 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
I think that is a good compromise;
by that we also can filter
On Dec 5, 2007 11:32 PM, Scott O'Bryan [EMAIL PROTECTED] wrote:
Mike, the reason for the API's I'm proposing is to solve a usecase we
can't currently support. Largely because of file uploads (but also some
other things as well), it is impossible for two renderkits to somtimes
even exist in
We can start with a 1.2 jsf commons api. But it should be allowed to
provide a 1.1 jsf commons later.
Bernd
Scott O'Bryan schrieb:
Well it was mainly for the API's (not the other pieces). So are you
asking for us to have both a 1.1 and a 1.2 jsf commons api?
Scott
Bernd Bohmann wrote:
Forking this part of the discussion.
:) I will say that the Configurator's aren't completely isolated from
the classpath ordering issue. But I'm hoping that the combination of
universal processing for common tasks (like multi-part form handling)
and the ordering system allowed by the
All myfaces commons trunks - 1.2
1.1 branch that is only maintained by those willing to perform back ports
wasn't that what I said w/ compromise?
use JSF 1.2 as default, and when sb. cares, let
him port it back on a branch or what not;
-M
-Andrew
On Dec 5, 2007 3:43 PM, Matthias
At least in terms of the validators/converters/etc (non-api) parts of
commons, it is not intended that Tobago or any other project depend on
these. These are additional components made available to the end
users. So it's true that some small subset of Tobago users won't be
able to use it.
[
https://issues.apache.org/jira/browse/TOMAHAWK-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cagatay Civici updated TOMAHAWK-1155:
-
Resolution: Fixed
Status: Resolved (was: Patch Available)
Arabizing the
[
https://issues.apache.org/jira/browse/TRINIDAD-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548615
]
Matthias Weßendorf commented on TRINIDAD-811:
-
the correct config for the filter is:
!-- Trinidad
nope; don't think so.
it's fine if we just start w/ 1.2 as base.
(I'll update your little common tomorrow)
If needed, someone will just do it on a branch
(or somewhere else)
-M
On Dec 5, 2007 11:54 PM, Andrew Robinson [EMAIL PROTECTED] wrote:
Want to restart the vote?
On Dec 5, 2007 3:52
[
https://issues.apache.org/jira/browse/TRINIDAD-851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548865
]
Aino Andriessen commented on TRINIDAD-851:
--
I'm obviously doing something wrong because I cannot
[
https://issues.apache.org/jira/browse/TRINIDAD-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548690
]
Dara Meinhard commented on TRINIDAD-790:
Does anybody react on this ?
datepicker selects wrong day
+1
On Dec 5, 2007 11:22 AM, Bruno Aranda [EMAIL PROTECTED] wrote:
+1
On 05/12/2007, Simon Lessard [EMAIL PROTECTED] wrote:
+1
On Dec 5, 2007 1:57 PM, Mike Kienenberger [EMAIL PROTECTED] wrote:
+1
On Dec 5, 2007 1:46 PM, Andrew Robinson [EMAIL PROTECTED]
wrote:
+1
On Dec 5, 2007 9:22 PM, Bruno Aranda [EMAIL PROTECTED] wrote:
+1
On 05/12/2007, Simon Lessard [EMAIL PROTECTED] wrote:
+1
On Dec 5, 2007 1:57 PM, Mike Kienenberger [EMAIL PROTECTED] wrote:
+1
On Dec 5, 2007 1:46 PM, Andrew Robinson [EMAIL PROTECTED]
wrote:
Ok,
I'm fine if we are starting with 1.2 only. We can look for 1.1
interesting parts later.
But I don't like a commons jsf 1.2 only vote.
Bernd
Scott O'Bryan schrieb:
Bernd,
I do. :) Common's multi-part form handling (file uploads) will need to
work in both a Portal and Servlet
Bernd,
I do. :) Common's multi-part form handling (file uploads) will need to
work in both a Portal and Servlet environment before something like
Trinidad will be able to use it. For this, I'm proposing that such a
handler use the Configurator sub-system. The configurator Subsystem
must
yes, some APIs have changed;
my point was just, that for trivial things (like the validators/converters),
the API is same, the generated artifacts are *dependent* to the particular
Faces version.
-M
On Dec 5, 2007 5:34 PM, Scott O'Bryan [EMAIL PROTECTED] wrote:
I've also noticed that things
Hello,
You can set the right timezone in trinidad-config.xml to fix it. However,
use the LONG time zone name like 'America/New York' and NOT 'EST' nor
'GMT-5' or else day light saving won't kick in. Also, since the daylight
saving dates changed this year, make sure you have the latest update of
[
https://issues.apache.org/jira/browse/TRINIDAD-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548716
]
Steve Horne commented on TRINIDAD-811:
--
I agree the issue is INVALID. However, the Trinidad developer's
[
https://issues.apache.org/jira/browse/TRINIDAD-848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Weßendorf updated TRINIDAD-848:
Resolution: Fixed
Fix Version/s: 1.2.6-plugins
Status:
ToolTip for TreeListBox doesnt work in Internet Explorer
Key: TOBAGO-568
URL: https://issues.apache.org/jira/browse/TOBAGO-568
Project: MyFaces Tobago
Issue Type: Bug
I've also noticed that things with the externalContext also do not work
properly because the ExternalContext api's have changed. I suspect
anything that relies on the new functionality in externalContext or any
of the other API's for that matter will have trouble porting back.
Scott
Could not generate CGLIB subclass of class [class $Proxy0]
--
Key: ORCHESTRA-12
URL: https://issues.apache.org/jira/browse/ORCHESTRA-12
Project: MyFaces Orchestra
Issue Type: Bug
[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-15?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548909
]
Eduardo Millan commented on PORTLETBRIDGE-15:
-
Yes Kito, that would be fine, go ahead and let me
to bring light to this discussion;
On Oct 24, 2007 8:15 AM, Martin Marinschek [EMAIL PROTECTED] wrote:
For me, a merger makes sense.
The question is who will do the work, though.
yup! That's right.
Some reflections on the modules:
- ViewController/Dialog: I hope Orchestra can take in
Perhaps, we just should wait, when it comes to Faces 2.x impl and take
the bits, as we need them;
same is true for Orchestra (like Dialog/VC) as well.
Besides that, the Test may be interesting for us, since we use it, and
I'd like to see that module stays alive :-)
-Matthias
On Dec 6, 2007 8:34
71 matches
Mail list logo
