xmlunit-general Mailing List for XML Unit

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

This release fixes a problem with the published POM of the
xmlunit-legacy module. It doesn't contain any changes to any of the
other modules.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Both releases come with build related changes but also fix some issues
with the placeholders module.

# List of changes for XMLUnit for Java

* placeholders can now also be used inside of the local part of `xsi:type` attributes.
  PR https://github.com/xmlunit/xmlunit/pull/293

* PlaceholderDifferenceEvaluator would cause ClassCastException for documents with
  differences in `xsi:type` attributes.
  Issue https://github.com/xmlunit/xmlunit/issues/276

* updated a bunch of Maven plugins, in particular we now create CylcloneDX files using
  version 1.6 of the schema.
  PR https://github.com/xmlunit/xmlunit/pull/292

* updated bytebuddy dependency of xmlunit-assertj to 2.12.23 in order
  to support Java 17 properly

* Migrated form TravisCI to CircleCI
  Issue https://github.com/xmlunit/xmlunit/pull/289

* Migrated to Sonatype's Central Portal
  Issue https://github.com/xmlunit/xmlunit/issues/287

* added a new BOM artifact xmlunit-bom
  Issue https://github.com/xmlunit/xmlunit/issues/268

* `Comparison` has earned a new convenience constructor.
  PR https://github.com/xmlunit/xmlunit/pull/280 by @hiufung-kwok

* `Input.from` now detects `Reader` arguments and uses `fromReader`.
  PR https://github.com/xmlunit/xmlunit/pull/281 by @SThomasP

# List of changes for XMLUnit for Java

* placeholders can now also be used inside of the local part of `xsi:type` attributes.
  PR https://github.com/xmlunit/xmlunit.net/pull/49

* PlaceholderDifferenceEvaluator would cause InvalidCastException for documents with
  differences in `xsi:type` attributes.
  Equivalent of XMLUnit Java Issue https://github.com/xmlunit/xmlunit/issues/276

* added readme files for the nuget packages.
  Issue https://github.com/xmlunit/xmlunit.net/issues/46

* the NUnit 4.x constraints package tags nunit3 rather than nunit4.
  PR https://github.com/xmlunit/xmlunit.net/issues/43

* added Cyclone DX SBOMs to release artifacts
  Issue https://github.com/xmlunit/xmlunit.net/issues/47

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAmgqrAwACgkQohFa4V9ri3IKJwCcDKVzeR2Lr3fK9q5BGErDBmKe
7T0AniaM9lUTNo0jxuCDWkwkwqKi38lL
=zB7B
-----END PGP SIGNATURE-----

Back when I releasedXMLUnit.NET 2.10.0 I claimed the NUnit 3.x
constraints would nowsupport NUnit 4.x as well. Unfortunately I never
really tested this and it turns out to be wrong. NUnit 4.x is a major
release and it has broken backwards compatibility (it is a major
version, after all) in a way that doesn't seem to allow using the same
constraint implementation for 3.x and 4.x.

XMLUnit 2.11.0 adds a new XMLUnit.NUnit4.Constraints package with
constraints for NUnit 4.x. This package requires at least .NET 6 or .NET
Framework 4.6.2 - the minimum frameworks supported by NUnit 4.x.

Hi Andy

Andy Kwok <hiu...@gm...> writes:

> Recently I have some time for contribution and I have checked the Jacoco
> coverage report for xmlUnit Java project,
>
> I wonder if it makes sense for me to write a few more tests to bring up the
> coverage first?

Back when Travis worked reliably we used to have coveralls reports and
have always been in the 92+ percentage range of coverage, so there
probably isn't that much untested code - at least I'd hope so.

https://coveralls.io/github/xmlunit/xmlunit

Please don't waste your time writing tests for trivial code like getters
and setters for properties and things like this. We are writing tests to
improve reliablity and catch regressions, not to make any statistics
happy.

I'm not sure whether coveralls is smarter than Jacoco. Some code paths
in core may only be covered by tests run in one of the other modules - I
don't believe the jacoco report would see that.

Cheers

        Stefan

Hi team,

Recently I have some time for contribution and I have checked the Jacoco
coverage report for xmlUnit Java project,

I wonder if it makes sense for me to write a few more tests to bring up the
coverage first?

PS: I'm planning to also work on some of the opening issues reported on
Github, but I'm thinking it's probably better to contribute some more tests
first, before making any changes on the codebase.

Thanks,

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* adjusted the NUnit 3.x constraints so they should work for NUnit 4.x  as well.
  Issue https://github.com/xmlunit/xmlunit.net/issues/40

* add a new `ElementSelectors.ByNameAndAllAttributes` variant that
  filters attributes before deciding whether elements can be compared.
  Inspired by Issue https://github.com/xmlunit/xmlunit/issues/259

* `Nodes.GetMergedNestedText` and `Nodes.StripElementContentWhitespace`
  had the same problem of not knowning about `XmlWhitespace` that caused
  Issue  https://github.com/xmlunit/xmlunit.net/issues/38 .
  And neither of the methods could deal with `XmlSignificantWhitespace` at all.

* add `XmlWhitespaceStrippedSource`, `XmlWhitespaceNormalizedSource`,
  and `XmlElementContentWhitespaceStrippedSource` that only trim
  characters that are considered whitespace by the XML Specification
  from textual content.  Also added new modifiers to `DiffBuilder` that
  make use of the new `ISource` types.
  Issue https://github.com/xmlunit/xmlunit.net/issues/39
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAma1HLUACgkQohFa4V9ri3JFBwCeKNK2GmPRnNNZ2QfZz5D8A9Wp
FtYAnifFBAhnJ8wih4dYnSTLcOKrejAM
=EzA2
-----END PGP SIGNATURE-----

Hi all

XMLUnit for Java's Transform's default transformation allowed the use of
XSLT extension functions - this has been change in 2.10.0.

If you've been using XMLUnit to run XSLT transformations with untrusted
stylesheets and your setup is so that an attacker can chose the
stylesheet and ensure your XSLT processor can run the extensions this
may lead to a remote code execution in the worst setup. Therefore the
old default has been assigned CVE-2024-31573 .

Some XSLT processors - e.g. Apache Xalan - allow the extension code to
be specified inline with an Apache BSF enabled scripting language - note
that would require your code executing the transformation to also have
BSF around. In outher cases your transformation would need to allow the
attacker to also inject Java classes into your running process. This
combined with my believe that XMLUnit is very unlikely to be run in a
setup like this made me set the impact to "Low".

Advisory: https://github.com/xmlunit/xmlunit/security/advisories/GHSA-chfm-68vv-pvw5

Stefan

This is a release with small ehancements. Most notable are changed
defaults that try to disable the execution of extension functions in
XSLT and XPath.

* add a new `ElementSelectors.byNameAndAllAttributes` variant that
  filters attributes before deciding whether elements can be compared.
  Inspired by Issue https://github.com/xmlunit/xmlunit/issues/259

* By default the `TransformerFactory`s created will now try to disable
  extension functions. If you need extension functions for your
  transformations you may want to pass in your own instance of
  `TransformerFactory` and `TransformerFactoryConfigurer` may help with
  that.
  Inspired by Issue https://github.com/xmlunit/xmlunit/issues/264

* `JAXPXPathEngine` will now try to disable the execution of extension
  functions by default but uses `XPathFactory#setProperty` which is not
  available prior to Java 18. You may want to enable secure processing
  on an `XPathFactory` instance you pass to `JAXPXPathEngine` instead -
  and `XPathFactoryConfigurer` may help with that.

Hi all

this should come as no surprise to anybody, there hasn't been a release
of XMLUnit 1.x in more than nine years. XMLUnit 2.x has long taken over
and its legacy module seems to be working for some people.

