Re: Client-side validation - enhance to match server-side

2007-04-20 Thread Danny Robinson

Does anyone have any feedback on this patch?  I don't expect it is perfect
or complete, but I'd like to understand if this is the approach you'd expect
for implementing this feature.

https://issues.apache.org/jira/browse/ADFFACES-391

On 3/16/07, Danny Robinson [EMAIL PROTECTED] wrote:


OK, I've posted an initial patch so client-side validation matches
server-side here: https://issues.apache.org/jira/browse/ADFFACES-391

Feedback gratefully received.

Description:

Attached patch file will provide an alternative client-side validation
mode where message layout and appearance exactly follows the server-side
mode. It renders hidden (skinned) elements that are dynamically populated
with error text and displayed if c/s validation fails for a given component.
The 'X' icon is also dynamically displayed. This works for input fields
rendered inside or outside of panelForm.

It contains certain changes to FormRenderer so that is will render a
different validation method depending on the setting below. _multiValidate
method was modified so it returns a 2d array of id, message which is then
processed by either _validateAlert() or _validateInline. FormRenderer now
uses the return value of the above methods to determine if submit can occur.


Outstanding features:
* Public js method that can be added to onblur (eg.
onblur=validateField(this);) to enable immediate validation of fields.
* Test with fields in tables

