Building XMLUnit
XMLUnit for Java builds using Apache Maven, mainly you want to run
$ mvn installThe tests of XMLUnit depend on JUnit 4.x (legacy uses JUnit 3.x and also depends on JUnit 3.x at runtime), the matchers depend on Hamcrest.
XMLUnit for .NET uses NuGet and msbuild/xbuild - or Visual Studio 2013+ - for the traditional .NET Framework 3.5 compatible version. The .NET Standard 2,0 version uses the dotnet CLI - or Visual Studio 2017+.
When using Visual Studio the build should automatically refresh the NuGet packages, build the core and constraints assemblies as well as the unit test projects and run all NUnit tests.
When not using Visual Studio you need to install nuget as well as msbuild or xbuild and run
$ nuget restore XMLUnit.NET.NetFramework.slnonce to download the packages used by XMLUnit during the build (really only NUnit right now). After that you can run msbuild or xbuild like
$ xbuild /p:Configuration=Debug XMLUnit.NET.slnwhich compiles core and constraints, builds the assemblies and executes the NUnit tests.
Tests are run using NUnit 3.x and the constraints assemblies even have a runtime dependency on NUnit 2.x and 3.x respectively.
When using Visual Studio the build should automatically refresh the
NuGet packages, build the core and constraints assemblies as well
as the unit test projects.
When not using Visual Studio you need to run
$ dotnet restore XMLUnit.NET.slnonce to download the packages used by XMLUnit during the build (really
only NUnit right now). After that you can run dotnet like
> dotnet build XMLUnit.NET.sln -c Debugwhich compiles core, constraints and placeholder and builds the
assemblies. In order to run the tests use
> dotnet test src/tests/net-core/XMLUnit.Core.Tests.csproj
> dotnet test src/tests/net-constraints-nunit3/XMLUnit.NUnit3.Constraints.Test.csproj
> dotnet test src/tests/net-placeholders/XMLUnit.Placeholders.Tests.csprojAPI documentation is currently not published automatically to the website but created manually. The Java SNAPSHOTs contain javadocs jars.
$ mvn javadoc:aggregatebuilds javadocs for all three modules and merges them into a single documentation tree.
API docs are based on XML comments and some external files for namespace level docs. Currently the API docs are generated using monodoc, the shell script run-monodoc.sh creates static HTML documentation in build/html.
The main requirement for the API docs is "static HTML". Experimenting with Sandcastle has only lead to formats that require an extra viewer or an interactive ASP.NET webapp, neither is acceptable. If anybody known about a better option, help is very much appreciated.