cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <...@envoisolutions.com>
Subject Re: Tooling Proposal [was Re: tooling and service model]
Date Wed, 27 Sep 2006 14:31:49 GMT

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


Mime
View raw message