RE: Schema generator not generating certain classes.

[Lawrence Jones]

Hi Eamonn   I feel like I’m missing something here. Your own jar contains the OrderDetails class. It is listed as OrderDocument$Order$OrderDetails.class – which is what I would expect for an inner class. You refer to it in Java as noNamespace.OrderDocument.Order.OrderDetails. I turned on the –src flag for scomp and here’s an example line from the generated Order (inner) interface:        void setOrderDetailsArray(noNamespace.OrderDocument.Order.OrderDetails[] orderDetailsArray);   You can see that the reference to the class is exactly as expected. And, as I mentioned, the class is present even in the jar you attached below.   If you wanted to generate such an object in order to call e.g. the above setter you could do something like:       import noNamespace.OrderDocument;       OrderDocument.Order.OrderDetails od = OrderDocument.Order.OrderDetails.Factory.newInstance();     od.setXXX();     …   exactly as for other elements. So I’m afraid I don’t understand the problem?   Cheers,   Lawrence   From: Eamonn Rohan [mailto:[EMAIL PROTECTED] Sent: Monday, March 13, 2006 6:42 AM To: user@xmlbeans.apache.org Subject: Re: Schema generator not generating certain classes.   Hi Lawrence, Thank you for your reply.  I have attached three schema definition files that are similar (but smaller) than those that I am using in the program, plus the jar that was generated by using scomp on Order.xsd. If you look in the jar you will see in the noNamespace directory there are all the global elements plus an OrderDocument interface containing an Order interface that has a number of methods generated for it including  getters and setters for MessageHeaderType and another set of methods for an orderDetailsArray which deal with an object called OrderDetails. It is this OrderDetails object that I am looking to find as without it I have no way to get or set any of the elements contained within the OrderDetails part of the xml message. Thanks again for your help so far. Regards, Eamonn Lawrence Jones wrote: Hi Eamonn   I tried out your schema below and it worked for me. The OrderDetails interface was generated as an inner interface on Order which was itself an inner interface of OrderDocument. Similarly for the impl classes.   I believe the rule is that global elements/types are generated as separate classes but local elements/types are defined as inner interfaces within their parent - which is why when you moved the definition of OrderDetails to a global position you saw a separate source file for it.   But either way when compiled the classes ought to be there.   If not can you post a complete example along with anything you think might be pertinent in your environment and we can go from there?   Cheers,   Lawrence     -----Original Message-----From: Eamonn Rohan [mailto:[EMAIL PROTECTED]]Sent: Thursday, March 09, 2006 3:37 AMTo: user@xmlbeans.apache.orgSubject: Schema generator not generating certain classes. Hi everyone, I'm developing an application that takes in a schema defined by a    third  party and uses XML beansto parse out the content and also to create the same messages from    data  in the app. Each xsd file defining a particular message (of which there are about17) uses an include statementto another schema containing common types and this in turn links to athird file containing dictionary definitions for eachelement (some of them end up being enumerations etc.). My problem arises when i try to compile an xsd file like this: <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" version="1.00"id="R2005.1">    <xs:include schemaLocation="CommonTypes.xsd"/>    <xs:element name="Order">        <xs:complexType>            <xs:sequence>                <xs:element name="OrderHeader"    type="MessageHeaderType"/>                  <xs:element name="OrderDetails" maxOccurs="unbounded">                    <xs:complexType>                        <xs:sequence>                            <xs:element ref="ELEMENT1"/>                            <xs:element ref="ELEMENT2"/>                            ...                            <xs:element ref="ELEMENT17"/>                            <xs:element ref="REMARKS" minOccurs="0"/>                        </xs:sequence>                    </xs:complexType>                </xs:element>            </xs:sequence>            <xs:attribute ref="version" use="required"/>        </xs:complexType>    </xs:element></xs:schema> The generator gives me a separate document for each Element in thedictionary file as I would expect it to and alsodocuments for each of the complex types defined in CommonTypes.xsd(including one for MessageHeaderType above).In my OrderDocument interface I get a nested interface for Order whichincludes methods like:addNewOrderHeader which returns a MessageHeaderType, setOrderHeaderwhich takes in a MessageHeaderType..., howeverI also get generated methods for OrderDetailsArray (addNew, set,    remove  etc.) that refer to a data typenoNamespace.OrderDocument.Order.OrderDetails which is itself notgenerated at all.  This means I get no getters or setters for any of    the  elements at all and therefore no way to add a new OrderDetails line. I have managed to get around this problem by taking the complex typecontained in the OrderDetails section and putting it's contents intothe CommonTypes.xsd file as OrderDetailsType so that the Orders.xsd    file  looks like:       ...        <xs:complexType>            <xs:sequence>                <xs:element name="OrderHeader"    type="MessageHeaderType"/>                  <xs:element name="OrderDetails"    type="OrderDetailsType"  maxOccurs="unbounded" />            </xs:sequence>            <xs:attribute ref="version" use="required"/>        </xs:complexType>       ... I was wondering if anyone could shed some light as to why this ishappening (is it something I am doing wrong or a shortcoming of theapplication?)and how I can avoid having to hack at the schemas to get them to    compile  correctly. I am looking at a situation whereby there may be several revisions ofthe schemas throughout the year and I would prefer if at all possiblenot to have to change them each and every time a new one gets    published.  Thank you in advance. Regards Eamonn  ---------------------------------------------------------------------To unsubscribe, e-mail: [EMAIL PROTECTED]For additional commands, e-mail: [EMAIL PROTECTED]     _______________________________________________________________________Notice:  This email message, together with any attachments, may containinformation  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliatedentities,  that may be confidential,  proprietary,  copyrighted  and/orlegally privileged, and is intended solely for the use of the individualor entity named in this message. If you are not the intended recipient,and have received this message in error, please immediately return thisby email and then delete it. ---------------------------------------------------------------------To unsubscribe, e-mail: [EMAIL PROTECTED]For additional commands, e-mail: [EMAIL PROTECTED]     _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.