With this mail I'm just stating publically what has been true for a long
time. There will be no new XMLUnit 1.x releases and bugs are not going
to be fixed (no matter how severe). Please migrate to the legacy module
or even better to XMLUnit 2.x APIs. I will accept bug reports against
the legacy module and will try to fix them.

Stefan

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all

I've just released a small minor release of XMLUnit.NET that fixes a bug
with whitespace normalization/stripping and adds a small feature
simplifying the use of NodeFilters.

Full list of changes:

* added NodeFilters#SatisfiesAll and SatifiesAny methods to make
  it easier to combine multiple node filters.
  added to simplify the use case of https://github.com/xmlunit/xmlunit/issues/249

* when documents contained element content whitespace represented by
  System.Xml.XmlWhitespace the types and methods that are supposed
  to strip or normalize whitespace would fail.
  Issue https://github.com/xmlunit/xmlunit.net/issues/38

Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAmQTQNEACgkQohFa4V9ri3Ip+wCg0smjRUll8FTWjOvxps/6O3X1
vYIAn3NXjvBBGUTdBOBt/vfwNYJWhmjS
=V9rC
-----END PGP SIGNATURE-----

full list of changes:

* fixed some AssertJ tests that didn't work on Windows.
  Issue #252 and PR #253 by @Boiarshinov

* added overloads to ElementSelectors.byXPath that accept a XPathEngine argument.
  Issue #255

* added Cyclone DX SBOMs to release artifacts

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The major change of XMLUnit for Java 2.9.0 is the addition of a new
module xmlunit-jakarta-jaxb-impl that can be used in addition to
xmlunit-core when you want to use the Jakarta XML Binding API in
version 3. For details please see the user's guide at
https://github.com/xmlunit/user-guide/wiki/JAXB .

The full list of changes of XMLUnit for Java 2.9.0 is:

* added a new module xmlunit-jakarta-jaxb-impl that makes
  Input.fromJaxb use jakarta.xml.bind rather than
  javax.xml.bind. For more details see the User's
  Guide.

  This change is not fully backwards compatible. The JaxbBuilder class
  has become abstract and the withMarshaller method has changed its
  signature. For most cases the change will not be noticed and for
  almost all other cases it should be enough to re-compile your code
  against XMLUnit 2.9.x.

  Issue #227 and PR #247

* added NodeFilters#satisfiesAll and satifiesAny methods to make it
  easier to combine multiple node filters. added to simplify the use
  case of #249
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAmHwNkYACgkQohFa4V9ri3L33gCeJ3byfOgI8sUrXiD2hj1XXaqY
d0sAoIGVFfs65FAK9ZwWEhErOSCxKJWr
=CsyX
-----END PGP SIGNATURE-----

the last announcement had the wrong version for XMLUnit.NET the new
release is 2.9.1 not 2.9.2.

sorry

        Stefan

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all

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

* 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 to Diff that provides a
  string-representation of all differences - not just the first one like
  ToString 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.

Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAmG7ogUACgkQohFa4V9ri3Ky+wCfYmi9SArsqee6T3WcimPmAEh5
j5UAoNnK+5ITL9ZLk+r8zJBbhcaykajd
=5Ft2
-----END PGP SIGNATURE-----

On 12/09/21, Stefan Bodewig wrote:
>On 2021-11-18, Stefan Bodewig via Xmlunit-general wrote:
>
>> On 2021-11-17, Amarendra Godbole via Xmlunit-general wrote:
>>
>> > I wanted to highlight that the signature on xmlunit-1.3.jar is bad and
>> > won't verify with the key. However, it verifies fine on the associated .pom
>> > file.
>>
>> Thank you.
>>
>> I can confirm the signature is reported as bad. The non-crypto checksums
>> seem to be fine, but that's no guarantee things haven't been tampered
>> with.
>
>[...]
>
>> I'll ask Sonatype for advice.
>
>The policy for Maven Central forbids replacing the jar - even if I could
>create a new one - so the only advice is to tell people not to use
>XMLUnit 1.3 and use a more recent version instead. Which is the best for
>our users anyway as XMLUnit 1.x is not really supprted anymore.
[...]

