[Xmlunit-general] Under development again

[Stefan B. <bo...@ap...>]

Hi all,

just in case there still is anybody listening I thought I'd better
give you a heads up, now that I start breaking everybody's code 8-)

A few months ago I asked Tim and Jeff whether they'd be around to
accept a few patches and Jeff was kind enough to give me commit
access.

Back then my primary interest was - and still is - to get the .NET
version into shape, in particular I'd like to make it work with more
recent versions of NUnit and the .NET framework (as well as Mono).

For the time being I've spent more time on the Java codebase since
this is the one I was more familiar with.  I started fixing a few of
the open bugs and by now managed to make XMLUnit pass all its test
under JDK 1.5 and 1.6 as well.  In order to do that I've added to
SimpleXpathEngine a JAXP 1.3 implementation that gets used under the
covers if it is available.

My short term goal is to add XML Schema validation and XML namespace
support for XPath assertions, which should mean I'd have addressed
almost all open issues in the trackers.  Once done I'd like to do a
1.1 release of XMLUnit/Java - and start working on the .NET version
after that.  Any objections?

Also I'd like to move to subversion sooner rather than later.

Longer term I'd like to break up XMLUnit a bit more.  The XML diff
engine is usable standalone and I'd like to see it as a first class
citizen with the *Unit test framework classes just using them.

Speaking of *Unit, I want to add support for JUnit4 style assertions
(actually Java 1.4 style) and maybe TestNG on the Java side and look
at the stuff Peli has done for the MBUnit integration on the .NET
side.  Support for Team Test might be an option there as well.

Certain parts of XMLUnit won't see much love during that process, in
particular the classes that support working on good old HTML might
better be replaced by something like JTidy in the tests.

In general I want to keep stuff backwards compatible - those who know
my work on Ant know that I can get pretty paranoid when it comes to
BWC - but I'll be breaking things every once in a while.

If anybody thinks that the deprecated methods should not be removed
before the next release, please speak up now.

I started to refactor parts of the exception handling.  Any
ParserConfigurationException or TransformerConfigurationException now
gets wrapped in a RuntimeException - you cannot recover from that
anyway.  I'll probably try to remove IOException from all
methods/constructors that take String arguments as well.

I'm a bit undecided on dealing with TransformerException and
SAXExceptions - should I wrap them in RuntimeExceptions as well or do
we expect tests to gracefully deal with invalid XML input?

Cheers

        Stefan

-- 
http://stefan.samaflost.de/