There will be additional attributes/elements within each of the 4 major elements - JavaToWSDL, JavaToXSD,..... I do not need feedback about those. :-)
I am interested in knowing whether you think the above block is intuitive to users, when backed with good documentation in the JBossWS Tools document??
There are really just two modes for the tool:
1: client side working from wsdl
2. server side working from java
Some of the options (i.e. targetNamespace) apply accross the fine grained tasks. The tasks java2wsdl and java2xsd should both be run for server side for example. There is also the webservices.xml artifact for the server side.
You may want to have common options for server/client side plus individual options for the fine grained tasks.
Yes, we need a schema for the config file once it is reasonably stable. The test build should have a generation step that builds the artifacts that are currently generated by wscompile.
Hope I'm not out of line here :-) We are building a fairly large SOA with JBoss where we start from WSDLs on both server and client side.. so a third mode
3. server side working from wsdl
will definetly be required for us
on a personal note, I think that generating WSDL's from java is like generating interfaces from classes (interfaces/WSDLs are abstract definitions, java-web-services/classes are implementations), which I find a bit "backwards" from a design point of view and fairly unusual in the java community (generating interfaces from classes ;-) maybe i'm wrong here.. !?
In my desription of the modes I was perhaps to restrictive. It should be possible to generate the server side artifacts from wsdl.
Generating the client side from SEI is probably indeed nonsense.
Ole, from an accademic point of view you're probably right. However, the vast majority of people start of with the SEI when providing a service endpoint.