Good to hear you're having progress. The real issue is that the DOM and SAX interfaces do not pass any sort of context down through the layers. Instantiating a new resolver dynamically would take care of that, but Eclipse's URIResolvers / URIResolverExtensions are statically instantiated from the extension-points. Bummer (or API improvement potential?)
>
Any idea how this could be solved?
Would a thread-local variable work for you? While it does make you dependent on the validator's concurrency model (in this case, the Xerces validating parser, right?), it is unlikely to change anytime soon.
Another trick would be to introduce a new URI scheme for the second-level dependencies, and use two resolvers: One resolver (I'm guessing stage="postnormalization") would work on the logical level, and extract the project from the baseLocation,and turn it into a different faux-URL:
resolve(baseLocation, publicId, systemId) would return "my-qualified-file://<project-name-from-baseLocation>/<systemId>"
Another URIResolver (stage="physical") would resolve the faux-URL into the real resource, using the mapping from the authority part of the URI:
resolve("my-qualified-file://<project-name-from-baseLocation>/<systemId>", publicId, <nextLevelSystemId>") would return "file://<wherever-you-find-the-relevant-nextLevelSystemId-on-the-project>"
This should preserve the "logical" URI as the base when getting the second-level dependencies. I'm thinking it does (as it also works for the interface for the XML catalog and cache extensions), but I can't guarantee it. :-|
Did that make sense?
One drawback I could imaging is that if there are problems in actually parsing/validating the referenced resources, you'd expose the faux-URIs to the user. Don't know if that's an issue.
-Jesper
