On 05/01/2009, Rahul Akolkar <rahul.akol...@gmail.com> wrote:
> On Mon, Jan 5, 2009 at 7:57 AM, sebb <seb...@gmail.com> wrote:
>  > SCXMLTestHelper currently allows the test to continue if it cannot
>  > create the serialisation work directory.
>  >
>  > Given that it now fails the test if it cannot create/read the
>  > serialisation files, it seems to me that directory creation failure
>  > should also cause the test to fail.
>  >
>  > WDYT?
>  >
>
> <snip/>
>
>  Confused by the predicate in 2nd para since in case of NSEs the test 
> continues.

The test does not continue if the file cannot be created/written.

>  WRT the directory creation, if you'd rather have the build fail if
>  creation fails, there would ideally be a nice message stating the
>  problem (rather than a generic x failures and y errors kind of thing)

I was thinking of throwing an IOException("Failed to create
serialisation work directory",e).

However it's going to be a pretty unlikely occurrence - indeed I'm not
sure why the check is needed at all as failure to create the directory
would cause an IO error on the file creation which follows.

>  and additonally, there'd be a build time switch that allows folks to
>  say "we don't care about serialization" which would cause the build to
>  succeed (this could also help the NSE catches you are looking at
>  eliminating -- all NSEs could then cause tests to error out by
>  default). So maybe the approach of providing such a switch helps both
>  cases we're discussing.

Not sure I know how to do that in Maven. Why not do a single test for
NSE and skip any further serialisation tests if the the initial test
fails?

>  -Rahul
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>  For additional commands, e-mail: dev-h...@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to