I'm using SpringSource Tool Suite 2.7.0.M2, which is Eclipse 3.6.2. I'm on Mac OS X 10.6.7, but this issue isn't OS-specific, so for whatever that's worth...
I have an XSD that imports another XSD. In our existing structure, this is in a build structure in the folder system, referenced by a command-line build (an amalgam of ant, maven 1, and maven 2). For obvious reasons, we're moving from that process to a Maven- and plugin-based architecture over the next few months. This will mean lots of little projects that reference back to our primary project(s), including the XSD referenc开发者_StackOverflow中文版es.
So currently these XSDs look something like this:
<xs:schema targetNamespace="http://nrg.wustl.edu/iq" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xnat="http://nrg.wustl.edu/xnat" xmlns:iq="http://nrg.wustl.edu/iq">
<xs:import namespace="http://nrg.wustl.edu/xnat" schemaLocation="../xnat/xnat.xsd"/>
...
</xs:schema>
Like I said, that works in our current structure since there really is an xnat folder located at the same level as my custom schema that's importing that xnat.xsd.
But our new plugin architecture will break this, since plugins for custom types will reference our base project as either:
- Another project in the same STS workspace
- A Maven-managed jar file referenced by the plugin's pom.xml
This causes the import statement to generate a warning, since it can't find the referenced XSD file, and causes references to the defined namespace to generate errors, since it can't find a definition for the namespace against which to validate the referenced elements.
I've tried setting up a delegate catalog in STS, with Key type to match set to URI, the import path (i.e. ../xnat/xnat.xsd) as the Matching start string, and Delegate to this XML Catalog file to the xnat.xsd located through the workspace.
I also set up an XML catalog element that mapped the URI to the xsd file. I had both of these operative at the same time thinking that maybe the delegate would push over to the XML catalog element given that the URI was the same, but no such luck.
So what's the best way to accomplish this? I can turn off XML validation, but I'd really rather have a nice process to pass onto our user base so that they can validate their XML and XSDs as they're working on their plugins. If this would work for both project and Maven-dependency references, so much the better!
Note that, although I'm working in STS, these are NOT Spring configuration files, so they're not going through the validation process with the spring.handler/schema/etc. configuration files...
Thanks for any help you can give on this issue!
精彩评论