Hi,
Changing the way some pieces of XMLUnit work has been on my TODO list
for quite some time, but since that list always grows, I just never
seem to reach the point that I actually *do* it.
A few weeks ago Maxim Filimonov came in and he seems to have the
energy to actually do something - and I don't want to stand in his
way.
The rest of this mail - and likely mails sent by me on this and
related threads later - will contain "I" in many places. Right now
I'm the sole contributor and I take the liberty to make decisions as I
see fit. But I don't want to keep this project a one-man show (in
fact if you want to help and have the time to actually do so, speak
up) and will not only listen to feedback but try to find consensus.
Before I discuss more details in separate email threads here is what I
intend to do for XMLUnit2, much of this is not really technical at
all:
* split the Java jar into multiple pieces:
xmlunit-core: only depends on the JDK
xmlunit-junit3: provides custom JUnit3 assert methods on top of
xmlunit-core
xmlunit-junit4: provides custom Java 1.4 assert methods on top of
xmlunit-core to use together with JUnit 4.x
xmlunit-legacy: provide the old API and pieces I don't intend to
support in the future on top of xmlunit-core and
xmlunit-junit3
* split the .NET DLL into multiple pieces
xmlunit-core: only depends on the framework class library
xmlunit-nunit: provides custom NUnit assert methods on top of
xmlunit-core
* keep .NET and Java versions in sync
This doesn't mean things have to be identical from the API level,
but close. For example we may chose to use delegates in .NET where
the Java version uses one-method interfaces. .NET will capitalize
method names and may use properties instead of get/set pairs ...
* try to share tests between .NET and Java versions
* change package/namespace to avoid confusion
* some legal changes (I will forward this mail to Jeff and Tim to
allow them to chime in), in particular:
- the old sources - which only live in xmlunit-legacy - won't be
affected by anthing I list below
- any new code will be written from scratch
- the new code won't carry any copyright notice at all
- before I grant anybody commit access or accept bigger patches I'll
require a contributor license agreement which will be scanned and
put into svn. I'll certainly sign one myself.
I'll likely use Apache's CLA as a template.
This is more a way to protect myself and other future contributors
than anything else.
* design XMLUnit2 in an API-first way
There are some ideas and I'll start with explaining my ideas of how
we should specify input for the different pieces of XMLUnit first -
I hope to get this done over the weekend or early next week.
Stefan
------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Xmlunit-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xmlunit-general
