It is now possible to use a ZIP file as a catalog. If a ZIP file appears on the catalog path, the resolver will search inside the zip file for a catalog and use that catalog (which can, naturally, contain local URI references to other files in the ZIP file).
The test suite contained some erronous references to xmlresolver.com instead of xmlresolver.org
The data for the “data” jar has been moved to a separate repository; it’s now included as a submodule.
ZIP files seem to come in two flavors, one that unzips files into the current directory, and one that unzips files into a common subdirectory.
If every entry in the ZIP file begins with the same directory name (e.g., directory-x.y/), then the resolver looks for directory-x.y/org/xmlresolver/catalog.xml and directory-x.y/catalog.xml. If it finds both, it uses the former.
If there are no leading directories, or if there are different leading directories, or if only some files are in directories, then the resolver looks for org/xmlresolver/catalog.xml and catalog.xml. Once again, if it finds both, it uses the former.
XML Resolver version 3.0.2
The 3.0.2 release fixes a few bugs.
The catalog loader was not resolving XML Catalog DTDs against local versions. This could cause catalogs to fail to load if the system identifier was unreachable. (Issue #47)
The validating catalog loader requires org.relaxng:jing:20181222 to be on your classpath. (This is not a new requirement, but it was not documented in previous releases.)
The code that created the resource cache would fail if more than one level of subdirectory had to be created.
There was a bug in cache initialization where it was possible for the cache to be created without creating a cache control file. In this circumstance, all URIs would be cached, even file: and jar:file URIs that probably shouldn’t be. If you’re using the cache, it might be prudent to review what’s been cached.
If the cache is not successfully initialized, caching is explicitly disabled.
The dependencies on logging libraries have been reworked so that it should be easier to integrate the resolver into your application. The XML Resolver API uses the slf4j-api but does not include a concrete logging back end.
It has been reported that 1.x versions of the XML Resolver did not handle a trailing slash in the uriStartString the same way that the 3.x resolver does. It was determined that this is a bug in the 1.x version and the current behavior is correct.
Improved the way excluded URIs are handled. Added path: URIs to the set of URI patterns excluded from local caching. The path: scheme is used by C# to address into assemblies. It’s excluded here in case the same cache is shared between different applications. (Issue #45)
A number of improvements were made to the unit tests.
XML Resolver 3.0.1
The 3.x release is a major refactoring. Partly this is in aid of porting it to C#, partly it was just to clean up some design issues. The new design has its own data structure for managing the parsed catalogs and supports a wide range of new features.
There’s documentation at XMLResolver.org and a complete sample application that demonstrates many of its features with an application that can parse, validate, and transform documents.
There’s also a new cache control application to help you manage the local, automatic caching features of the resolver, if you use them.
A non-exhaustive list of features and improvements:
The highest-level user features (simply naming the org.xmlresolver.tools.ResolvingXMLReader and org.xmlresolver.Resolver classes for parsers and resolvers) are unchanged. It should be a drop-in replacement with the earlier versions in most cases.
There are new interfaces for easier integration with applications.
There’s a generic “feature” class for extensibility.
Support for automatic identification of catalogs in jar files. Put the jar file on the classpath and resolution will automatically take advantage of resources in that catalog.
Added a “data” jar file to the release that includes a wide range of standard resources.
Improved support for data:, classpath:, and jar: URI schemes.
Reworked implementation of the cache. Added many tests and the separate cache control application.
Reworked the RDDL parsing feature so that it works reliably.
Added an optional validating catalog loader to help find errors in catalogs. (Catalog errors are usually ignored, but being able to find them can quickly identify resolver problems.)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually 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)
dependabot[bot]
commented
3 years ago
Bumps xmlresolver from 2.1.0 to 3.1.0.
Release notes
Sourced from xmlresolver's releases.
... (truncated)
Commits
0477871XML Resolver 3.1.0 released83e9aa3Update the submodule reference to the data repositoryd7afc7bFix #40 by adding a test with spacesd7bc3fdFix #54 by catching the ClassCastException that arises in JDK9+8dccbe8Fix build status badge, now using CircleCIc17451eBump version12800e2Merge pull request #53 from xmlresolver/archived-catalogsf4cccb4Support ZIP files on the catalog path23e5d14Replace bogus xmlresolver.com references with xmlresolver.orgcef3995Bump version to new SNAPSHOTDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually 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)