On Mon, Jan 5, 2009 at 5:40 PM, sebb <seb...@gmail.com> wrote: > 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: <snip/> >> > >> > 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. > <snap/>
Apart from the details of conditionally turning off certain tests once the surefire plugin sets off (which I'm not aware of) ... Ideally, we don't want to skip those tests entirely, we just want to skip the serialization round trips in those tests once we detect the specific NSE due to the DOM impl. Each of those tests takes the form of functional testing interspersed with serialization testing, this best emulates real world scenarios, IOW: 1. test something 2. do a serialization round trip 3. test something else assuming state at end of 1 4. do another serialization round trip ... So we'd want to skip 2 and 4, but keep testing 1 and 3. Which is what we do now. Ofcourse, at any point, if the JDK DOM impl isn't serializable, then the endorsed standards override mechanism can be used to change that and fully run all the tests with serialization. Your point of making it easier to detect other serialization errors on such a JDK is well taken. >> 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, <snip/> Yup, thats a good thing, thanks :-) > but I think NSEs which are not caused by > the faulty Sun 1.4 DOM should cause failures. > <snap/> OK, so what you added to trunk does that. I guess we can retain the crimson check as-is and keep refining it as and when it breaks with other obscure JDKs and configurations you and I haven't tested on. -Rahul --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
