0

I'm working on two large 3rd party schemas, one includes the other and generates a large number of type name collisions. If I could set the package on a namespace this problem would go away.

I hoped something like

<jaxb:bindings namespace="http://www.openapplications.org/oagis/9" >
    <jaxb:schemaBindings>
        <jaxb:package name="org.oagis" />
    </jaxb:schemaBindings>
</jaxb:bindings>

would work, or perhaps

<jaxb:bindings node="/xsd:schema[@targetNamespace='http://www.openapplications.org/oagis/9']">
    <jaxb:schemaBindings>
        <jaxb:package name="org.oagis" />
    </jaxb:schemaBindings>
</jaxb:bindings>

But no joy.

Trying to set on the individual xsd files in that namespace left me with the dread

[ERROR] Multiple <schemaBindings> are defined for the target namespace "http://www.openapplications.org/oagis/9"

Pointers/suggestions are appreciated.

Mike Summers
  • 2,139
  • 3
  • 27
  • 57

1 Answers1

1

This is a bit hard to answer without seeing the whole compilation. However I often got this error when compiling third-party schemas in the case when the same schema was included via different URLs.

I.e. I've implemented a project which compiled an extensive set of OGC Schemas. The problem was that these schemas referenced each other via relative and absolute URLs. So when I customized one of the schemas there were other schemas for the same namespace URI. Since JAXB processes imports and includes, it is not quite transparent what exactly gets compiled. Try to check your XJC logs for cues or - if you compile schemas directly via URLs (which is not recommended) - go through a logging proxy and see what actually gets accessed.

lexicore
  • 42,748
  • 17
  • 132
  • 221
  • Ah, I suspect this is the case. There are "common" schemas that are both included and imported multiple times. Thanks for the tip. – Mike Summers Mar 27 '14 at 11:34
  • Looks like there are a number of issues related to namespaces, import vs include, and recognizing duplicates based on URI. I'm going to have to go in and rationalize/normalize paths and that should clear it up. Thanks for the pointer. – Mike Summers Mar 27 '14 at 14:54
  • Another hint: the best way to approach this is with catalog files. You can basically "replace" URLs with other URLs. My recommendation is to have a complete local copy of schemas you want to compile and configure catalog files for all of the included/imported URLs. Unfortunatelly it is not trivial. I did it a few times, is no fun job. – lexicore Mar 27 '14 at 14:57
  • I was just going down the catalog path :-) Thanks for the validation. – Mike Summers Mar 27 '14 at 16:21