Hi, Stevo Slavić wrote: > 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. As already said, I am open for discussions. I just tried to explain what I think has been the reasoning behing the current state of things.
> 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. Yes, and no. But if you start taking naming conflicts into account (as well), the picture starts changing immediately. > Regards, > Stevo. Werner > > 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 >> >> >> > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
