[ http://issues.apache.org/jira/browse/TOBAGO-57?page=all ]
Volker Weber resolved TOBAGO-57.
Resolution: Fixed
Add globalOnly attribute to messages tag
Key: TOBAGO-57
URL:
Hi there!
just some thoughts ...
I also think that it is right about time to include dojo into
tomahawk. Since a lot
of sandbox components are already using dojo an probably a lot more will come
this should be the right way to go. Sooner or later those components will move
from the sandbox to
+1 for removing wish. Its all a wish - even the bugs. I think the
current voting system is a better way for finding what the popular
requests are. IMO those take second priority over Patch Available.
sean
On 8/18/06, Cagatay Civici [EMAIL PROTECTED] wrote:
for a wish ?
Yes, I do it if
Do you have an account yet? If not, I can create one for you.
Sean
On 8/16/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
see offline email
On 8/16/06, Wendy Smoak [EMAIL PROTECTED] wrote:
Can I get an account on the MyFaces zone?
Recent discussion about the Core 1.1.4 release indicated
On 8/20/06, Sean Schofield [EMAIL PROTECTED] wrote:
Do you have an account yet? If not, I can create one for you.
Apparently we're sharing one, so I have that. If you have time to set
up 'wsmoak' as well, that would be great.
I could use a tour of the zone. What is all the stuff in the
+1
We basically decided on this a long time ago but not everyone is
following it. Newer versions of JIRA (in use with Shale but not
MyFaces) also allows you to disable email on bulk changes.
At some point I will change the JIRA workflow so that you can not
directly close a feature (it must be
Change JIRA workflow so issues must be resolved before they are closed
--
Key: MYFACES-1390
URL: http://issues.apache.org/jira/browse/MYFACES-1390
Project: MyFaces Core
On 8/20/06, Sean Schofield [EMAIL PROTECTED] wrote:
We basically decided on this a long time ago but not everyone is
following it. Newer versions of JIRA (in use with Shale but not
MyFaces) also allows you to disable email on bulk changes.
At some point I will change the JIRA workflow so that
Anyone else getting this on a clean co ?
Downloading: http://repo1.maven.org/maven2/doxia/doxia-core/1.0-alpha-4/doxia-co
re-1.0-alpha-4.pom
4K downloaded
[INFO]
[ERROR] BUILD ERROR
[INFO]
[ http://issues.apache.org/jira/browse/TOBAGO-111?page=all ]
Bernd Bohmann resolved TOBAGO-111.
--
Resolution: Fixed
Add blank and demo example to assembly
--
Key: TOBAGO-111
URL:
Can you do it so this is only required for Fixed issues?
Invalid/Won't Fix issues should be closed directly.
Why should these be closed directly? Maybe we would revisit one of
these before the release is done. Also, I believe having them
resolved (instead of closed) allows the user to appeal
[ http://issues.apache.org/jira/browse/TOBAGO-113?page=all ]
Bernd Bohmann resolved TOBAGO-113.
--
Resolution: Fixed
TabChangeEvent should provide the same methods like the TabChangeEvent in
tomahawk
Is there any way to search for Patch Available issues?
I haven't been able to figure this out yet myself.
Just create a custom search under Find Issues Be sure to change the
project to MyFaces and click the refresh link that they show you.
Otherwise you are stuck with options available for all
[ http://issues.apache.org/jira/browse/TOBAGO-114?page=all ]
Bernd Bohmann resolved TOBAGO-114.
--
Resolution: Fixed
The datepicker of tx:date should surrounded by a form to prevent validation
errors from other fields
[ http://issues.apache.org/jira/browse/TOBAGO-109?page=all ]
Bernd Bohmann resolved TOBAGO-109.
--
Resolution: Fixed
UICommand facet support for change and click events in selectOneRadio,
selectBooleanCheckbox, selectManyCheckbox and selectOneChoice
I see the primary use of resolved versus closed as keeping/generating
a log of what's changed during a release. Things that don't impact a
release (non-fixes) don't need to have a resolved state.
I have never had a need to revisit an invalid issue. Won't fix hasn't
come up yet.
Users can
Aha! I was sure that the last time I looked, Patch Available wasn't
an option under status. Thanks for pointing this out.
On 8/20/06, Sean Schofield [EMAIL PROTECTED] wrote:
Is there any way to search for Patch Available issues?
I haven't been able to figure this out yet myself.
Just
Even easier than that - there''s a link right off the main
Browse Project page... Look under Project Summary
at http://issues.apache.org/jira/browse/MYFACES
-- Adam
On 8/20/06, Sean Schofield [EMAIL PROTECTED] wrote:
Is there any way to search for Patch Available issues?
I haven't been able
Shale test framework 1.0.3 includes MyFaces 1.1.1
-
Key: TOMAHAWK-612
URL: http://issues.apache.org/jira/browse/TOMAHAWK-612
Project: MyFaces Tomahawk
Issue Type: Bug
Affects Versions:
[ http://issues.apache.org/jira/browse/TOMAHAWK-612?page=all ]
Paul Spencer updated TOMAHAWK-612:
--
Status: Patch Available (was: Open)
Shale test framework 1.0.3 includes MyFaces 1.1.1
-
Has this stuff been here all along and I somehow missed it when
looking for it, or was it added recently (in the last couple of
months)? I feel like a fool for not seeing it up to this point.
On 8/20/06, Adam Winer [EMAIL PROTECTED] wrote:
Even easier than that - there''s a link right off the
I am writing a unit test based on the Shale Test Framework for a Tomahawk
component. My current problem is the I need to add the default MyFaces and
Tomahawk components and renderers to the FacesContext. To date I have been
using facesContext.getApplication().addComponent(...) and
I would be suprised if you found a quick and easy way to do this. MyFaces core
uses digester to unmarshal the config files. It then calls the API you
mention. I would start digging around in org.apache.myfaces.config .
Dennis Byrne
-Original Message-
From: Paul Spencer [mailto:[EMAIL
On 8/20/06, Dennis Byrne [EMAIL PROTECTED] wrote:
I would be suprised if you found a quick and easy way to do this. MyFaces core uses digester to unmarshal the config files.It then calls the API you mention. I would start digging around in org.apache.myfaces.config .
One aggressive approach you
24 matches
Mail list logo
