[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [wtp-dev] project-specific XSD resolution question
|
Hey Jesper!
I got this working using the project-specific URIs that you suggested.
Thanks again very very very much for your help!!!
While this is working for most of the cases, it fails in this case:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=399649
Any idea how to work around that?
Thanks!
-Martin
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
On Wed, Jan 30, 2013 at 11:39 AM, Martin Lippert <lippert@xxxxxxx
<mailto:lippert@xxxxxxx>> wrote:
Hey Jesper!
The XSL tooling plugin uses a resolverExtension to accomplish
something similar. You may be able to find pointers there.
IIRC, it is the core plugin. Mind you, they will be cases where
you can't find a project, in case a resource is loaded directly
from the file system, e.g. with File > Open
Firstofall, thanks for your answer and the pointer!!!
I looked into this in more detail. The problem for me seems to be:
In case an XML file is being parsed, I get the XML file from my
workspace as IFile parameter into this method call:
URIResolverExtension.resolve(__IFile file, String baseLocation,
String publicId, String systemId);
That is great and I can identify the project this file comes from.
But if the XSD refers another XSD, the lookup of the corresponding
project seems to fail in ExtensibleURIResolver:
public String resolve(String baseLocation, String publicId,
String systemId)
{
String result = systemId;
// compute the project that holds the resource
//
IFile file = computeFile(baseLocation);
because the baseLocation is now pointing to the location of the XSD
- and that is inside my local Maven repo, for example (so not in my
workspace). Therefore this lookup (computeFile) fails and I get no
information for which project this lookup should happen.
Any idea how this could be solved?
Thanks for your help!
-Martin
-Jesper
On 21/11/2012, at 17.04, Martin Lippert <lippert@xxxxxxx
<mailto:lippert@xxxxxxx>> wrote:
Hey!
A while ago I asked this question, which is still open on my
end and I am still hoping to find some help here. Any idea?
That would be really really great!
Thanks!
-Martin
On 15.06.12 15:51, Martin Lippert wrote:
Hey!
We have implemented project-specifc XSD resolution for
the Spring IDE,
but are still suffering from a few cases where we don't
get any
information about the project for which the XSD should
be resolved. And
I would love to hear from you whether this is possible
at all, and what
I maybe need to take a look at in this case.
We have implemented the extension point:
org.eclipse.wst.common.__uriresolver.resolverExtensions
with stage=postnormalization
But that doesn't seem to always give us the necessary
information to
which project this resolving belongs to. And I am not
sure whether the
webtools allows us to fully implement this.
Any pointers and help highly appreciated!
-Martin
_________________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx <mailto:wtp-dev@xxxxxxxxxxx>
https://dev.eclipse.org/__mailman/listinfo/wtp-dev
<https://dev.eclipse.org/mailman/listinfo/wtp-dev>
_________________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx <mailto:wtp-dev@xxxxxxxxxxx>
https://dev.eclipse.org/__mailman/listinfo/wtp-dev
<https://dev.eclipse.org/mailman/listinfo/wtp-dev>
_________________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx <mailto:wtp-dev@xxxxxxxxxxx>
https://dev.eclipse.org/__mailman/listinfo/wtp-dev
<https://dev.eclipse.org/mailman/listinfo/wtp-dev>
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
