Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of James.Mao@iona.com designates
 65.223.216.181 as permitted sender)
Message-ID: <4579121E.2020309@iona.com>
Date: Fri, 08 Dec 2006 15:19:58 +0800
From: James Mao <james.mao@iona.com>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: cxf-dev@incubator.apache.org
Subject: Re: Tooling refactoring plan
References: <9A4696F35B459043970EE4A85A3173900667FD@amer-ems1.IONAGLOBAL.COM>
In-Reply-To: <9A4696F35B459043970EE4A85A3173900667FD@amer-ems1.IONAGLOBAL.COM>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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:Edell.Nolan@iona.com]
>> Sent: Friday, December 08, 2006 12:20 AM
>> To: cxf-dev@incubator.apache.org
>> 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:james.mao@iona.com] 
>> Sent: 07 December 2006 12:21
>> To: cxf-dev@incubator.apache.org
>> 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:jim.ma@iona.com]
>>> Sent: 07 December 2006 10:25
>>> To: cxf-dev@incubator.apache.org
>>> Subject: RE: Tooling refactoring plan
>>>
>>>
>>> Comments in line.
>>>
>>>   
>>>       
>>>> -----Original Message-----
>>>> From: James Mao [mailto:james.mao@iona.com]
>>>> Sent: Thursday, December 07, 2006 5:38 PM
>>>> To: cxf-dev@incubator.apache.org
>>>> 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.
>>>>
>>>>
>>>>   
>>>>
>>>>
>>>>
>>>>
>>>>     
>>>>         
>>>   
>>>       
>>