Hi all,
I missed one thing, i'm think of changing the artifact id of the wsdl2java
Previous in tools we mainly have:
tools/common
tools/wsdl2java
tools/java2wsdl
tools/misc
In the misc we have wsdl2service/wsdl2soap etc.
So i'm thinking of the following layout in tools2
tools/common
tools/wsdlto
tools/javato
The idea is to combine the wsdl2java and the misc, there're some
duplicate code in those two modules. and i think the new layout make
more sense.
Since the YOKO project depends on tools/common only , so there'll have
no impact, but the STP project may need to change the dependency of the
cxf in their POM. from cxf-tools-wsdl2java to cxf-tools-wsdlto
The API will remain, no changes.
Any comments or objections?
Cheers,
James.
Hi Edell, I just had a quick look into Yoko's code base, as far as I can see,
Yoko tool model only depends on cxf-api, cxf-common-utilities and
cxf-tools-common. cxf-tools-common is a framework mainly for command line
parser, tool spec etc. I do not think we have any plan to touch this piece of
code as part of tools refactoring. So nothing to worry.
Cheers,
Jervis
-----Original Message-----
From: Nolan, Edell [mailto:[EMAIL PROTECTED]
Sent: Friday, December 08, 2006 12:20 AM
To: [email protected]
Subject: RE: Tooling refactoring plan
Hi,
Will you be putting up a design plan for these changes as if
we need to refactor or change things in Yoko then we need to
plan these tasks/changes into our milestones and it would be
good to know in advance.
Thanks, Edell.
-----Original Message-----
From: James Mao [mailto:[EMAIL PROTECTED]
Sent: 07 December 2006 12:21
To: [email protected]
Subject: Re: Tooling refactoring plan
Hi Edell，
Yes，i know, the STP project also depends on cxf tools, so
actually the API will not change a lot, by default the API
will keep the same.
But we do allow you to pass in the front end profile or
databinding profile to generate the code other than jaxws and
jaxb And all the refactoring will be stay in tools2, the
tools will be kept until we think it's time to migrate.
Cheers,
James.
Hi,
Yoko tools depends very much on the cxf tools and any api
changes will have a big impact so if you intend changing any
- can you send an email to let us know.
Thanks, Edell.
-----Original Message-----
From: Jim Ma [mailto:[EMAIL PROTECTED]
Sent: 07 December 2006 10:25
To: [email protected]
Subject: RE: Tooling refactoring plan
Comments in line.
-----Original Message-----
From: James Mao [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 07, 2006 5:38 PM
To: [email protected]
Subject: Tooling refactoring plan
The goals of the refactoring are:
1. Reuse the service model
2. Support multiple databinding plugins（jaxb, xmlbeans etc.) 3.
Support multiple frontend plugins (jaxws frontend, simple frontend
etc.)
Add one goal :
Make our tools more plugable and extensible. Support
pluggable generator to generate deployment descriptor
,configuration etc .
Support code modification plugin which can modify the
generated code like JAXB plugin can do.
>
and we plan to
1. Copy Tools to Tools2, which will depend on RT temporarily.
the Tools2 will be a framework, it works as a CLI,
and it'll load the service builder plugin, frontend plugins and
databinding plugins according to the input.
and works as a main controller.
2. After all the test passed, then we start move the
RT/Core to top
level Core, after that the dependency of Tools2 looks like
API <- Core <- Tools2 <- TestUtils <- RT
3. Move the JaxWs specific processors and generators from
Tools2 to
rt/frontend/jaxws
Move the Jaxb specific code from the Tools2 to
rt/databiding/jaxb
Comments:
The benefit of moving is it will keep the tools
framework clean,
but it make packaging harder, and the tools in RT, seems weird.
It's weird . I think it should be place to tools . Runtime
only includes the stuff used in runtime .
4. Migrating to the Tools2, check the testutils works
fine, RT tests
pass, System tests pass etc.
Remove Tools
Rename Tools2 as Tools
Comments or Objections?
Cheers,
James.