Thanks and yes, we have upgraded to a more recent version already, 
though wanted to clarify the bad signature. Appreciate the follow-up.

-ag

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.

On 2021-11-18, Stefan Bodewig via Xmlunit-general wrote:

> On 2021-11-17, Amarendra Godbole via Xmlunit-general wrote:
> 
> > I wanted to highlight that the signature on xmlunit-1.3.jar is bad and
> > won't verify with the key. However, it verifies fine on the associated .pom
> > file.
> 
> Thank you.
> 
> I can confirm the signature is reported as bad. The non-crypto checksums
> seem to be fine, but that's no guarantee things haven't been tampered
> with.

[...]

> I'll ask Sonatype for advice.

The policy for Maven Central forbids replacing the jar - even if I could
create a new one - so the only advice is to tell people not to use
XMLUnit 1.3 and use a more recent version instead. Which is the best for
our users anyway as XMLUnit 1.x is not really supprted anymore.

Stefan

On 11/18/21, Stefan Bodewig wrote:
>On 2021-11-17, Amarendra Godbole via Xmlunit-general wrote:
>
>> I wanted to highlight that the signature on xmlunit-1.3.jar is bad and
>> won't verify with the key. However, it verifies fine on the associated .pom
>> file.
>
>Thank you.
>
>I can confirm the signature is reported as bad. The non-crypto checksums
>seem to be fine, but that's no guarantee things haven't been tampered
>with.
>
>Unfortuantely I haven't got any archive of the release I created more
>than twelve years ago so I cannot faithfully say whether the file is the
>one I created and something went wrong with the signature back then or
>the file really is bad.
>
>I'll ask Sonatype for advice.

Let me know what you find out from Sonatype.

>At least the signature for xmlunit-1.6.jar seems to be fine as well as
>some of the 2.x releases I've checked seem to be fine.
>
>Stefan
[...]

Thanks for the confirmation, we have upgraded to 1.6, and signatures
check out fine.

-ag

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.

On 2021-11-17, Amarendra Godbole via Xmlunit-general wrote:

> I wanted to highlight that the signature on xmlunit-1.3.jar is bad and
> won't verify with the key. However, it verifies fine on the associated .pom
> file.

Thank you.

I can confirm the signature is reported as bad. The non-crypto checksums
seem to be fine, but that's no guarantee things haven't been tampered
with.

Unfortuantely I haven't got any archive of the release I created more
than twelve years ago so I cannot faithfully say whether the file is the
one I created and something went wrong with the signature back then or
the file really is bad.

I'll ask Sonatype for advice.

At least the signature for xmlunit-1.6.jar seems to be fine as well as
some of the 2.x releases I've checked seem to be fine.

Stefan

Hi,

I wanted to highlight that the signature on xmlunit-1.3.jar is bad and
won't verify with the key. However, it verifies fine on the associated .pom
file. Hosted here: https://repo1.maven.org/maven2/xmlunit/xmlunit/1.3/ (we
verified with a download from the official sourceforge site as well).

ag@mac $ gpg --verify xmlunit-1.3.jar.asc xmlunit-1.3.jar
gpg: Signature made Mon Sep 21 12:20:23 2009 PDT
gpg:                using DSA key A2115AE15F6B8B72
gpg: BAD signature from "Stefan Bodewig <bo...@ap...>" [unknown]

Thanks.

-ag

-- 
sent via recycled electrons, from a portable command center.

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 to Diff that provides a
  string-representation of all differences - not just the first one like
  toString 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAmFsf0YACgkQohFa4V9ri3KUWACcD75lls/rO9Lr52LJcEcnnjw4
