axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <stev...@iseran.com>
Subject Re: Suggestion
Date Mon, 02 Dec 2002 18:01:50 GMT

----- Original Message -----
From: "Glen Daniels" <gdaniels@macromedia.com>
To: "Axis-Dev (E-mail)" <axis-dev@xml.apache.org>
Sent: Sunday, December 01, 2002 14:42
Subject: Suggestion


>
> What do people think about a system property switch we can use to
activate/deactivate tests which are "bleeding edge"?  Right now, we have
tests (like TestCircularRefs and test/wsdl/gateway) which are in the tree
but test things which are currently known to be broken.  The way we deal
with this at present is to comment out the broken stuff so the tests run.
>
> How about instead, we surround "sketchy" things which SHOULD pass but
don't yet with
>
> if (bleedingEdge) {
> }
>
> where bleedingEdge gets set by running with -Daxis.bleedingEdge on the
command line.
> That way people interested in working on making those tests run won't have
to uncomment/recomment various bits and pieces.  Once the test works, just
remove the if.

1. please hold back changing buildTests.xml much till I commit the
offline/proxy support, which I am still stabilising (and holding back till
you get 1.1beta out, as it can only break the build)

2. make it an ant property, not a sysprop, so that your own build.properties
can control what is allowed.

3. I like the idea of tests bundled into functional classes, rather than
just 'bleedingedge'...
 tests.appserver    -httpunit tests
 tests.interop    -remote interop
 tests.performance    -load tests; time consuming
 tests.broken    -anything that is broken, pending classification

With a patternset for each one. This is roughly what I am doing in the
online/offline fix


Mime
View raw message