Announcement Announcement Module
Collapse
No announcement yet.
Importing XSDs from other projects Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Importing XSDs from other projects

    I don't think this is an STS-specific issue, but I'm not sure, so I'll throw this out here.

    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. We're moving to a Maven- and plugin-based architecture over the next few months, however. This will mean lots of little projects that reference back to our primary project(s), including the XSD references.

    So currently these look something like this:

    HTML Code:
    <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

    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 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!
Working...
X