mIQAn1yuKqE9a4Sv4SFVTMm5yEP5HLvC
=TAkV
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAl/gZzwACgkQohFa4V9ri3JmywCdG6qL1cTI2WXCLTqiin8Au52x
7eAAn3wjG9K2vk4g7ggQV6llhzmRIFyY
=EV5D
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.x ComparisonException but an opentest4j
  AssertionFailedError 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAl+xG2wACgkQohFa4V9ri3KDtACfYvj3UeDc/igj2T4DAKF8kO0B
2LkAoMKRXt8EoS2MJJvjZzZb2Egq9+bx
=K2Su
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 to MultipleNodeAssert 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 multiple ElementSelectors could fail to find
  the best matches as the order of ElementSelectors should select them.
  #197

* Input builder now supports java.nio.file.Path
  #196

* It is now possible to specify a custom TransformerFactory for
  DefaultComparisonFormatter.
  #195

Details for XMLUnit.NET 2.9.0
- -----------------------------

* ISource now extends IDisposable to allow releasing unmanaged resources
  used when building sources from files or URIs.

  This change is backwards incompatible if you are providing ISource
  implementations of your own.

  #33

* DefaultNodeMatcher with multiple ElementSelectors could fail to find
  the best matches as the order of ElementSelectors should select them.
  Issue similar to xmlunit/#197

These two releases contain an incompatible change to the
`(I)PlaceholderHandler` interface, thus the new minor versions. The
`Evaluate` method now receives a variable number of string arguments in
addition to the textual content of the element/attribute. This allows
placeholders like `${xmlunit.matchesRegex(some\s*regex)}`.

For XMLUnit.NET only the placeholders package has changed, for Java in
addition the assertj module is now supposed to be compatible with
AssertJ 3.15+.

Release Notes for XMLUnit for Java 2.7.0:

* the AssertJ tests now pass on non-English locales as well
  Issue #180

* added a workaround for a binary incompatible change in AssertJ that
  caused xmlunit-assertj to be incompatible with AssertJ 3.15.0
  Issue #181

* added a new `${xmlunit.matchesRegex(regex)}` placeholder
  PR #178 by @Jazzyekim

* add a new `${xmlunit.isDateTime}` placeholder
  inspired by #xmlunit.net/31 and #xmlunit.net/32 by @MilkyWare
  Issue #174

* avoid unnecessary creation of `DocumentBuilderFactory` in
  `DOMDifferenceEngine` when a custom factory has been provided to
  `DiffBuilder`.
  Issue #182

Release Notes for XMLUnit.NET 2.8.0:

* add a new `${xmlunit.isDateTime}` placeholder
  PRs #31 and #32 by @MilkyWare

* added a new `${xmlunit.matchesRegex(regex)}` placeholder
  based on Java PR xmlunit/#178 by @Jazzyekim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAl660mgACgkQohFa4V9ri3LfzACeLduOx7tWiu0LNW1+GXvgVI2g
Vp4AoMugPOUJPaZS1n+sFKr2A596la5u
=OcD5
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Both releases fix a common bug where the XPath reported for missing
nodes could be wrong in certain edge cases.

* the XPath values for comparisons resulting in `CHILD_LOOKUP`
  differences could be wrong when `NodeFilter`s were present.
  XMLUnit.NET Issue #29 https://github.com/xmlunit/xmlunit.net/issues/29

This is the only change in XMLUnit.NET. In XMLUnit for Java the
AssertJ module has also been improved and is supposed to be compatible
with AssertJ 3.13+ now.

The full list of changes for XMLUnit for Java:

* the dependencies on JAXB implementation and its transitive
  dependencies has been promoted from test scope to optional for Java
  9 and later
  Issue #162 https://github.com/xmlunit/xmlunit/issues/162

* added `containsAnyNodeHavingXPath`, `containsAllNodesHavingXPath`
  and `hasXPath` assertions to xmlunit-assertj.

* added `extractingAttribute` method to xmlunit-assertj.

* removed some redundant `instanceof` checks.
  PR #171 https://github.com/xmlunit/xmlunit/issues/171 by
  @PascalSchumacher

