First of all, congratulations and thanks for the major cleanup!

Some remarks:

• 1. mkdir() in ResourceCache when creating the cache directory should really be mkdirs(): with the cache directory inside the .xmlresolver.org one, one-step mkdir() is guaranteed to fail where the .xmlresolver.org directory does not exist. (Cache subdirectories are created one level at a time, so mkdir() works there.)
  • confirmed fixed
• 2. Version 3.0.1 caches (URIs rewritten to local) file: URIs, not just the "legacy V2"; version 1.x did not. Current 3.0.2-SNAPSHOT continues to do the same; this is probably caused by the failure to write the control.xml file, which in turn seems to be caused by the underlying parser (in my case, SAXParserFactory.newInstance() finds Saxon 6.5.2's aelfred) throwing an EOFException (and not the FileNotFoundException) when trying to parse the non-existent control.xml file.
  • confirmed fixed
• 3. With the cache disabled (because of the problem 1 above or intentionally, e.g. by setting CACHE_UNDER_HOME to false), such URIs fail to resolve; see below.
  • works as designed: the parser is going to turn around and arrive at exactly the same result
• 4. ValidatingXmlLoader uses its own private XMLResolverConfiguration instance with the cache disabled, so the URIs mentioned above fail to resolve when ValidatingXmlLoader is used.
  • confirmed fixed
• 5. For ValidatingXmlLoader to work at all, dependency 'org.relaxng:jing:20181222' has to be available; this probably should be documented...
  • documented
• 6. Resolver is now sensitive to the "uriStartString" ending with /; version 1.x was not.
  • works as designed
• 7. Different implementations of slf4j can be used in different environments (e.g., on Google Cloud Run, logback is likely to be used; inside a Gradle plugin Gradle-supplied implementation is used, etc.). xmlresolver brings in 'org.slf4j:slf4j-simple', which needs to be excluded in the Gradle build files of the project using xmlresolver. In my humble opinion, xmlresolver should not have (production) dependency on any slf4j implementations... (And: all implementation dependencies are unnecessarily listed also as runtimeOnly; 'org.slf4j:slf4j-api' may as well be listed as compileOnly and not as implementation dependency.)
  • confirmed fixed