Andreas Pakulat wrote:
> I'm trying to parse a whole lot of schema files. I have about 2-5
> "entry" schema files, which I will give to jaxb. Everyone might
> reference other schema files via xs:include or xs:import and those might
> have different targetNamespaces. If I'm not totally mistaken I have
> about 4 or 5 different namespaces. The problem here is I'd have to
> figure out which "other" schema file is first imported from an entry
> schema file for a particular namespace.
No, you don't have to. As long as <jaxb:schemaBindings> is attached to
any schema that has the desired target namespace, that would work.
I often just write an empty schema with the right target namespace +
<jaxb:schemaBindings> to apply a binding.
Something for you to consider.
> I'd also have to have different
> binding files for each entry-schema file as each might use another
> schema file as first one for a particular namespace.
This is also not true, as you can have all your bindings (that apply to
different files) in one binding file, like this:
<binding xmlns='....'>
<binding schemaLocation="a.xsd">
...
</binding>
<binding schemaLocation="b.xsd">
...
</binding>
</binding>
> Now regarding the -p commandline option: That one totaly "disables" the
> automatic package-generation-from-namespaces which doesn't work either
> as I then get many collisions because classes are named the same in
> various namespaces.
Right. This isn't very useful when you deal with multiple schemas that
span across different namespaces. This is just for those who have simple
needs.
> Thus I thought overriding the toPackageName(String s) function of a
> NameConverter would help here, however it seems that this method is
> never called??
Ah, yeah. As the javadoc of the toPackageName method say, this isn't
really designed to accept a namespace URI.
I'll change it.
> So what I'm looking for is just a way to prefix every generated
> packagename with another package string to make the inclusion into the
> project I'm working on easier (I can probably do with refactoring, but
> that just feels wrong).
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com