* xmlunit-assertj should now work with AssertJ-Core 3.13.x
  Issue #166 https://github.com/xmlunit/xmlunit/issues/166

* xmlunit-legacy will now use `NewDifferenceEngine` even when an
  `ElementQualifier` different from the built-in ones is used.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAl5lAY8ACgkQohFa4V9ri3LOegCdHx0AFSueBH6ux2YE83JxEZqP
UfwAoJ2sY/NNJDjl2o0LoG+DzFrQLVgQ
=baz+
-----END PGP SIGNATURE-----

2002	Jan	Feb	Mar	Apr	May (2)	Jun	Jul	Aug (2)	Sep	Oct	Nov	Dec
2003	Jan (2)	Feb (8)	Mar	Apr	May (2)	Jun (4)	Jul (1)	Aug	Sep	Oct (3)	Nov	Dec (2)
2004	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (2)
2005	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (1)	Nov	Dec
2006	Jan	Feb	Mar	Apr (1)	May	Jun (1)	Jul	Aug	Sep	Oct	Nov	Dec (6)
2007	Jan (12)	Feb (17)	Mar (13)	Apr (20)	May (36)	Jun (5)	Jul (3)	Aug (1)	Sep (1)	Oct	Nov (11)	Dec (5)
2008	Jan (9)	Feb (3)	Mar (19)	Apr (20)	May (8)	Jun (18)	Jul (1)	Aug	Sep (2)	Oct (2)	Nov (4)	Dec
2009	Jan	Feb	Mar (3)	Apr (6)	May (12)	Jun (6)	Jul (2)	Aug (2)	Sep (5)	Oct (4)	Nov (2)	Dec (2)
2010	Jan	Feb (2)	Mar (6)	Apr (3)	May (5)	Jun (2)	Jul	Aug (4)	Sep (3)	Oct (3)	Nov	Dec (3)
2011	Jan (2)	Feb (10)	Mar (6)	Apr	May	Jun	Jul	Aug	Sep (7)	Oct (4)	Nov	Dec
2013	Jan	Feb (3)	Mar (1)	Apr (13)	May (2)	Jun	Jul	Aug	Sep (1)	Oct (5)	Nov	Dec
2014	Jan	Feb	Mar	Apr	May (2)	Jun	Jul	Aug	Sep (1)	Oct	Nov	Dec (17)
2015	Jan (28)	Feb (33)	Mar (1)	Apr	May (1)	Jun	Jul (2)	Aug (2)	Sep	Oct (2)	Nov (2)	Dec (1)
2016	Jan	Feb (1)	Mar (2)	Apr (1)	May	Jun (2)	Jul	Aug	Sep	Oct	Nov (1)	Dec
2017	Jan	Feb	Mar (1)	Apr	May	Jun	Jul (1)	Aug	Sep (1)	Oct (1)	Nov (1)	Dec
2018	Jan	Feb	Mar	Apr (1)	May	Jun	Jul	Aug (2)	Sep	Oct	Nov	Dec
2019	Jan	Feb	Mar	Apr (2)	May	Jun (1)	Jul	Aug	Sep	Oct	Nov	Dec
2020	Jan	Feb	Mar (1)	Apr	May (1)	Jun	Jul	Aug	Sep	Oct (1)	Nov (1)	Dec (1)
2021	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (1)	Nov (3)	Dec (4)
2022	Jan (1)	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2023	Jan (1)	Feb	Mar (1)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2024	Jan (1)	Feb	Mar	Apr (1)	May (1)	Jun	Jul	Aug (1)	Sep (2)	Oct	Nov	Dec
2025	Jan	Feb	Mar (1)	Apr	May (2)	Jun	Jul	Aug	Sep	Oct	Nov	Dec

xmlunit-general Mailing List for XML Unit

XMLUnit provides assertions that help testing code that produces XML.

xmlunit-general — Everything XMLUnit ;0)