Re: [Xmlunit-general] Plans

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

On Thu, 5 Jun 2008, Colin Gourlay <cg...@eb...> wrote:

> I am new to XmlUnit having just stumbled across it by chance and can
> see me making great use of the .Net version for a project I am
> working on.
> 
> I am keen to get involved in the development and noticed there are a
> couple of books with coverage of XmlUnit available.
> 
> Before I start poking around the code is it worthwhile getting any
> of these books, or can anyone suggest any reading that will give me
> a firm footing of the capabilities as they currently stand

I don't know any of those books, so I really don't know.

For the .NET version your only bet is the code.  It's not as if we
were talking about hundreds of classes, you really can get a grip of
it within a few hours.

For the Java version the user guide should be completely
comprehensive, at least that was my intention when I put it together.

> (particularly what would be required to bring the Java & .Net APIs
> up to a similair level)?

A lot.

The .NET version doesn't provide more than the basic functionality
inside the difference engine while the Java version has a whole lot of
knobs to turn and extension points.  The .NET version can't even be
made to ignore differences in whitespace between otherwise contentless
elements.

BTW, the XMLUnit2 plans I posted in no way should preclude any
development on the existing code base.  I just think it will be easier
to come forward with a fresh start, but if there is anything that can
be imporved mid-term, just go ahead and suggest/implement it.

>>RE: Strongly naming the assembly
> 
> Have you looked into delay signing the assembly and sharing the key
> amongst the release managers?

I'm afraid that wouldn't be enough.

The binary we release should be strongly named, for this to work I
don't see any problem.  I don't think sharing the key between release
managers will be a real problem either (I'm not that much concerned
about security, we can always tell our users that they shouldn't take
the signature as any kind of guarantee).

But if we delay signed the assembly in our NAnt build, wouldn't that
mean that nobody without the key could build a usable version of the
assembly for him/herself?

To me the source distribution is as at least as important as the
binary one - actually I consider the source code the primary release
channel and the JAR/DLL is only some sort of convenience for our
users.

Stefan