Liu, Jervis wrote:
Hi Dan K, I am completely on your side too. :-) I believe we can all agree with
followings:
1. The tools module is the framework and should not bind into specific data
bindings and frontends in its core. Data bindings and frondends specific
generators are loaded in the runtime as plugins. Tools module does not need to
depend on databinding and frontend during building. This feature is already in
tools, see DataBindingGenerator.java and FrontEndGeneratorsProfile.java.
2. The plugins for the tools that actually do the generation work should live
in the appropriate place. JAXB code goes in the JAXB databinding. JAX-WS stuff
goes into the JAX-WS frontend.
3. We do need to fix those non-jaxws modules that use any JAX-WS specific
generated codes.
However, this does not answer two questions below:
1. How to use JAX-WS generated code in JAX-WS froentend test if tools depend on
rt?
We should be able to do some classpath mangling to get it working. I was
able to do so with XFire and Maven using the maven ant plugin. There may
be other/better ways though.
2. Can we refactor tools to use serviceModel while still keeping tools module as a top level module? I still believe it does NOT make sense to make tools depend on the whole cxf core just because it needs serviceModel.
I don't think so. Even if you could, its not worthwhile because you'll
need core because the JAX-WS module will depend on it.
Can we do sth to serviceModul similiar as what we have done in tools? I.e.,
make serviceModel itself a generic model so that anything using serviceModel
does not need to depend on specific databindings and frontend during build
time. In the run time, serviceModel acquires specific binding/frontend
capabilities through plugin loader. For example, a JaxwsServiceModelBuilder
that can decorate serviceModel using info from Jax-ws annotations can be loaded
by serviceModel in the runtime. JaxwsServiceModelBuilder should live in Jax-ws
frontend.
I'm confused, the servicemodel already doesn't depend on a sepcific
databinding. So I'm not sure what it is that you're suggesting...
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog
