On 05/01/2009, Rahul Akolkar <rahul.akol...@gmail.com> wrote:
> On Mon, Jan 5, 2009 at 3:52 PM, sebb <seb...@gmail.com> wrote:
> > 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.
> >
>
> <snip/>
>
> I went looking through the svn log since I don't recollect its
> origins, and I think it had to do with failures when running the tests
> outside Maven. The only thing I see is cases where we can't assume the
> existence of the parent 'target' directory -- which has been fixed by
> changing the mkdir() call to mkdirs(). At this point, I agree the
> check is not needed.
>
OK, I'll remove the check then.
> >> 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?
> >
>
> <snap/>
>
> You mean single JUnit test? That'll cause the build to fail on JDKs
> like Sun 1.4 (unless the tests are skipped), which seems suboptimal
> given its an optional feature users may not need and an environment
> configuration, rather than code, issue.
Yes, the idea would be to use a separate JUnit test to probe for the
specific NSE error and skip the other tests that would fail.
The NSE exceptions would then no longer need to be caught.
This would make it much easier to detect other serialisation errors,
e.g. if any of the classes are updated in future. There would be no
need to check what class was involved - i.e. the present "fragile"
check would not be needed.
> When I weight the pros and
> cons of a build failure vs. current outcome (warnings to console) in
> this context, the latter seems better to me.
>
Now that the test output is shorter, the serialisation warning
messages stand out better, but I think NSEs which are not caused by
the faulty Sun 1.4 DOM should cause failures.
> -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
