Not sure how you are handling multiple schemas which is a separate issue. We also have multiple schemas and we generate separate packages for each schema. We also have a separate binding file for each schema/package.
If you don't generate separate packages, I assume you run the generator once for each schema? We simply use a naming convention - based on the name of the schema we look for a corresponding binding file. On windows we write a simple batch file where we pass in the schema name as a parameter and use that to pick up the appropriate binding file. And yes, creating the binding file once is hand done. Someone must determine where the duplicates are and resolve them in a binding file. I haven't tried it, but you may be able to put it all in one binding file assuming that you can uniquely describe the path to the duplicate class/element name. If not, well, separate files should work as well. The idea, hopefully, is you do this once. Then the script can be rerun when needed to recreate the code. Of course, if a schema is changed in the future to add more duplicate element names you'll have to edit your binding file(s) Hope this is helpful. -----Original Message----- From: Juan Wu [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 05, 2005 4:02 PM To: [email protected] Subject: Re: [castor-user] How to resolve java file name confliction when use SourceGenerator to generate java files for schema with same-name elements? Hi, Paul and Lastric, Thanks for your help. I can't modify the schema itself to make the duplication of elements disappear in the schema. I think the binding file will need to be generated for each of the schema and can only deal with a specific schema instance, do I understand it correctly? For my case, I need to automatically parse any kind of schema which may or may not contain duplicated elements. And the duplicated element' names may be different from schema to schema. Also, I can't generate a different binding file for each schema since this is part of the automatic parsing process. I'm not sure how this generic problem about duplicate elements can be resolved by just ONE generic binding file? Please advice. Thank you very much again. Best Regards, Joanna ----- Original Message ----- From: "Paul Grillo" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Thursday, June 30, 2005 5:17 AM Subject: RE: [castor-user] How to resolve java file name confliction when use SourceGenerator to generate java files for schema with same-name elements? > You'll probably want to use a binding file when generating the java > source. use the -binding-file [filename] in your sourcegenerator > statement. > > > > The binding file indicates how you want to handle these and other issues. > > an example might look like the following, but I can't guarantee its > accuracy. essentially you are indicating that you want to create a class > called AccountPayableRow when you encounter the element you refer to. > > The only thing I'm not sure of is if you will need a mapping file when you > unmarshal at runtime. that is you may then have to indicate in a mapping > file the mapping from the xml data back. At any rate this or a > combination of both of these will solve your problem. We had the exact > same issue where we were not at liberty to change the XSD, and overcame it > in this way. > > > > <?xml version="1.0"?> > > <binding xmlns:cbf="http://www.castor.org/SourceGenerator/Binding"; > defaultBindingType="element"> > > <cbf:elementBinding name="/AccountPayble /row"> > > <cbf:java-class name=" AccountPaybleROW"/> > > </cbf:elementBinding> > > </binding> > > > ________________________________________ > From: Juan Wu [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 30, 2005 4:10 AM > To: [email protected] > Cc: [EMAIL PROTECTED] > Subject: [castor-user] How to resolve java file name confliction when use > SourceGenerator to generate java files for schema with same-name elements? > > Hi, > I try to use SourceGenerator to generate java files for the following > schema. It has two top level elements AccountPayble and PaymentMethods. > However, they all have a sub-element which is called the same as "row". > And, these two "row" elements contain different sub-elements. > The SourceGenerator will generate a java file for each of the elements - > however, I only get one "row `.java" file related with the 2nd element > (PaymentMethods), since it overwrites the "row.java" generated for the 1st > element (AccountPayble). > Is there a way that can let it generate two different row.java files that > won't overwrite each other in an non-interactive way (with -f option)? > Since this process doesn't run on a command window, I can't manually type > "y|n" when it asks for overwriting. > In another word, would it be possible to generate java files for the 2 > "row" elements named like "AccountPayble_row.java" and > "PaymentMethods_row.java" instead of just "row.java" when there is such > element name conflict? > I have set "org.exolab.castor.builder.javaclassmapping=type" in the > castorbuilder.properties. > Your any suggestions or answers will be highly appreciated. > Thanks a lot! > Joanna > ...... part of the schema which has elements' name conflict...... > <element maxOccurs="1" minOccurs="0" name="AccountPayble"> > <complexType> > <sequence> > <element maxOccurs="unbounded" minOccurs="0" name="row"> > <complexType> > <all> > <element maxOccurs="1" minOccurs="0" name="AccountType" type="string"/> > <element maxOccurs="1" minOccurs="0" name="AccountCode" type="string"/> > </all> > </complexType> > </element> > </sequence> > </complexType> > </element> > <element maxOccurs="1" minOccurs="0" name="PaymentMethods"> > <complexType> > <sequence> > <element maxOccurs="unbounded" minOccurs="0" name="row"> > <complexType> > <all> > <element maxOccurs="1" minOccurs="0" name="PaymentMethodCode" > type="string"/> > </all> > </complexType> > </element> > </sequence> > </complexType> > </element> > > ------------------------------------------------- > If you wish to unsubscribe from this list, please > send an empty message to the following address: > > [EMAIL PROTECTED] > ------------------------------------------------- > > > ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] ------------------------------------------------- ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -------------------------------------------------
