build(deps): bump xmlresolver.version from 4.6.4 to 5.2.0

[dependabot]

Bumps xmlresolver.version from 4.6.4 to 5.2.0.
Updates xmlresolver from 4.6.4 to 5.2.0

Release notes

Sourced from xmlresolver's releases.

5.2.0

Version 5.2.0 adds a new API for constructing a catalog directly from a stream of SAX events. This makes it possible to construct a catalog directly from a database, for example, or from a novel format.

5.1.3

Fixes a small bug wherein same document references were not handled correctly if the ALWAYS_RESOLVE feature was true.

5.1.2

This release removes the (transitive) dependency on the xml-apis jar file. There's also one new log message for tracking catalogs that are loaded.

5.1.1

Enforce ACCESS_* features when opening connections

The new ALWAYS_RESOLVE feature means that the resolver will sometimes access resources on behalf of the caller (ones that were not found in the catalog). That feature failed to take the ACCESS_EXTERNAL_DOCUMENT and ACCESS_EXTERNAL_ENTITY features into consideration.

5.1.0

The 5.1.0 release fixes a significant bug in the new ALWAYS_RESOLVE feature. See #133

5.0.0

The Java contract for the entity resolver is to return null if the entity isn't found. Unfortunately, redirects are common these days (for example, w3.org redirects all http: URIs to https: URIs) and parsers don't always follow redirects, so if the resolver returns null, the parse fails. That's...suboptimal.

This release adds a new feature ResolverFeature.ALWAYS_RESOLVE that will resolve the resource (and follow redirects to do so) and always return it. This feature is true by default.

This release also extends the ResolverInputSource to expose the response code (if applicable) and headers (if available) from the response.

Commits

• c59628a Merge pull request #147 from xmlresolver/ver-520
• d9c3da7 XML Resolver 5.2.0 release
• 2502d31 Remove dead repo
• 2a5fa4a Merge pull request #146 from ndw/improve-docs
• 6b74e8c Improved JavaDoc for the SAX loader
• 9c82811 Improved; added notes about ALWAYS_RESOLVE and SAX producer
• 78c14bb Merge pull request #145 from ndw/loader-test
• f979f55 Add a unit test for the SaxProducer loader
• 33dd7c3 Merge pull request #144 from ndw/gradle8
• a71aa89 Upgrade build to Gradle 8.1.1
• Additional commits viewable in compare view

Updates xmlresolver from 4.6.4 to 5.2.0

Release notes

Sourced from xmlresolver's releases.

5.2.0

Version 5.2.0 adds a new API for constructing a catalog directly from a stream of SAX events. This makes it possible to construct a catalog directly from a database, for example, or from a novel format.

5.1.3

Fixes a small bug wherein same document references were not handled correctly if the ALWAYS_RESOLVE feature was true.

5.1.2

This release removes the (transitive) dependency on the xml-apis jar file. There's also one new log message for tracking catalogs that are loaded.

5.1.1

Enforce ACCESS_* features when opening connections

The new ALWAYS_RESOLVE feature means that the resolver will sometimes access resources on behalf of the caller (ones that were not found in the catalog). That feature failed to take the ACCESS_EXTERNAL_DOCUMENT and ACCESS_EXTERNAL_ENTITY features into consideration.

5.1.0

The 5.1.0 release fixes a significant bug in the new ALWAYS_RESOLVE feature. See #133

5.0.0

The Java contract for the entity resolver is to return null if the entity isn't found. Unfortunately, redirects are common these days (for example, w3.org redirects all http: URIs to https: URIs) and parsers don't always follow redirects, so if the resolver returns null, the parse fails. That's...suboptimal.

This release adds a new feature ResolverFeature.ALWAYS_RESOLVE that will resolve the resource (and follow redirects to do so) and always return it. This feature is true by default.

This release also extends the ResolverInputSource to expose the response code (if applicable) and headers (if available) from the response.

Commits

• c59628a Merge pull request #147 from xmlresolver/ver-520
• d9c3da7 XML Resolver 5.2.0 release
• 2502d31 Remove dead repo
• 2a5fa4a Merge pull request #146 from ndw/improve-docs
• 6b74e8c Improved JavaDoc for the SAX loader
• 9c82811 Improved; added notes about ALWAYS_RESOLVE and SAX producer
• 78c14bb Merge pull request #145 from ndw/loader-test
• f979f55 Add a unit test for the SaxProducer loader
• 33dd7c3 Merge pull request #144 from ndw/gradle8
• a71aa89 Upgrade build to Gradle 8.1.1
• Additional commits viewable in compare view

You can trigger a rebase of this PR by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

> **Note** > Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

[adamretter]

Hmmm... I cannot reproduce the test failures when running CollectionConfigurationValidationModeTest from IntelliJ on this branch.
I will try and run the full test suite locally and see what happens...

[adamretter]

From running the full test-suite locally I do see two failures in CollectionConfigurationValidationModeTest

insertModeAuto

java.lang.AssertionError: exerr:ERROR XMLDB reported an exception while storing document: The XML parser reported a problem: warning at (1,157) : schema_reference.4: Failed to read schema document '', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not <xsd:schema>. [at line 1, column 1, source: String/-8162933849824779821]
	at org.junit.Assert.fail(Assert.java:89)
	at org.exist.validation.CollectionConfigurationValidationModeTest.insertModeAuto(CollectionConfigurationValidationModeTest.java:185)

insertModeTrue

java.lang.AssertionError: exerr:ERROR XMLDB reported an exception while storing document: The XML parser reported a problem: warning at (1,157) : schema_reference.4: Failed to read schema document '', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not <xsd:schema>. [at line 1, column 1, source: String/-5880094038311784252]
	at org.junit.Assert.fail(Assert.java:89)
	at org.exist.validation.CollectionConfigurationValidationModeTest.insertModeTrue(CollectionConfigurationValidationModeTest.java:143)

---

This is going to take a bit of time to figure out...

[dependabot]

Superseded by #5022.