On 11/23/09, Felipe Gaścho <fgaucho_at_gmail.com> wrote:
> Now, I have some questions, mainly regarding modularization issues.
> Maybe you could help me on this:
>
> - Let's assume we have module A with a.xsd inside and module B with
> b.xsd. a.xsd defines type t, type u and type v; type u is abstract.
> a.xsd uses the types t and v and extends type u.
>
> The question is now if it's possible to generate the according
> JAXB-Java-classes at build time for every module separately. This would
> mean that we have calsses for the types t, u and v in module A. And
> class that extends type u in module B. This would mean that during build
> time of module B, JAXB has to know that the classes of a.xsd have been
> generated already and as well their names and packages.
> - Is this possible?
Yes.
> - Does this make sense?
Yes.
The way to do this (without customization) is to put the Schema definitions for
types t, u, v into a namespace resulting in the package name for A and
the things that use (and extend) these types into B's namespace. The
schema b.xsd
would use xsd:import schema a.xsd so that there is only one glorious
xjc run, producing all classes at the same time.
Outlines for a.xsd and b.xsd:
<xsd:schema xmlns:xsd="
http://www.w3.org/2001/XMLSchema"
targetNamespace="/some/where/a"
xmlns:a="/some/where/a">
</xsd:schema>
<xsd:schema xmlns:xsd="
http://www.w3.org/2001/XMLSchema"
targetNamespace="/some/where/b"
xmlns:b="/some/where/b"
xmlns:a="/some/where/a">
<xsd:import namespace="/some/where/a"
schemaLocation="a.xsd"/>
<!-- Refer to a definition from a.xsd, e.g.: -->
<xsd:element name="foo" type="a:u"/>
</xsd:schema>
>
> Another question is about file resolving.
> - Is there a possibility to provide an alternative file resolver (e.g.
> that looks referenced schema files up in the classpath)?
Your question isn't clear to me. Schema files (presumably to be used
for validation) aren't different from any other data files in your
classpath. Class.getResourceAsStream(String path) should do the trick.
-W