On 06/01/2009, Rahul Akolkar <rahul.akol...@gmail.com> wrote: > 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. >
Great! > > -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