I guess this setting would be more at home in trinidad-config.xml though.
context-param
param-name
org.apache.myfaces.trinidadinternal.renderkit.INLINE_JS_VALIDATION
/param-name
param-valuetrue/param-value
/context-param
  [ Show » https://issues.apache.org/jira/browse/ADFFACES-391 ]
 Danny 
Robinsonhttps://issues.apache.org/jira/secure/ViewProfile.jspa?name=dannyjrobinson
[16/Mar/07 08:59 AM] Attached patch file will provide an alternative
client-side validation mode where message layout and appearance exactly
follows the server-side mode. It renders hidden (skinned) elements that are
dynamically populated with error text and displayed if c/s validation fails
for a given component. The 'X' icon is also dynamically displayed. This
works for input fields rendered inside or outside of panelForm. It contains
certain changes to FormRenderer so that is will render a different
validation method depending on the setting below. _multiValidate method was
modified so it returns a 2d array of id, message which is then processed by
either _validateAlert() or _validateInline. FormRenderer now uses the return
value of the above methods to determine if submit can occur. Outstanding
features: * Public js method that can be added to onblur (eg.
onblur=validateField(this);) to enable immediate validation of fields. *
Test with fields in tables I guess this setting would be more at home in
trinidad-config.xml though. context-param param-name
org.apache.myfaces.trinidadinternal.renderkit.INLINE_JS_VALIDATION/param-name 
param-valuetrue/param-value /context-param



On 3/1/07, Adam Winer [EMAIL PROTECTED]  wrote:

 Trinidad already has essentially the same functionality - input
 components
 can be marked as autoSubmit, at which point tabbing out will
 automatically
 trigger a server-side submit, and error messages will be automatically
 inserted into tr:messages, if present.  (There's an existing bug where
 the inline messages don't show up).

 -- Adam


 On 3/1/07, Peter Muir  [EMAIL PROTECTED]  wrote:
 
  On 28/02/07, Danny Robinson [EMAIL PROTECTED] wrote:
   Would there be support for an enhancement to the client-side
 validation
  so
   that it behaves in the same way as the server-side logic?  Meaning,
 we'd
  get
   rid of the javascript alert dialog and instead dyanamically
 show/hide
  the
   error messages in the page.
 
  You should look at the way this is done in A4J - the server side
  validators are used: the onblur of the input causes it's value to be
  sent, and then rendering any error messages (in the normal places),
  again using ajax.  Very neat IMO.
 
  Pete
 




--
Chordiant Software Inc.
www.chordiant.com





--
Chordiant Software Inc.
www.chordiant.com


Re: Client-side validation - enhance to match server-side

2007-04-20 Thread Adam Winer

Sorry - I've been wanting to have a look at it, but been
generally swamped.  Hopefully soon...

-- Adam


On 4/20/07, Danny Robinson [EMAIL PROTECTED] wrote:

Does anyone have any feedback on this patch?  I don't expect it is perfect
or complete, but I'd like to understand if this is the approach you'd expect
for implementing this feature.

https://issues.apache.org/jira/browse/ADFFACES-391

On 3/16/07, Danny Robinson [EMAIL PROTECTED] wrote:

 OK, I've posted an initial patch so client-side validation matches
 server-side here: https://issues.apache.org/jira/browse/ADFFACES-391

 Feedback gratefully received.

 Description:

 Attached patch file will provide an alternative client-side validation
 mode where message layout and appearance exactly follows the server-side
 mode. It renders hidden (skinned) elements that are dynamically populated
 with error text and displayed if c/s validation fails for a given component.
 The 'X' icon is also dynamically displayed. This works for input fields
 rendered inside or outside of panelForm.

 It contains certain changes to FormRenderer so that is will render a
 different validation method depending on the setting below. _multiValidate
 method was modified so it returns a 2d array of id, message which is then
 processed by either _validateAlert() or _validateInline. FormRenderer now
 uses the return value of the above methods to determine if submit can occur.


 Outstanding features:
 * Public js method that can be added to onblur (eg.
 onblur=validateField(this);) to enable immediate validation of fields.
 * Test with fields in tables

 I guess this setting would be more at home in trinidad-config.xml though.
 context-param
 param-name
 org.apache.myfaces.trinidadinternal.renderkit.INLINE_JS_VALIDATION
 /param-name
 param-valuetrue/param-value
 /context-param
   [ Show » https://issues.apache.org/jira/browse/ADFFACES-391 ]
  Danny 
Robinsonhttps://issues.apache.org/jira/secure/ViewProfile.jspa?name=dannyjrobinson
 [16/Mar/07 08:59 AM] Attached patch file will provide an alternative
 client-side validation mode where message layout and appearance exactly
 follows the server-side mode. It renders hidden (skinned) elements that are
 dynamically populated with error text and displayed if c/s validation fails
 for a given component. The 'X' icon is also dynamically displayed. This
 works for input fields rendered inside or outside of panelForm. It contains
 certain changes to FormRenderer so that is will render a different
 validation method depending on the setting below. _multiValidate method was
 modified so it returns a 2d array of id, message which is then processed by
 either _validateAlert() or _validateInline. FormRenderer now uses the return
 value of the above methods to determine if submit can occur. Outstanding
 features: * Public js method that can be added to onblur (eg.
 onblur=validateField(this);) to enable immediate validation of fields. *
 Test with fields in tables I guess this setting would be more at home in
 trinidad-config.xml though. context-param param-name
 org.apache.myfaces.trinidadinternal.renderkit.INLINE_JS_VALIDATION/param-name 
param-valuetrue/param-value /context-param



 On 3/1/07, Adam Winer [EMAIL PROTECTED]  wrote:
 
  Trinidad already has essentially the same functionality - input
  components
  can be marked as autoSubmit, at which point tabbing out will
  automatically
  trigger a server-side submit, and error messages will be automatically
  inserted into tr:messages, if present.  (There's an existing bug where
  the inline messages don't show up).
 
  -- Adam
 
 
  On 3/1/07, Peter Muir  [EMAIL PROTECTED]  wrote:
  
   On 28/02/07, Danny Robinson [EMAIL PROTECTED] wrote:
Would there be support for an enhancement to the client-side
  validation
   so
that it behaves in the same way as the server-side logic?  Meaning,
  we'd
   get
rid of the javascript alert dialog and instead dyanamically
  show/hide
   the
error messages in the page.
  
   You should look at the way this is done in A4J - the server side
   validators are used: the onblur of the input causes it's value to be
   sent, and then rendering any error messages (in the normal places),
   again using ajax.  Very neat IMO.
  
   Pete
  
 



 --
 Chordiant Software Inc.
 www.chordiant.com




--
Chordiant Software Inc.
www.chordiant.com



Re: MessageBundleTest._validateBundleParams

2007-04-20 Thread Adam Winer

Ah, I see.  It gives warnings for missing keys, but errors
when the set of parameters don't match up.  Yeah,
I guess disabling it is the simplest answer.

-- Adam


On 4/19/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:

It fails

Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0,031 sec

testBundles(org.apache.myfaces.trinidad.resource.MessageBundleTest)
Time elapsed: 0,031 sec   FAILURE!

[ stdout ] ---



[ stderr ] ---



[ stacktrace ] ---

junit.framework.AssertionFailedError: Error while testing bundle
MessageBundle_ar
Place holders mismatch in key
org.apache.myfaces.trinidad.validator.DateTimeRangeValidator.MAXIMUM_detail
Default bundle params {2}
MessageBundle_ar params {2} {1}
at junit.framework.Assert.fail(Assert.java:47)
at 
org.apache.myfaces.trinidad.resource.MessageBundleTest._validateBundleParams(MessageBundleTest.java:237)
at 
org.apache.myfaces.trinidad.resource.MessageBundleTest._validateBundle(MessageBundleTest.java:142)


Do you mind to disable it for now ?
I'll file a bug that it's disabled, I'll enable it, when the
translations arrive.



On 4/19/07, Adam Winer [EMAIL PROTECTED] wrote:
 I think the test should just be dumping warnings, not failing.

 -- Adam


 On 4/19/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 
  Hi,
 
  when putting the *new* messages in place, I noticed that this test fails:
  MessageBundleTest._validateBundleParams()
 
  That is because only the English messages are in a good shape, all
  translations, like German, Chinese and whatnot aren't updated yet.
 
  Two possible steps I am seeing:
  -commit all in once (English and translated)
  -turn off the test (for now ;-))
 
  What is your take on that?
 
  Thx,
  Matthias
 
  --
  Matthias Wessendorf
  http://tinyurl.com/fmywh
 
  further stuff:
  blog: http://jroller.com/page/mwessendorf
  mail: mwessendorf-at-gmail-dot-com
 



--
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com



Re: MessageBundleTest._validateBundleParams

2007-04-20 Thread Matthias Wessendorf

That is my guess as well,
at least before disabling a test, I need to ask the group ;-)

Thanks,
Matthias

On 4/20/07, Adam Winer [EMAIL PROTECTED] wrote:

Ah, I see.  It gives warnings for missing keys, but errors
when the set of parameters don't match up.  Yeah,
I guess disabling it is the simplest answer.

-- Adam


On 4/19/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 It fails

 Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0,031 sec

 testBundles(org.apache.myfaces.trinidad.resource.MessageBundleTest)
 Time elapsed: 0,031 sec   FAILURE!

 [ stdout ] ---



 [ stderr ] ---



 [ stacktrace ] ---

 junit.framework.AssertionFailedError: Error while testing bundle
 MessageBundle_ar
 Place holders mismatch in key
 org.apache.myfaces.trinidad.validator.DateTimeRangeValidator.MAXIMUM_detail
 Default bundle params {2}
 MessageBundle_ar params {2} {1}
 at junit.framework.Assert.fail(Assert.java:47)
 at 
org.apache.myfaces.trinidad.resource.MessageBundleTest._validateBundleParams(MessageBundleTest.java:237)
 at 
org.apache.myfaces.trinidad.resource.MessageBundleTest._validateBundle(MessageBundleTest.java:142)


 Do you mind to disable it for now ?
 I'll file a bug that it's disabled, I'll enable it, when the
 translations arrive.



 On 4/19/07, Adam Winer [EMAIL PROTECTED] wrote:
  I think the test should just be dumping warnings, not failing.
 
  -- Adam
 
 
  On 4/19/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  
   Hi,
  
   when putting the *new* messages in place, I noticed that this test fails:
   MessageBundleTest._validateBundleParams()
  
   That is because only the English messages are in a good shape, all
   translations, like German, Chinese and whatnot aren't updated yet.
  
   Two possible steps I am seeing:
   -commit all in once (English and translated)
   -turn off the test (for now ;-))
  
   What is your take on that?
  
   Thx,
   Matthias
  
   --
   Matthias Wessendorf
   http://tinyurl.com/fmywh
  
   further stuff:
   blog: http://jroller.com/page/mwessendorf
   mail: mwessendorf-at-gmail-dot-com
  
 


 --
 Matthias Wessendorf
 http://tinyurl.com/fmywh

 further stuff:
 blog: http://jroller.com/page/mwessendorf
 mail: mwessendorf-at-gmail-dot-com





--
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com


Re: ADFFACES-459 - to trunk only?

2007-04-20 Thread Matthias Wessendorf

committed

-M

On 4/19/07, Adam Winer [EMAIL PROTECTED] wrote:

I think we should apply the 1.2 patch immediately, because it's
for a different file - transform12.xsl instead of transform.xsl.

-- Adam


On 4/19/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:

 Hi *

 I applied the ADFFACES-459 patch to trunk only, for now.
 When we create a new JSF 1.2 branch (that is based on trunk), the
 patch is also in the latest greatest JSF 1.2 branch.

 ok w/ you ?

 -Matthias

 --
 Matthias Wessendorf
 http://tinyurl.com/fmywh

 further stuff:
 blog: http://jroller.com/page/mwessendorf
 mail: mwessendorf-at-gmail-dot-com





--
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com


Re: [continuum] BUILD FAILURE: Apache Trinidad Impl

2007-04-20 Thread Matthias Wessendorf

even a fresh, clean, naked, whatever checkout on my box, didn't cause the issue.

some (random?) continuum failures ?!



On 4/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:

ähm,

can anyone test ?

I am not seeing this on my box



On 4/20/07, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
 Online report : 
http://myfaces.zones.apache.org:8081/continuum/buildResult.action?buildId=7249projectId=85
 Build statistics:
   State: Failed
   Previous State: Ok
   Started at: Fri, 20 Apr 2007 16:29:54 +
   Finished at: Fri, 20 Apr 2007 16:33:35 +
   Total time: 3m 41s
   Build Trigger: Schedule
   Build Number: 42
   Exit code: 1
   Building machine hostname: myfaces.zones.apache.org
   Operating system : SunOS(unknown)
   Java version : 1.5.0_11(Sun Microsystems Inc.)

 
 SCM Changes:
 
 Changed: no author @ no date
 Comment: no comment
 Files changed:
   src/test/java/org/apache/myfaces/trinidad/resource/MessageBundleTest.java ( 
no revision )

 
 SCM Changes since last success:
 
 
 Dependencies Changes:
 
 org.apache.myfaces.trinidad:trinidad-build:1.0.1-incubating-SNAPSHOT

 org.apache.myfaces.trinidad:trinidad-api:1.0.1-incubating-SNAPSHOT

 org.apache.myfaces.trinidad:trinidad-api:1.0.1-incubating-SNAPSHOT

 org.apache.myfaces.trinidad:trinidad:1.0.1-incubating-SNAPSHOT

 
 Test Summary:
 
 Tests: 805
 Failures: 374
 Total time: 27361

 
 Output:
 
 [INFO] Scanning for projects...
 [INFO] Searching repository for plugin with prefix: 'source'.
 [INFO] 

 [INFO] Building Apache Trinidad Impl
 [INFO]task-segment: [clean, install, source:jar, deploy]
 [INFO] 

 [INFO] [clean:clean]
 [INFO] Deleting directory 
/local/continuum-1.1-SNAPSHOT/apps/continuum/working-directory/85/target
 [INFO] Deleting directory 
/local/continuum-1.1-SNAPSHOT/apps/continuum/working-directory/85/target/classes
 [INFO] Deleting directory 
/local/continuum-1.1-SNAPSHOT/apps/continuum/working-directory/85/target/test-classes
 [INFO] [faces:generate-jsp-taglibs {execution: default}]
 [INFO] Generated 141 JSP tag(s)
 [INFO] [faces:generate-facelets-taglibs {execution: default}]
 [INFO] Generated META-INF/tr.taglib.xml
 [INFO] Generated META-INF/trh.taglib.xml
 [INFO] [i18n:generate-locale-elements {execution: default}]
 [INFO] Generating LocaleElements
 [INFO] [i18n:generate-javascript-locales {execution: default}]
 [INFO] Generating Javascript Locales
 [INFO] [javascript:reduce-javascript {execution: default}]
 [INFO] [xrts:generate-sources {execution: default}]
 [INFO] Generating 32 XRTS bundles to 
/local/continuum-1.1-SNAPSHOT/apps/continuum/working-directory/85/target/maven-xrts-plugin/main/java
 [INFO] [faces:generate-faces-config {execution: default}]
 [INFO] Generated META-INF/faces-config.xml
 [INFO] [resources:resources]
 [INFO] Using default encoding to copy filtered resources.
 [INFO] [compiler:compile]
 Compiling 1122 source files to 
/local/continuum-1.1-SNAPSHOT/apps/continuum/working-directory/85/target/classes
 [WARNING] 
/local/continuum-1.1-SNAPSHOT/apps/continuum/working-directory/85/src/main/java/org/apache/myfaces/trinidadinternal/skin/SkinImpl.java:[49,60]
 [deprecation] org.apache.myfaces.trinidadinternal.ui.laf.xml.parse.IconNode in 
org.apache.myfaces.trinidadinternal.ui.laf.xml.parse has been deprecated

 [WARNING] 
/local/continuum-1.1-SNAPSHOT/apps/continuum/working-directory/85/src/main/java/org/apache/myfaces/trinidadinternal/skin/SkinImpl.java:[50,60]
 [deprecation] 
org.apache.myfaces.trinidadinternal.ui.laf.xml.parse.SkinPropertyNode in 
org.apache.myfaces.trinidadinternal.ui.laf.xml.parse has been deprecated

 [WARNING] 
/local/continuum-1.1-SNAPSHOT/apps/continuum/working-directory/85/src/main/java/org/apache/myfaces/trinidadinternal/skin/StyleSheetEntry.java:[37,60]
 [deprecation] org.apache.myfaces.trinidadinternal.ui.laf.xml.parse.IconNode in 
org.apache.myfaces.trinidadinternal.ui.laf.xml.parse has been deprecated

 [WARNING] 
/local/continuum-1.1-SNAPSHOT/apps/continuum/working-directory/85/src/main/java/org/apache/myfaces/trinidadinternal/skin/StyleSheetEntry.java:[38,60]
 

Re: [continuum] BUILD FAILURE: Apache Trinidad Impl

2007-04-20 Thread Simon Lessard

We... broken English... Should have been maybe you forgot to add a file
with latest patch?

On 4/20/07, Simon Lessard [EMAIL PROTECTED] wrote:


I'll try right away, did you forget to add a file with a patch maybe?

On 4/20/07, Matthias Wessendorf [EMAIL PROTECTED]  wrote:

 even a fresh, clean, naked, whatever checkout on my box, didn't cause
 the issue.

 some (random?) continuum failures ?!



 On 4/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  ähm,
 
  can anyone test ?
 
  I am not seeing this on my box
 
 
 
  On 4/20/07, [EMAIL PROTECTED]
   [EMAIL PROTECTED] wrote:
   Online report : 
http://myfaces.zones.apache.org:8081/continuum/buildResult.action?buildId=7249projectId=85

   Build statistics:
 State: Failed
 Previous State: Ok
 Started at: Fri, 20 Apr 2007 16:29:54 +
 Finished at: Fri, 20 Apr 2007 16:33:35 +
 Total time: 3m 41s
 Build Trigger: Schedule
 Build Number: 42
 Exit code: 1
 Building machine hostname: myfaces.zones.apache.org
 Operating system : SunOS(unknown)
 Java version : 1.5.0_11(Sun Microsystems Inc.)
  
  
 
   SCM Changes:
  
 
   Changed: no author @ no date
   Comment: no comment
   Files changed:
  
 src/test/java/org/apache/myfaces/trinidad/resource/MessageBundleTest.java (
 no revision )
  
  
 
   SCM Changes since last success:
  
 

  
 
   Dependencies Changes:
  
 
   org.apache.myfaces.trinidad:trinidad-build:1.0.1-incubating-SNAPSHOT
  
   org.apache.myfaces.trinidad:trinidad-api:1.0.1-incubating-SNAPSHOT
  
   org.apache.myfaces.trinidad:trinidad-api:1.0.1-incubating-SNAPSHOT
  
   org.apache.myfaces.trinidad:trinidad:1.0.1-incubating-SNAPSHOT
  
  
 
   Test Summary:
  
 
   Tests: 805
   Failures: 374
   Total time: 27361
  
  
 

   Output:
  
 
   [INFO] Scanning for projects...
   [INFO] Searching repository for plugin with prefix: 'source'.
   [INFO]
 
   [INFO] Building Apache Trinidad Impl
   [INFO]task-segment: [clean, install, source:jar, deploy]
   [INFO]
 
   [INFO] [clean:clean]
   [INFO] Deleting directory 
/local/continuum-1.1-SNAPSHOT/apps/continuum/working-directory/85/target

   [INFO] Deleting directory /local/continuum-1.1-SNAPSHOT
 /apps/continuum/working-directory/85/target/classes
   [INFO] Deleting directory 
/local/continuum-1.1-SNAPSHOT/apps/continuum/working-directory/85/target/test-classes

   [INFO] [faces:generate-jsp-taglibs {execution: default}]
   [INFO] Generated 141 JSP tag(s)
   [INFO] [faces:generate-facelets-taglibs {execution: default}]
   [INFO] Generated META-INF/tr.taglib.xml
   [INFO] Generated META-INF/trh.taglib.xml
   [INFO] [i18n:generate-locale-elements {execution: default}]
   [INFO] Generating LocaleElements
   [INFO] [i18n:generate-javascript-locales {execution: default}]
   [INFO] Generating Javascript Locales
   [INFO] [javascript:reduce-javascript {execution: default}]
   [INFO] [xrts:generate-sources {execution: default}]
   [INFO] Generating 32 XRTS bundles to /local/continuum- 1.1-SNAPSHOT
 /apps/continuum/working-directory/85/target/maven-xrts-plugin/main/java
   [INFO] [faces:generate-faces-config {execution: default}]
   [INFO] Generated META-INF/faces-config.xml
   [INFO] [resources:resources]
   [INFO] Using default encoding to copy filtered resources.
   [INFO] [compiler:compile]
   Compiling 1122 source files to 
/local/continuum-1.1-SNAPSHOT/apps/continuum/working-directory/85/target/classes

   [WARNING] 
/local/continuum-1.1-SNAPSHOT/apps/continuum/working-directory/85/src/main/java/org/apache/myfaces/trinidadinternal/skin/SkinImpl.java:[49,60]
 [deprecation]
 org.apache.myfaces.trinidadinternal.ui.laf.xml.parse.IconNode in
 org.apache.myfaces.trinidadinternal.ui.laf.xml.parse has been deprecated
  
   [WARNING] 
/local/continuum-1.1-SNAPSHOT/apps/continuum/working-directory/85/src/main/java/org/apache/myfaces/trinidadinternal/skin/SkinImpl.java:[50,60]
 [deprecation]
 org.apache.myfaces.trinidadinternal.ui.laf.xml.parse.SkinPropertyNode in
 org.apache.myfaces.trinidadinternal.ui.laf.xml.parse has been deprecated
  
   [WARNING] 

Re: [continuum] BUILD FAILURE: Apache Trinidad Impl

2007-04-20 Thread Matthias Wessendorf

no worries, I can't speak English as well.

But, I added a file.

-Matthias

On 4/20/07, Simon Lessard [EMAIL PROTECTED] wrote:

We... broken English... Should have been maybe you forgot to add a file
with latest patch?

On 4/20/07, Simon Lessard [EMAIL PROTECTED] wrote:

 I'll try right away, did you forget to add a file with a patch maybe?

 On 4/20/07, Matthias Wessendorf [EMAIL PROTECTED]  wrote:
 
  even a fresh, clean, naked, whatever checkout on my box, didn't cause
  the issue.
 
  some (random?) continuum failures ?!
 
 
 
  On 4/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
   ähm,
  
   can anyone test ?
  
   I am not seeing this on my box
  
  
  
   On 4/20/07, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Online report : 
http://myfaces.zones.apache.org:8081/continuum/buildResult.action?buildId=7249projectId=85
 
Build statistics:
  State: Failed
  Previous State: Ok
  Started at: Fri, 20 Apr 2007 16:29:54 +
  Finished at: Fri, 20 Apr 2007 16:33:35 +
  Total time: 3m 41s
  Build Trigger: Schedule
  Build Number: 42
  Exit code: 1
  Building machine hostname: myfaces.zones.apache.org
  Operating system : SunOS(unknown)
  Java version : 1.5.0_11(Sun Microsystems Inc.)
   
   
  
SCM Changes:
   
  
Changed: no author @ no date
Comment: no comment
Files changed:
   
  src/test/java/org/apache/myfaces/trinidad/resource/MessageBundleTest.java (
  no revision )
   
   
  
SCM Changes since last success:
   
  
 
   
  
Dependencies Changes:
   
  
org.apache.myfaces.trinidad:trinidad-build:1.0.1-incubating-SNAPSHOT
   
org.apache.myfaces.trinidad:trinidad-api:1.0.1-incubating-SNAPSHOT
   
org.apache.myfaces.trinidad:trinidad-api:1.0.1-incubating-SNAPSHOT
   
org.apache.myfaces.trinidad:trinidad:1.0.1-incubating-SNAPSHOT
   
   
  
Test Summary:
   
  
Tests: 805
Failures: 374
Total time: 27361
   
   
  
 
Output:
   
  
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'source'.
[INFO]
  
[INFO] Building Apache Trinidad Impl
[INFO]task-segment: [clean, install, source:jar, deploy]
[INFO]
  
[INFO] [clean:clean]
[INFO] Deleting directory 
/local/continuum-1.1-SNAPSHOT/apps/continuum/working-directory/85/target
 
[INFO] Deleting directory /local/continuum-1.1-SNAPSHOT
  /apps/continuum/working-directory/85/target/classes
[INFO] Deleting directory 
/local/continuum-1.1-SNAPSHOT/apps/continuum/working-directory/85/target/test-classes
 
[INFO] [faces:generate-jsp-taglibs {execution: default}]
[INFO] Generated 141 JSP tag(s)
[INFO] [faces:generate-facelets-taglibs {execution: default}]
[INFO] Generated META-INF/tr.taglib.xml
[INFO] Generated META-INF/trh.taglib.xml
[INFO] [i18n:generate-locale-elements {execution: default}]
[INFO] Generating LocaleElements
[INFO] [i18n:generate-javascript-locales {execution: default}]
[INFO] Generating Javascript Locales
[INFO] [javascript:reduce-javascript {execution: default}]
[INFO] [xrts:generate-sources {execution: default}]
[INFO] Generating 32 XRTS bundles to /local/continuum- 1.1-SNAPSHOT
  /apps/continuum/working-directory/85/target/maven-xrts-plugin/main/java
[INFO] [faces:generate-faces-config {execution: default}]
[INFO] Generated META-INF/faces-config.xml
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
Compiling 1122 source files to 
/local/continuum-1.1-SNAPSHOT/apps/continuum/working-directory/85/target/classes
 
[WARNING] 
/local/continuum-1.1-SNAPSHOT/apps/continuum/working-directory/85/src/main/java/org/apache/myfaces/trinidadinternal/skin/SkinImpl.java:[49,60]
  [deprecation]
  org.apache.myfaces.trinidadinternal.ui.laf.xml.parse.IconNode in
  org.apache.myfaces.trinidadinternal.ui.laf.xml.parse has been deprecated
   
[WARNING] 

Re: [continuum] BUILD FAILURE: Apache Trinidad Impl

2007-04-20 Thread Simon Lessard

Hello Matthias,

I could reproduce a compilation error but not the ones you mentioned, only
GoButtonFacesBeanTest failed here :

java.lang.ClassCastException:
org.apache.myfaces.trinidadinternal.bean.UIXFacesBeanImpl cannot be cast to
org.apache.myfaces.trinidadinternal.uinode.UINodeFacesBean
   at
org.apache.myfaces.trinidadinternal.uinode.UINodeFacesBeanTestCase.createUINodeFacesBean
(UINodeFacesBeanTestCase.java:54)
   at
org.apache.myfaces.trinidadinternal.uinode.nav.GoButtonFacesBeanTest.testDestination
(GoButtonFacesBeanTest.java:72)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at junit.framework.TestCase.runTest(TestCase.java:154)
   at org.jmock.core.VerifyingTestCase.runBare(Unknown Source)
   at junit.framework.TestResult$1.protect(TestResult.java:106)
   at junit.framework.TestResult.runProtected(TestResult.java:124)
   at junit.framework.TestResult.run(TestResult.java:109)
   at junit.framework.TestCase.run(TestCase.java:118)
   at junit.framework.TestSuite.runTest(TestSuite.java:208)
   at junit.framework.TestSuite.run(TestSuite.java:203)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(
JUnitBattery.java:242)
   at org.apache.maven.surefire.battery.JUnitBattery.execute(
JUnitBattery.java:216)
   at org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:215)
   at org.apache.maven.surefire.Surefire.run(Surefire.java:163)
   at org.apache.maven.surefire.Surefire.run(Surefire.java:87)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at org.apache.maven.surefire.SurefireBooter.runTestsInProcess(
SurefireBooter.java:313)
   at org.apache.maven.surefire.SurefireBooter.run(SurefireBooter.java:221)
   at org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:371)
   at org.apache.maven.plugin.DefaultPluginManager.executeMojo(
DefaultPluginManager.java:412)
   at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(
DefaultLifecycleExecutor.java:534)
   at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle
(DefaultLifecycleExecutor.java:475)
   at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(
DefaultLifecycleExecutor.java:454)
   at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures
(DefaultLifecycleExecutor.java:306)
   at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(
DefaultLifecycleExecutor.java:273)
   at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(
DefaultLifecycleExecutor.java:140)
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
   at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
   at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
   at org.codehaus.classworlds.Launcher.main(Launcher.java:375)

On 4/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:


no worries, I can't speak English as well.

But, I added a file.

-Matthias

On 4/20/07, Simon Lessard [EMAIL PROTECTED] wrote:
 We... broken English... Should have been maybe you forgot to add a
file
 with latest patch?

 On 4/20/07, Simon Lessard [EMAIL PROTECTED] wrote:
 
  I'll try right away, did you forget to add a file with a patch maybe?
 
  On 4/20/07, Matthias Wessendorf [EMAIL PROTECTED]  wrote:
  
   even a fresh, clean, naked, whatever checkout on my box, didn't
cause
   the issue.
  
   some (random?) continuum failures ?!
  
  
  
   On 4/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
ähm,
   
can anyone test ?
   
I am not seeing this on my box
   
   
   
On 4/20/07, [EMAIL PROTECTED]
 [EMAIL PROTECTED] wrote:
 Online report :