I have a similar situation. I have an idea for how I plan to handle it, my
schedule to implement that idea is a couple of weeks away at best.
The framework I am implementing will be used by 5 different applications
being built by 5 different groups. One of the tasks of my framework is to
convert between Java and XML. Each application has its own schema and plans
to jar the generated classes in separate jars. There is however a common
subset that is enterprise-wide useful stuff hence I plan to have that in a
common.xsd (for instance). I plan to generate classes out of these and jar
them up in a commonTypes.jar. I plan to ask the 5 teams to exclude the
package com.cccis.common from their Ant jar command.
Can the experts out there verify whether I am on the right path ?
"Franklin, Brian"
<brian.franklin_at_c To: JAXB-INTEREST_at_JAVA.SUN.COM
iraden.com> cc:
Sent by: Subject: Re: Class generation and <xsd:include>
Discussion list
for the Java
Architecture for
XML Binding
<JAXB-INTEREST_at_JA
VA.SUN.COM>
05/15/2003 05:00
PM
Please respond to
Discussion list
for the Java
Architecture for
XML Binding
>>From what you are describing about your schemas, it sounds like you are
taking the correct approach.
I believe the problem lies in how you are invoking xjc. When you specify
the target package explicitly using the -p switch, it applies that package
to the schema that you specify AS WELL AS all included and imported
schemas.
Now, whether this is proper behavior is perhaps a separate question, but
nonetheless that's the current effect.
Normally, the namespace is converted automatically into a package name
using
the mapping rules described in the JAXB specification (
http://java.sun.com/xml/downloads/jaxb.html ), section C.5. So, depending
on how your namespace is arranged, you may not have to use the -p switch.
If the automatic mapping from namespace to package doesn't work for your
schemas, you can get around this with a binding customization in each
schema. The binding customization is a <schemaBindings> customization,
specifically the <package> customization.
Please see section 6.6.1.1 in the JAXB specification, or look at po.xsd in
the SampleApp6 and SampleApp7 examples that come with JAXB.
As a quick reference, the customization would look something like this:
--- C.xsd ---
<?xml version="1.0"?>
<schema xmlns="
http://www.w3.org/2001/XMLSchema"
targetNamespace="
http://www.foo.bar/some/namespace"
xmlns:this="
http://www.foo.bar/some/namespace"
xmlns:jaxb="
http://java.sun.com/xml/ns/jaxb"
jaxb:version="1.0"
elementFormDefault="qualified"
version="1.0">
<annotation>
<appinfo>
<jaxb:schemaBindings>
<jaxb:package name="bar.foo.c"/>
</jaxb:schemaBindings>
</appinfo>
</annotation>
...
</schema>
--- end C.xsd ---
Hope that helps,
Brian Franklin
-----Original Message-----
From: Pratt, Jerald [mailto:jerpratt_at_northropgrumman.com]
Sent: Thursday, May 15, 2003 5:22 PM
To: JAXB-INTEREST_at_JAVA.SUN.COM
Subject: Re: Class generation and <xsd:include>
I am trying to do something similar with similar results. In my situation,
I have 3 different namespaces (let's call them A, B, and C). C provides
common tools that are used by both A and B.
My A namespace consists of a collection of XSD files that all belong to the
same namespace with a single file defining the root element. In this root
XSD file, I have an <xs:import namespace="C" schemaLocation="C.xsd">
statement for namespace C and a collection of <xs:include> elements to
include the other XSD files w/in the same namespace.
My B namespace lives in a single XSD file so in this file I only have a
single <xs:import> line that looks just like the one mentioned above.
My problem is that I have not been able to figure out how to get these into
3 different packages w/out having to duplicate the entries found in the
common namespace C. What I've had to do is run xjc for the A namespace
where all the XSD files for A and C existed:
xjc -d src -p xxx.A A.xsd
And then again, run xjc for the B namespace where all the XSD files for B
and C existed:
xjc -d src -p xxx.B B.xsd
But this produces duplicate classes for the C namespace items existing in
both the xxx.A and xxx.B package.
Is there anyway to create a common xxx.C package that both xxx.A and xxx.B
can reference so that I don't have to have common classes w/in both of
these
packages???
Jerald Pratt
-----Original Message-----
From: Franklin, Brian [mailto:brian.franklin_at_ciraden.com]
Sent: Tuesday, April 22, 2003 1:25 PM
To: JAXB-INTEREST_at_JAVA.SUN.COM
Subject: Re: Class generation and <xsd:include>
If I understand your intent correctly, then I know that it can be
accomplished fairly easily. What you probably need to do is define a
targetNamespace in your common.xsd file. I know that's a quick answer, but
if you'd like I can post an example.
Brian Franklin
-----Original Message-----
From: Doug Holmes [mailto:dholme_at_ACXIOM.COM]
Sent: Tuesday, April 22, 2003 3:38 PM
To: JAXB-INTEREST_at_JAVA.SUN.COM
Subject: Re: Class generation and <xsd:include>
We've been using JAXB 1.0 and are pretty happy with it. I have one
question
about how imported schemas are generated, because we would like to share
some common elements across many schemas.
Since each schema that includes these common elements creates JAXB objects
for them in a different package, I can't have common code to pack/unpack
the
common elements.
The only solution I can think of is to put the same interface on the
various
versions of the same object in the different packages, but JAXB 1.0 seems
to
preclude adding specific interfaces to specific generated objects.
Just so I understand what my tradeoffs are, I was wondering what the "good
reason" (see below) is that these common schema definitions are duplicated?
On Tue, 21 Jan 2003 13:30:38 -0800, Kohsuke Kawaguchi
<Kohsuke.Kawaguchi_at_Sun.COM> wrote:
>The package is per-namespace basis. IOW, if two components are in the
>same namespace (regardless of the source .XSD file it is defined), they
>will end up in the same package.
>
>It's not clear to me whether your child schemas are all belong to a
>difference target namespace URI or the same namespace URI.
>
>If they are different, you end up receiving duplicates of
>common_types.xsd in every package (for a good reason, BTW),
>
>If they are the same, all the components from all your children schemas
will
>be generated into the same package.
>
>
>regards,
>--
>Kohsuke KAWAGUCHI 408-276-7063 (x17063)
>Sun Microsystems kohsuke.kawaguchi_at_sun.com