On 3/11/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Jean-Sebastien Delfino wrote: > > Yang ZHONG wrote: >> WSDL has schemas and portTypes. >> WSDL2Java uses SDO CodeGen to compute classes names for schemas and >> generates classes for portTypes. >> SDO code seem not actually generated. >> Is that desired? >> >> If not, I can look into how to fix. >> >> If yes, are users supposed to use SDO CodeGen themselves? >> If so, what if users specify options causing different code from what >> WSDL2Java expects? >> How do we enable users to reflect the customization to WSDL2Java? >> > > Yang, > > If I remember correctly, the current WSDL2Java tool does not > automatically run XSD2Java for all the inline XSDs or all the XSDs > referenced from the WSDL. Application developers are responsible to > run the WSDL2Java tool or XSD2Java tool on each individual WSDL or XSD > file. > > On one hand, it would be nice to support a top-down generation from a > WSDL including the closure of all the referenced XSDs. On the other > hand if multiple WSDLs reference common XSDs you probably don't want > to regenerate code for these XSDs multiple times. Also if an > application developer starts to work on an XSD he'll probably want to > generate SDOs from it even before writing a WSDL, then later when he > generates a Java interface from that WSDL, the interface will have to > point to these SDOs... As you noted things will break if incompatible > codegen options are used in XSD2Java and WSDL2Java. > > These issues are actually not specific to WSDL, you can run into > similar issues with a graph of XSDs... > > We should start a discussion to find the best strategy for this codegen: > a) Handle generation on an SCA contribution basis (basically you don't > gen from individual files but you handle in a single pass ALL relevant > files in the contribution, with consistent codegen options and > avoiding duplicate gen). > b) Or continue with the current approach where the app developer > specifies which files to gen from (including support for "*.wsdl" or > "*.xsd"). > c) Or add support for top-down generation of a closure from a WSDL or > an XSD. > d) Or any other scheme... > > My preference would be for keeping option (b) and build option (a) on > top of it, but I think it'll help to look at how existing similar > tools are handling this: > How does the current XSD2Java tool handle this? What does it do when > you give it an a.xsd containing an <import/> of another b.xsd? Does it > generate code only for a.xsd? or for both a.xsd and b.xsd? > What about the JAXWS tools? > > Thoughts? > One more thought, for option (a) we should be able to reuse the SCA Contribution service to find all the WSDLs and XSDs used in an SCA contribution (as well as the namespaces imported from other SCA contributions) to automate the calls to the WSDL2Java and XSD2Java codegen and generate everything the SCA contribution needs. -- Jean-Sebastien --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi, a couple of questions/comments
I'm for option a) if we can make it work. It would be good to have some event call out though so that just before parsing an XSD you get the chance to do some configuration, e.g. in the databinding test work the same schema is used for SDO and JAXB tests but their generators will both generate to the same location (package) if we let them. What happens today in the case of reading a remote WSDL. Is it the developer's responsibility to download WSDL and associated XSDs and to build the contribution and hence gen code from them? From your comments this would seem to be the case. This sounds like it's harder than it should be. Would be good if the generator tools were able to provide to the developer the interfaces described by the contribution/SCDL . Does this tie up with your option c)? Regards Simon
