Hello Werner, My expectation was that if packaging parameter is provided to the castor-maven-plugin, then when determining package for an element/type/group/attribute/... castor would do whatever it is doing at the moment, and if package determined is still null or empty, then use one provided from packaging parameter. Currently there is no such fallback. Maybe it could be added to e.g. XMLBindingComponent's getJavaPackage() method logic, at least that's where I saw wrong prefix-less package is being applied.
This would render usage of binding.xml unneeded, in simple cases like mine, where one just wants all the classes from all the different processed XSDs/namespaces to be generated using same package configured to plugin through packaging parameter. Regards, Stevo. On Tue, Aug 25, 2009 at 11:06 PM, Werner Guttmann <[email protected]>wrote: > Hi Stevo, > > Stevo Slavić wrote: > > Hello castor users, > > > > When generating source code from multiple XSDs using castor-maven-plugin > > v1.5, one may experience random failure. Process itself will not fail, > but > > its outputs are not generated well. Problem occurs if one configures > plugin > > using packaging, schemaDirectory, without providing binding file, and > when > > generateImportedSchemas is set to false, in case of multiple XSDs being > > processed referencing each other. In this case source code generation > > success will be dependent on order the XSDs are processed. E.g. if one > xsd > > (1) references the other (2) and 1 becomes processed before 2, types > > generated from 1st XSD with attributes of type generated from 2nd XSD > might > > not compile, because attributes will not have correct package reference > > (only types.%TypeName% without packaging prefix) - likely a bug in Castor > > CodeGen module. > Not really a bug, but in my view something that needs to be driven by a > human being, as requirements seem to differ for everybody. But then > again, this is me being biased here. > > > > In my case generateImportedSchemas has to be false, since some imported > > schemas don't have to be processed, only ones from a given directory. > > Correct me if I'm wrong, but I think currently one can not influence > order > > XSDs will be processed. After checking the castor-maven-plugin source it > > seems schemas will be processed in order that is more dependent on > alignment > > of stars than anything else (java.io.File.listFiles(), java.util.Set, ... > no > > guarantees of order). Same goes for the processing success. > Yes, correct. > > > Solution was to use binding.xml file and configure XML namespace to > package > > name mapping. Then it seems, regardless of the order XSDs are processed, > > source code generator knows to resolve package for given XSD > > type/group/element/... based on its namespace and provided mapping. > Yes, that's where much what we advise users to do. If you run into > problems during code generation, use one of two options: > > a) set generateImportedSchemas to 'true', or > b) use a binding file. > > > > Maybe castor-maven-plugin could be improved, to first analyze all the > XSDs > > before they are processed, check who imports whom, and based on that > order > > the XSDs for processing, so do something similar maven reactor does at > the > > start of the build by ordering modules to be built. > Yes, definitely. That would make for some nice goals. As a first step, > one could provide a new goal that behaves similar to > castor:analyze-schema-set .... > > > > > Regards, > > Stevo. > > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
