Arnaud, It looks like I'd consider your options 1 or 2, but not option 3, since I don't know that there won't be conflicting schema names in different directories in my schema hierarchy.
One thing I need to know is this -- Is the <schemaLocation> listed in the bindings file to be the same as it is in the actual schema include? That is, if my schemas all do includes like <xsd:include schemaLocation = "../../foo/bar/baz.xsd"/> will I then need to use option 2? Or can I use option 1 as well, since I'll know at the time I run the SourceGenerator what all the absolute paths of the schemas are? Assuming I can use either option: For option 1: Since all of my schemas use relative paths, will the locations generated for the schemas by Castor take into account that the include paths are relative to the including schemas and not to the current directory? For option 2: I'm not sure this would work for me, since it looks like Castor will calculate the schema paths relative only to the current directory, and not to the including schemas. Please clarify these things for me at your convenience. Thanks, Lisa Arnaud Blandin wrote: > > Hi Erik and Lisa, > > I've slightly modified the behavior of the <package> element and I hope > it will fit your needs. > The <package> element allows you to define a mapping between a package > name and a schemaLocation. The schema location is a URI that identifies > your XML Schema. > You have several options: > > 1- using the absolute URI: > <package> > <name>foo.bar</name> > <schemaLocation>file:///home/schemas/myschema.xsd</schemaLocation> > </package> > When processing the schema myschema.xsd, Castor will create a location > for it and the SourceGenerator will simply check that this location > matches the one specified in the binding file. > > 2- using a relative URI > <package> > <name>foo.bar</name> > <schemaLocation>./myschema.xsd</schemaLocation> > </package> > > The Source Generator will compute the schemaLocation at runtime using > the user current directory (user.dir property) > > 3- use the resource name > <package> > <name>foo.bar</name> > <schemaLocation>myschema.xsd</schemaLocation> > </package> > > In that case every 'myschema.xsd' whatever the URI is will generate > sources in a foo.bar package. > > Let me know if it fits your needs, > > Arnaud > > > -----Original Message----- > > From: Ostermueller, Erik [mailto:[EMAIL PROTECTED] > > Sent: Friday, May 30, 2003 10:13 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [castor-dev] binding file -- <package> element > > > > I wrote: > > > Also, is the <package> node in any way a replacement for > > > the property org.exolab.castor.builder.nspackages? > > When you generate code, the answer is yes. > > > > > How about for the SourceGenerator -package command line > > > parameter? > > Again, when you generate code, the answer is yes, as long as you > > put the same targetNamespace in both your schema and the binding file. > > > > I have another question, though. This ns-package mapping would > > be very helpful when unmarshalling. Is there any code that inspects > > the bindingfile during unmarshalling? > > > > I want it to detect a ns in an instance doc, locate the corresponding > > java package in the binding file and then unmarshall the data. > > > > Also, I still haven't answered my original question: > > > > The binding file html doc says the <package> element allows you "to > define the > > mapping between a schemaLocation attribute and a Java package". > > > > Does this mean that the following binding file will place > > all generated objects for Customer.xsd into the 'vo' package? > > It's not working for me. > > > > <cbf:binding xmlns:cbf="http://www.castor.org/SourceGenerator/Binding"; > > defaultBindingType='type'> > > <cbf:package> > > <cbf:name>vo</cbf:name> > > <cbf:schemaLocation>./Customer.xsd</cbf:schemaLocation> > > </cbf:package> > > </cbf:binding> > > > > > > Thanks, > > > > Erik > > > > ----------------------------------------------------------- > > If you wish to unsubscribe from this mailing, send mail to > > [EMAIL PROTECTED] with a subject of: > > unsubscribe castor-dev > > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail to > [EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
