I've been trying to get the maven-jaxb2-plugin to generate a JAXB jar out of XSDs that are stored inside a dependency that I have no control of. This was quite doable for a simple, single XSD Maven dependency that didn't import any other schemas, but when dealing with a more complex schema that did import multiple other XSDs from the same dependency jar, it didn't "just" work. After trying many approaches I found a solution however.

First lets see what the structure of the Maven dependency jar file looked like. This was the jar that contained XSDs that I was interested in.

Jar Structure

my-dependency.jar

\-- org

\-- some

\-- package

\

|-- ns1.xsd

|-- ns2.xsd

|-- ns3.xsd

So the 'ns1.xsd' was the primary file for the schema. Inside it contained two imports, for both the other XSD files in the same package. That all looked like...

at com.sun.xml.xsom.impl.parser.NGCCRuntimeEx.resolveRelativeURL(NGCCRuntimeEx.java:229)

at com.sun.xml.xsom.impl.parser.NGCCRuntimeEx.importSchema(NGCCRuntimeEx.java:256)

After trying a myriad of different catalog REWRITE_SYSTEM combinations, I was ready to give up and just extract the XSDs to my project, but then I came across this which resolved all the errors that XJC was throwing at me. Incidentally when running as 'mvn -X' I could see that my rewrites were working and both ns2.xsd and ns3.xsd were being resolved to the correct Maven dependency, but for some reason they were still not being picked up.

The solution was to use a URL reference to the primary XSD and then in my catalog file to rewrite that URL to the Maven dependency location.

So my maven-jaxb2-plugin configuration contained the following (the URL didn't have to resolve to any public facing URL, it was just a placeholder in that case)...

pom.xml

<strict>false</strict>

<catalog>src/main/resources/catalog.cat</catalog>

<schemas>

<schema>

<url>http://someurl/schema/ns1.xsd</url>

</schema>

</schemas>

The catalog file contained a single line that rewrote the URL above to the Maven dependency I was using. Note that the rewriting is done up to the package that the XSDs reside in.

That was it! It worked like a charm! The only other place I had to change was in my binding.xml file. Because I had some property renaming to be do, I couldn't reference schemas by their file names and instead had to use the URL from above. For example...