Hi James, On 12/20/06, James Mao <[EMAIL PROTECTED]> wrote:
Hi Dan, From What I can see now, what we really need is just the extension schema and the extensions.xml (also the generated code from the schema for wsdl11 extensibility elements), nothing else. tools2 depends on whole soap & xml and jms transport will work, but i don't think it's a better solution. Previously tools has it's own serializer/deserializer which registered into the ExtensionRegistry, the idea basically is reuse the registration we already have in WSDLManagerImpl. The problems of tools2 depends on soap, xml, jms are: * if we have another binding or transport, we have to modify the tools dependency
Not true. The tools should reuse the discovery mechanism inside CXF, so if there is a new binding added tools should be able to pick it up as well. * if we want to package just tools, we have to package whole bindings
and transports from which we only use schema and extensions.xml
So what? It seems fitting to me that we have to depend on cxf-jms to get JMS support with our WSDL, so I don't see a problem here. The problems of moving schemas and extensions.xml into top level meta
module is: * separate the wsdl extensions of bindings and transport into a different module, if there is new binding or transport the schema has to defined in the meta module.
-1 Another solution i have is the schema and extension still stay in
bindings and transports module, but we split the module into two submodule. One is core sub module another is meta module which only include the wsdl11 extension schema (later wsdl20 extension schema) and extensions.xml. Take the xml module as example, we split the xml binding module into xml-core submodule and xml-meta submodule, and move the schema and extensions.xml into xml-meta submodule
The benefit of this approach is that all the binding/transport specific
stuff still stay in there own module, and the tools can depends on binding-meta submodule not the whole binding module. The problem of this approach is that we introduce more modules, means there are more jars introduced.
-1 - too much complexity. So there are actually three solutions, they both have pros and cons. i
myself prefer the last one.
I much prefer just relying on the soap/xml/http/jms modules at runtime during generation. - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
