Nevermind.
Pilot error.
In trying to create a small reproducible example, I found that one *CAN* in
fact assemble a Jar File URI as a string, with an appropriate path, and
then you CAN open a stream and it opens the right jar file.
It does require string hacking. The call
>
>
> Instead of feeding the new resource path (e.g. /d1/quux.dfdl.xsd) into
> getResource, can you strip off everything after the exclamation in the
> original jar path, append that new resource path, and use that as the
> new URI? This way there is no resource look up at all for relative paths.
The recent changes in Daffodil to include/import resolution was done
with the intention that relative paths were only expected only be found
in the same jar, and only absolute paths would look on the classpath.
This was done to make it for very simple logic to be used to transform
schemas to a
As of Java 20, the constructors for Java.net.URL have all been deprecated.
This has some implications for us. The matter is rather subtle, so bear
with me.
We use URL constructors so that a non-hierarchical URL, such as
jar:file:/foo.jar!/d1/d2/baz.dfdl.xsd can resolve a relative path such as
