I've just released new minor versions of XMLUnit for Java and XMLUnit.NET. Both releases are improvements.
Changelog for XMLUnit for Java 2.8.4:
- improved comparison performance for documents with many siblings
based on a suggestion by @gerpres made in #236
Changelog for XMLUnit.NET 2.9.1
- improved comparison performance for documents with many siblings
based on a suggestion by @gerpres made in Java Issue xmlunit/#236 - added a new
FullDescription
method toDiff
that provides a string-representation of all differences - not just the first one likeToString
does.
Based on Java PR xmlunit/#235 by @Boiarshinov
Right now there seem to be some issues with Sonatype's OSS Nexus (likely under heavy load) so it may take a bit longer than usual for the new Java artifacts to show up in Maven Central.
path: /en/oss/XMLUnit | #
This release fixes a shortcoming of the AssertJ support modules and
adds a new convenience feature to the Diff
class.
The full list of changes:
- added a new
fullDescription
method toDiff
that provides a string-representation of all differences - not just the first one liketoString
does.
PR #235 fixing #232 by @Boiarshinov - made sure AssertJ's methods to override the assertion message like
withFailMessage
are honored. #225 - adjusted unit tests so they pass when AssertJ 3.19.0 is used. PR #212 by mmathesius
path: /en/oss/XMLUnit | #
This release fixes a bug in the new AssertJ 3.x module.
CompareAssert
inside the AssertJ3 module swapped the expected and actual parameters when creating the assertion error.
#210 by @f-lopes.
path: /en/oss/XMLUnit | #
The only real change when compared to XMLUnit for Java 2.8.0 is the
introduction of a new xmlunit-assertj3
module that
requires AssertJ 3.18.1 or later in order to address a problem with
running AssertJ tests in an OSGi environment.
The original xmlunit-assertj
module will still be
supported.
The full changelog of XMLUnit for Java 2.8.1:
-
added a new xmlunit-assertj3 module that requires AssertJ 3.18.1 or later.
This module no longer uses AssertJ internal classes that are not exported to OSGi environments and thus fixes issue #203.
The module (like AssertJ 3.x itself) requires Java 8 at runtime and is similar to xmlunit-assertj but is no drop-in replacement. It uses a different Java package from xmlunit-assertj and
CompareAssert
will no longer throw a JUnit 4.xComparisonException
but an opentest4jAssertionFailedError
instead.The existing xmlunit-assertj module will still be supported in future releases but expect AssertJ 3.x specific changes to only get applied to xmlunit-assertj3.
Many thanks to @Zegveld, @scordio and @joel-costigliola.
path: /en/oss/XMLUnit | #
Both releases are mostly bugfix releases. Unfortunately both are going to break backwards compatibility for some people.
All modules of XMLUnit for Java now require Java7 as a minimum and
the optional JAXB dependency has been updated to use the Jakarta XML
Binding API. XMLUnit.NET has made ISource
disposable
which is going to break custom implementations.
Details for XMLUnit for Java 2.8.0
- changed optional JAXB dependency to use Jakarta XML Binding API PR #186 by @endrejeges
- bumped the bytebuddy dependency to 1.10.10 for the AssertJ module in the hope it would help with #188 - and change its scope from provided to compile time, which should finally fix the issue.
- added a new
extractingText
method toMultipleNodeAssert
to make it possible to write AssertJ assertions against the textual content of nodes more easily. Issue #192 and PR #193 by @keesvandieren - changed the minimum Java version required from Java 6 to Java 7 for all modules (it has already been Java 7 for the AssertJ module before).
DefaultNodeMatcher
with multipleElementSelector
s could fail to find the best matches as the order ofElementSelector
s should select them. #197Input
builder now supportsjava.nio.file.Path
#196- It is now possible to specify a custom
TransformerFactory
forDefaultComparisonFormatter
. #195
Details for XMLUnit.NET 2.9.0
ISource
now extendsIDisposable
to allow releasing unmanaged resources used when building sources from files or URIs. This change is backwards incompatible if you are providingISource
implementations of your own. #33.DefaultNodeMatcher
with multipleElementSelector
s could fail to find the best matches as the order ofElementSelector
s should select them. Issue similar to xmlunit/#197
path: /en/oss/XMLUnit | #