Hi Jervis,
Sorry I didn't get feedback earlier - but this sounds good. I'm with Dan
K on his suggestion about Step 1/rt renaming though.
I will definitely try to chip in as I'm the instigator here. I have
things to finish up for M1 before I can start working on this, but I
think I could help by doing
1. Getting XMLBeans databinding working
2. Doing the WSDL 2.0 work
Can you explain what you were referring to about the Transport work? Are
there any other areas you want me to tackle?
- Dan
Liu, Jervis wrote:
Hi, can I presume there is no objection to this proposal? ;-) Obviously this is
a big story, to move things forward, I would like to suggest we start from
tools refactoring and anything needed for tools refactoring, such as jax-ws
frontend and serviceModel etc. To minimize the risk of breaking mainline and
to allow others working on non-tools refactoring work in parallel(such as
moving databinding, transport etc from core to rt), we will take an incremental
step by step approach, at the end of each step, we need to make sure all
changes are committed to mainline and everything should build and run ok.
Below are action items we need to take related to tools refactoring, jax-ws and
serviceModel.
Step 1:
1. Rename rt to core.
2. Create a new directory and module called "rt" (or plugins). Move jax-ws from core to rt.
Cost: 1-2days
Step 2:
1. Move tools module and testutils module after core, before rt. So the dependency path will look like:
Common <- API <- Core <- Tools <- testuitls <- rt(only contains jax-ws at this moment) <- Systests
2. Move any jax-ws related code from tools module to jax-ws module. Tools load jax-ws capabilities as plugins.
3. non-jaxws module should not contain any jax-ws related code. Currently we
use jax-ws generated artifacts in a lot of places for testing. This needs to be
fixed.
Cost: about 1 week. I expect we will have to spend a lot of time on removing
jax-ws generated artifacts from non-jaxws modules.
In order to not break mainline for a week, I suggest we create a tools2 to hold
the work of step2. Once everything is working all tests passed using tools2, we
can replace tools with tools2.
Step 3:
1. Refactor tools to use ServiceModel. ServiceModel lives in core, it provides
a generic model to represent information from wsdl and classes. jax-ws specific
info is loaded into serviceModel by JaxwsServiceModelBuilder through plugins.
JaxwsServiceModelBuilder lives in jax-ws module.
2. Add soap1.2, wsdl20 supports into tools by leveraging ServiceModel.
Cost: about 1 week
Overall we expect we can finish tasks listed above in about 2 to 3 weeks. Both
James and myself are interested in working on this. As guys in Beijing are
taking 7 days off from 1st Oct to 7th Oct to celebrate National holidays, we
can probably kick off from the second week Oct. As I personally take 2 weeks
off from 1st Oct, I will join James from the third week Oct. If things going
well, we can finish this by the end of October. Note, we do not plan this work
for the coming cxf release.
Of course, we also need more volunteers to own non-tooling part refactorings,
such as transport, databindings etc.
Does this sound good to everyone?
Thanks,
Jervis
-----Original Message-----
From: Liu, Jervis
Sent: Thursday, September 28, 2006 2:37 PM
To: [email protected]
Subject: Proposal to refactor CXF dependencies. WAS: RE: Tooling
Proposal [was Re: tooling and service model]
Hi, we have come out with some new ideas (hopefully better
ideas ;-)) on how to resolve dependency problems we have been
trying to resolve in this email thread. Below is a summary
from IRC chat and email discussions:
1. Promote core to top level. Remove these "extra
functionalities" from core, the core remain as small as
possible and only provide basic and absolute necessary
functionalities. Anything considered as "extra" are moved to
rt module (or rename it to plugins). The core acquires those
"extra functionalities" through loader plugin. The new
dependency path will be: Common <- API <- Core <- Tools <-
RT(frontend, databindings etc) <- Systests
2. Candidates that will be moved from core to rt include:
a). Frontend: jax-ws, js
b). Databindings: jaxb
c). Transports: HTTP, JMS
d). Protocol bindings: SOAP, XML
d). anything else?
3. ServiceModel lives in core, though this serviceModel only
provides basic model info. Extra things like jax-ws info is
loaded into serviceModel during runtime through plugin loaders.
4. "tools" module provides a basic "tojava" tool and a basic
"towsdl" tool that just takes a ServiceModel and does not do
specific things. The other things (frontends, etc..) would
provide a plugin that would add a "-jaxws" or "-pojo" or
"-wsdl11" or "-wsdl20" command line switches (or similar) to
those tools to enable processing those things.
5. tools module is after core. The good thing is, first we
wont have any problems to make tools depend on serviceModel
anymore, as the serviceModel is in the core. Secondly and
most importantly, tools can use a "Bus.init()" to have a bus
load all the available plugins etc. This way we reuse the
plugin configurations from bus, it is the Bus's
responbilities to search classpath etc to load plugins.
How does this sound to everyone? We need to figure out an
exact list on what remains in core and what get moved to rt.
Cheers,
Jervis
--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com
