For demonstrating this problem the XML schema files alone would be
sufficient,
together with the actual (!) calls of xjc. Below are the results of
compiling your
reduced sample with 2.1.12 and 2.2.
Check the version in line 2 of the generated Java code.
It is very likely that you are not really calling xjc from 2.2 when you
think you are.
There are issues with combining 2.2 with JDK 1.6; see a recent thread. Try
using
the "endorsed" mechanism described therein.
-W
$ /extra/JAXB_2_1_12/bin/xjc.sh -verbose bar.xsd
parsing a schema...
compiling a schema...
[INFO] generating code
unknown location
com/foo/ns/Foo.java
com/foo/ns/ObjectFactory.java
com/foo/ns/package-info.java
com/foo/ns_bar/Bar.java
com/foo/ns_bar/ObjectFactory.java
com/foo/ns_bar/package-info.java
$ /extra/JAXB_2_1_12/bin/xjc.sh -version
xjc version "hudson-jaxb-ri-2.1-833"
JavaTM Architecture for XML Binding(JAXB) Reference Implementation, (build
hudson-jaxb-ri-2.1-833)
$ head -2 com/foo/ns_bar/Bar.java
//
// This file was generated by the JavaTM Architecture for XML Binding(JAXB)
Reference Implementation, vhudson-jaxb-ri-2.1-833
$ /extra/JAXB_2_2/bin/xjc.sh -verbose bar.xsd
parsing a schema...
compiling a schema...
[INFO] generating code
unknown location
com/foo/ns/Foo.java
com/foo/ns/ObjectFactory.java
com/foo/ns/package-info.java
com/foo/ns_bar/Bar.java
com/foo/ns_bar/ObjectFactory.java
com/foo/ns_bar/package-info.java
$ /extra/JAXB_2_2/bin/xjc.sh -version
xjc version "hudson-jaxb-ri-2.2-147"
JavaTM Architecture for XML Binding(JAXB) Reference Implementation, (build
hudson-jaxb-ri-2.2-147)
$ head -2 com/foo/ns_bar/Bar.java
//
// This file was generated by the JavaTM Architecture for XML Binding(JAXB)
Reference Implementation, vhudson-jaxb-ri-2.2-147
On Fri, Jan 1, 2010 at 8:47 PM, Adam Zell <zellster_at_gmail.com> wrote:
> Hello,
>
> I have a reproducible test case with JDK 1.6.0_17, but due to its inclusion
> of both JAXB versions it is rather large (~19MB). Is there someplace I can
> place it? I am guessing that <xsd:import> is tickling a recent code change.
>
> ----------
> xjc 2.1.12
> ----------
> parsing a schema...
> compiling a schema...
> [INFO] generating code
> unknown location
>
> com/foo/ns/Foo.java
> com/foo/ns/ObjectFactory.java
> com/foo/ns/package-info.java
> com/foo/ns_bar/Bar.java
> com/foo/ns_bar/ObjectFactory.java
> com/foo/ns_bar/package-info.java
> -------
> xjc 2.2
> -------
> parsing a schema...
> compiling a schema...
> [INFO] generating code
> unknown location
>
> com/foo/ns/Bar.java
> com/foo/ns/Foo.java
> com/foo/ns/ObjectFactory.java
> com/foo/ns/package-info.java
>
> Best,
>
> On Fri, Jan 1, 2010 at 1:01 AM, Wolfgang Laun <wolfgang.laun_at_gmail.com>wrote:
>
>> Hi Adam,
>>
>> please check the results as you posted them in relation to the
>> xjc version. Your post would indicate that the newest xjc drops
>> the URI fragment part entirely, as opposed to 2.1.12.
>>
>> There is indeed a difference between 2.2 and earlier versions,
>> but I find that 2.2 does the right thing, i.e., according to the
>> JAXB specification, section D.5.
>>
>> -W
>>
>>
>> On Tue, Dec 29, 2009 at 6:23 PM, Adam Zell <zellster_at_gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I have two basic schema files. The second schema file imports the first,
>>> and uses the hash character in its target namespace.
>>>
>>> foo.xsd:
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <xs:schema elementFormDefault="qualified"
>>> attributeFormDefault="unqualified" targetNamespace="
>>> http://www.foo.com/ns" xmlns:xs="http://www.w3.org/2001/XMLSchema"
>>> xmlns:foo="http://www.foo.com/ns">
>>> <xs:element name="Foo">
>>> <xs:complexType>
>>> <xs:sequence>
>>> <xs:element name="foo" type="xs:string"/>
>>> </xs:sequence>
>>> </xs:complexType>
>>> </xs:element>
>>> </xs:schema>
>>>
>>> bar.xsd:
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <xs:schema elementFormDefault="qualified"
>>> attributeFormDefault="unqualified" targetNamespace="
>>> http://www.foo.com/ns#bar" xmlns:xs="http://www.w3.org/2001/XMLSchema"
>>> xmlns:bar="http://www.foo.com/ns#bar">
>>> <xs:import namespace="http://www.foo.com/ns"
>>> schemaLocation="foo.xsd"/>
>>> <xs:element name="Bar">
>>> <xs:complexType>
>>> <xs:sequence>
>>> <xs:element name="bar" type="xs:string"/>
>>> </xs:sequence>
>>> </xs:complexType>
>>> </xs:element>
>>> </xs:schema>
>>>
>>> xjc 2.1.12 reports the following:
>>>
>>> $ ./jaxb-ri-20090708/bin/xjc.bat -d build/classes -verbose *.xsd
>>> parsing a schema...
>>> compiling a schema...
>>> [INFO] generating code
>>> unknown location
>>>
>>> com\foo\ns\Foo.java
>>> com\foo\ns\ObjectFactory.java
>>> com\foo\ns\package-info.java
>>> com\foo\ns_bar\Bar.java
>>> com\foo\ns_bar\ObjectFactory.java
>>> com\foo\ns_bar\package-info.java
>>>
>>> xjc 2.2 however reports:
>>>
>>> $ ./jaxb-ri-20091104/bin/xjc.bat -d build/classes -verbose *.xsd
>>> parsing a schema...
>>> compiling a schema...
>>> [INFO] generating code
>>> unknown location
>>>
>>> com\foo\ns\Bar.java
>>> com\foo\ns\Foo.java
>>> com\foo\ns\ObjectFactory.java
>>> com\foo\ns\package-info.java
>>>
>>> Is the difference in xjc behavior due to the hash character in bar's
>>> target namespace?
>>>
>>> Thanks!
>>>
>>> --
>>> Adam
>>> zellster_at_gmail.com
>>>
>>
>>
>
>
> --
> Adam
> zellster_at_gmail.com
>