users@jaxb.java.net

Re: Importing single .xsd file from JAR project with multiple .xsds

From: Aleksei Valikov <valikov_at_gmx.net>
Date: Tue, 15 Jul 2008 21:56:51 +0200

Hi.

On Tue, Jul 15, 2008 at 8:19 PM, Patrick Gallagher
<patrick.gallagher_at_cerner.com> wrote:
>
> Hi lexi,
>
> When you say "write your own" do you mean writer my own episode file. This
> could be done but what would I change in the episode file? I reviewed
> http://java.sun.com/xml/ns/jaxb but didn't see a way to describe my
> situation to parser.

Just leave out the whole

<bindings scd="x-schema::tns" xmlns:tns="http://www.xxx.org/B/object" >
...
</bindings>

section.

I suppose you understand that episode files are nothing but bindings
which are discovered automagically from JARs. When you configure
episodes you just let xjc (via maven-jaxb2-plugin) know that it should
look in such and such jars for episode files.

So instead of configuring and episode you can just provide the same
definitions in your binding.xjb in src/main/resources. If you include
there a section like:

<bindings scd="x-schema::tns" xmlns:tns="http://www.xxx.org/A/object">
   <schemaBindings map="false">
     <package name="org.xxx.a.object" />
   </schemaBindings>
   <bindings scd="~tns:a_target">
     <class ref="org.xxx.a.object.ATarget"/>
   </bindings>
   <bindings scd="~tns:a">
     <class ref="org.xxx.a.object.A"/>
   </bindings>
 </bindings>

you tell XJC that (1) no classes should be generated for the namespace
http://www.xxx.org/A/object (2) type "a" maps to the class
org.xxx.a.object.A and so on.

The problem that you have right now is that you configure an episode
artifact which automagically imports bindings from the episode
resource - for both http://www.xxx.org/A/object and
http://www.xxx.org/B/object namespaces. And since there is now schema
for http://www.xxx.org/B/object in the set of schemas you compile, XJC
complains about incorrect bindings. I'd say XJC is a bit too strict
here since - I think that if schema for the scd-bound namespace is not
provided then these bindings should be ignored (with a warning, not an
error) but we've got what we've got.

ps. A further (and rather hardcore) option is to leave episodes out,
generate classes for your schemas and then just delete packages you
don't need in this artifact. if you don't rename classes and
properties, this should work fine. Episodes are of corse more elegant,
but they fail sometimes (as we see).

Bye.
/lexi