Dmitri Colebatch wrote:
> Hi all,
>
> I thought this was possible, but I'm beginning to wonder if I'm
> thinking of something else.
>
> I have a schema that refers to some types that SAP uses.
> Unfortunately there's no nice way (that I know of) to get these types
> out of SAP in a general form. The relevant parts of my schema are:
>
> <xsd:schema targetNamespace="http://webservices.toyota.com.au/schema/s3/2004/12/14/common.xsd"
> xmlns:sap="urn:sap-com:document:sap:rfc:functions"
> xmlns:s0="http://webservices.toyota.com.au/schema/s3/2004/12/14/common.xsd"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
> xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc"
> jaxb:extensionBindingPrefixes="xjc"
> jaxb:version="2.0"
> elementFormDefault="qualified" attributeFormDefault="unqualified">
>
> ...
>
> <xsd:element name="SAPReturn">
> <xsd:complexType>
> <xsd:sequence>
> <xsd:element name="item" type="sap:BAPIRET2" minOccurs="0"
> maxOccurs="unbounded"/>
> </xsd:sequence>
> </xsd:complexType>
> </xsd:element>
>
>
> I have previously compiled the BAPIRET2 type, and have put that on the
> classpath. I'm running xjc using:
>
> xjc -classpath e:\dev\tmp\common-helper\jaxb-classes -d jaxb
> e:\dev\tmp\tJunction\schema\s3\2004\12\14\common.xsd
>
> and I get this error:
>
> parsing a schema...
> [ERROR] src-resolve: Cannot resolve the name 'sap:BAPIRET2' to a(n)
> 'type definition' component.
> line 101 of file:/E:/dev/tmp/tJunction/schema/s3/2004/12/14/common.xsd
>
> Failed to parse a schema.
>
> This makes a fair bit of sense, but I thought I could avoid this by
> putting and existing class that already represented that type on the
> classpath. Obviously (unless I'm missing something) this isn't the
> case.
In 2.1, we can do a separate compilation like that. See
http://weblogs.java.net/blog/kohsuke/archive/2006/09/separate_compil.html
But even when you do that, XJC still needs to see the whole schemas.
> So - is this possible (and if so how)? Given that I can't find the
> above strings in the jaxb source I'm assuming these are coming
> directly from the parser.
Yes, this error is from the JAXP RI.
> Alternatively, does anyone have any advice on how to handle the
> situation where you want to refer to types that don't exist in
> statically available schemas. The way I get these types out of SAP
> atm is to get the WSDL (available for each BAPI) and pull the schema
> out of that before running xjc over it. I have to do these one at a
> time because they contain duplicate copies of the same types (as you'd
> expect).
>
> What I'd like my build process to be is I firstly create a jar that
> contains all the compiled SAP schemas, and then I give that to xjc
> when compiling. My current approach (which has been causing trouble)
> is to have a hand built schema "sap.xsd" that references to types we
> need from SAP. Of course the problem with this is that it gets out of
> date a little too easily.
Read my blog entry, try the 2.1 EA bit, and let us know if it works for
you. The proposed feature is exactly for this kind of situations, and
the reason we have EAs out there is so that you can try out and tell us
if it works or sucks.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com