Hi Dan,
I still think that Tools should be an independent module, it should
not after rt, the benefit of independence is that you can use tools
any time you want.
And ideally the tools can be split as an outside project, so when
someone want to use just tools, what they need is just include the
cxf-tools.jar and cxf-common.jar in their classpath,
there will no cxf-rt.jar or others will be needed, one thing i can
imagine is that if you want to use tools in a WebService GUI, i think
STP project already did so, is you include just two jars not a lot.
I really disagree. There is no way to make it a completely separate
module unless we have duplicate code which does wsdl/jax-ws processing
in the tools. This causes more maintenance and more bugs in the long
run, so I'm pretty -1 against that. And, as I mentioned before, this
isn't that much more code to include. We could even put together a
bundled jar if people are really concerned about too many jars. I also
don't like the current approach because the jax-ws generation isn't
associated with the jax-ws module in any way, and it seems to me thats
where the generators should be.
I think the position of the tools is correct, we should not change this
position.
The RT could/may depend on tools, but tools should not depend on RT,
that does not make any sense.
Tools will/should process jax-ws stuff, consider the customization and
naming collision.
And we already have a good start on that, we have jax-ws profile to
handle all the jax-ws stuff in the tools and your may add more profiles
if you want, it could be a plugin style design. and i think all the
profiles should/could be shared by the tools and rt, so the code
generated by the jax-ws profile can go through the jax-ws rt. just a
thought. That profile stuff may need redesign to fit the needs.
You can bundle all the jars into one jar for people just use tools, but
that also make non-sense. why i need to download all the jars, when i
just need three of them?
So overall, my point is that tools should not depends on RT, that does
not make any sense.
I'm not going to
About ServiceModel, I think it should also be an independent module,
and for tools or rt, i think it'll be great if we have an plug-able
api, so the tools and rt are not directly reference ServiceModel, and
if you want to replace the ServiceModel with other Model(Wooden) will
be possible.
For the builder which build servicemodel should stay in servicemodel,
just like Wsdl4j, they provider a model and also provide a builder.
That misses the whole point of the service model. The point of the
service model is that wsdl 1.1, wsdl 2, and classes all get converted
into the service model and then artifacts are generated from that.
- Dan
No, You missed my point, my point is that the ServiceModel should/could
also be an independent module, we should have a decoupled design in our
mind,
Currently it's tightly coupled with rt, which i don't think it's a good
design. To support wsdl1.1, wsdl2, classes all get converted into the
ServiceModel , doesn't mean it have to stay in RT, if there are some
dependence, we could/should also move that part out of rt.
Ideally you have builder api like that:
ServiceModel build(URL url) // Use default profile JAX-WS
ServiceModel build(Class cls)
ServiceModel build(Definition def) // wsdl 1.1
ServiceModel build(Definition??? def) // wsdl 1.2
ServiceModel build(URL url, Profile profile)
...
The whole module could be shared by both the Tools and RT
So overall, my point is we could split the ServiceModel from RT.
Then, we have ServiceModel and Tools above the TestUtils/API/RT/..., i
think all the problems solved.
Cheers,
James.
