ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Ant Wiki] Update of "Proposals/EnhancedTestReports" by SteveLoughran
Date Mon, 03 Dec 2007 13:59:13 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Ant Wiki" for change notification.

The following page has been changed by SteveLoughran:
http://wiki.apache.org/ant/Proposals/EnhancedTestReports

The comment on the change is:
more on logging

------------------------------------------------------------------------------
  
  === Improved Logging information ===
  
-  * Retain the current stdout+stderr logs, but also allow people to bind to custom log4j/commons-logging/java.util.logging
back ends that grab the raw events and log them as structured XML events (host,process,thread,level,timestamp,text).
These would be renderable at different levels
+  * Retain the current stdout+stderr logs, but also allow people to bind to custom log4j/commons-logging/java.util.logging
back ends that grab the raw events and log them as structured XML events (host,process,thread,level,timestamp,text).
These would be renderable at different levels. This is not something we'd do automatically
as it can change application behaviour. We'd have to provide the custom back-ends for the
loggers and offer a switch to turn this on in the task; the switch would set the properties
for the forked process (and it would have to be forked) to log through our system. There's
an
+ [http://smartfrog.svn.sourceforge.net/viewvc/smartfrog/trunk/core/components/xunit/src/org/smartfrog/services/xunit/serial/LogEntry.java?view=markup
example class] in the smartfrog repository to capture log entries [http://smartfrog.svn.sourceforge.net/viewvc/smartfrog/trunk/core/components/xunit/src/org/smartfrog/services/xunit/serial/ThrowableTraceInfo.java?view=markup
and accompanying exceptions] that can be captured serialized and shared between processes.

+ 
   * XSL style sheets to merge output, ordering by clock (received time) and displaying log
messages from different machines/levels in different colour
-  * easy turn on/off display of different levels in viewers; maybe test runner.
+  * easy turn on/off display of different levels in viewers; maybe the test runner itself,
though log4j.properties and similar can do this (actually, given that java.util logging is
such a PITA to set up, we could add helper operations in the <java> task for all to
use.
  
  === Improved Host information ===
  
@@ -109, +111 @@

  
  === Improved Fault Information ===
  
- Java faults should be grabbed and their (recusrsive) stack traces extracted into something
that can be zoomed in on 
+ Java faults should be grabbed and their (recursive) stack traces extracted into something
that can be zoomed in on 
  
  {{{<throwable classname="java.lang.Throwable">
   <message>text here</message>
@@ -145, +147 @@

  * Skipped
  * In Progress, aka not-yet-finished
  
- SteveLoughran: I like failure itself to be categorised. So every state can be a pass state,
a warning or a failure. Warnings could include "passing, but took 50% longer than usual".
Failures can include "tests passed but outside allowed time" "tests passed but memory consumption
was over the limit", as well as simple "some assertion failed". 
+ SteveLoughran: I like failure itself to be categorised. So every state can be a pass state,
a warning or a failure. Warnings could include "passing, but took 50% longer than usual".
Failures can include "tests passed but outside allowed time" "tests passed but memory consumption
was over the limit", as well as simple "some assertion failed". Maybe we decouple result name
from outcome, with a limited set of outcomes, but an unlimited set of outcome categories.

  
  == Add partial-failure, not-yet-finished as test outcomes ==
  
@@ -178, +180 @@

  
  Arguments against
   1. if it becomes a wire format, it becomes even less flexible
-  1. CI tools are better of with their own custom listeners (they get to stop the run too
:)
+  1. CI tools are better off with their own custom listeners (they get to stop the run too
:)
   1. We don't want to endorse JAXB (brittle) or DOM (painful), but XOM is off limits to apache
projects (LGPL), and we don't want to intro new dependencies to ant either.
  
  This may be something for things other than Ant to consider.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message