[Xmlunit-general] Fwd: Under development again

[James A. <jam...@gm...>]

Oops - hit reply rather than reply all. Sorry.

---------- Forwarded message ----------
From: James Abley <jam...@gm...>
Date: 16-Dec-2006 21:21
Subject: Re: [Xmlunit-general] Under development again
To: Stefan Bodewig <bo...@ap...>


Hi Stefan,

Some people are still listening! I'm very happy to hear that you're
involved; I know you from the ANT list.

On 16/12/06, Stefan Bodewig <bo...@ap...> wrote:
> 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).

Not of interest to me right now. I don't use .NET.

>
> 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.
>

It sounds like you've been busy!

> 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?
>

Sounds good. In case you're after contributions, I did implement W3C
Schema validation a while back, and I think it could be worked quite
happily into a patch. [1]

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

+1

>
> 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.

again, +1. It would be good (although I haven't needed it recently) to
have this more readily available to Java developers.

>
> 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.

Or Neko? I haven't compared them lately, but might be worth doing.
HTTPUnit allows Neko or JTidy to be plugged in.

>
> 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.

Depends what's being removed. Presumably this is in HEAD currently?

>
> 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?
>

I haven't written / come across any tests where I would expect them to
handle this. IMHO, invalid XML has always been considered a problem in
the test environment, rather than something specifically tested for.
That said, might be worth defining a subclass of RuntimeException so
that client tests can do the following:

try {
   doSomething();
   fail("provided input wasn't valid xml");
catch (XMLUnitException expected) {
   // pass
}

> Cheers
>
>         Stefan
>
> --
> http://stefan.samaflost.de/
>

I'll check out the source and see if I'm suitably inspired to pitch in.

Cheers,

James

[1] http://sourceforge.net/mailarchive/message.php?msg_id=13656151