xmlunit-general

[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/

[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

Re: [Xmlunit-general] Fwd: Under development again

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

On Mon, 18 Dec 2006, James Abley <jam...@gm...> wrote:
> 
> Some people are still listening!

Good to know 8-)

> On 16/12/06, Stefan Bodewig <bo...@ap...> wrote:

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

Some of the fixed bugs really have been fruits hanging very very low ;-)

>> My short term goal is to add XML Schema validation and XML
>> namespace support for XPath assertions,
> 
> 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]

A patch would be very much appreciated.  I was thinking about
"borrowing" Ant's catalog resolver code so that we could use the an
Apache XML resolver based OASIS Catalog strategy for resolving
entities and schema locations.

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

What I was trying to say was that IMHO people should be running JTidy
(or neko) over their input before passing it to XMLUnit rather than
using XMLUnit's TolerantSAXParser - I may be wrong.

>> 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'd like to remove all the methods from XMLTestCase that have been
deprecated in 1.0.  Not that many.

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

I've already introduced this strategy when I removed the
ParserConfigurationException.  The later gets wrapped in a
ConfigurationException which extends XMLUnitRuntimeException which
extends RuntimeException.

Maybe we need to treat control and test XML differently?  Control
documents should never be invalid, while test documents might be.

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

I'm looking forward to more suggestions.

Stefan