Comments inline
Yang ZHONG wrote:
Thanks to Sebastien, Simon and Mike for the inputs.
I'll try one step at a time. First, I'll try an option to generate SDO as
well.
Then we can discuss generation from contribution/set more.
Great. Thanks Yang!
On 3/12/07, Mike Edwards <[EMAIL PROTECTED]> wrote:
Jean-Sebastien Delfino 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.
>
>
It seems to me that different usecases apply. It should be possible
just to point the tool at some remote WSDL / XSD and generate the
required Java files locally, without needing to download the WSDL and
XSDs. One of the points of convenience here is that the Java programmer
wants as little to do with the WSDL and XSDs as possible - what they are
really after are the Java interface files and the SDOs - those are what
they will work with. Ideally they DONT want the WSDL and XSDs in their
contributions.
So an option (at least) should allow the user to request that the tool
follows all links and generates all the target entities. Another option
should allow for "bulk creation" - ie a run against not just a single
file but a whole series of them - and that the tool should only gen each
target once for the whole run (ie spot when the same WSDL or XSD is
processed more than once....).
It seems reasonable to allow just a single file to be processed, but I
doubt whether that is what I would want as a default.
Yours, Mike.
+1 to Simon's and Mike's comments.
We need to be able to gen from a WSDL/XSD from wherever it is, so the
tool should allow:
- to pass just a URL to a WSDL/XSD
- to specify that you want to follow all links
- bulk generation from a set of files (I may be wrong, but I think that
our Maven plugin already supports that, I'm not sure about the non-Maven
command line tool though)
- bulk generation from the set of files (local or remote) referenced by
an SCA contribution
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
