Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of james.mao@iona.com designates
 12.170.54.180 as permitted sender)
Message-ID: <475609FE.1090604@iona.com>
Date: Wed, 05 Dec 2007 10:16:30 +0800
From: James Mao <james.mao@iona.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: cxf-dev@incubator.apache.org
Subject: Re: tools for javascript
References: <E95FD77F0171D14DA1EEE0A785E92B43024D6F45@mail3.basistech.net>
 <4754B67E.30306@iona.com>
 <E95FD77F0171D14DA1EEE0A785E92B43024D6FD7@mail3.basistech.net>
 <4754C45F.4040905@iona.com>
 <E95FD77F0171D14DA1EEE0A785E92B43024D6FDD@mail3.basistech.net>
 <4754CA02.9020500@iona.com>
 <E95FD77F0171D14DA1EEE0A785E92B43024D6FFE@mail3.basistech.net>
In-Reply-To: <E95FD77F0171D14DA1EEE0A785E92B43024D6FFE@mail3.basistech.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I hope not, you can have your own main line and toolspec for the java2js

James

> Won't that mess up the usage messages?  
>
>   
>> -----Original Message-----
>> From: James Mao [mailto:james.mao@iona.com] 
>> Sent: Monday, December 03, 2007 10:31 PM
>> To: cxf-dev@incubator.apache.org
>> Subject: Re: tools for javascript
>>
>> Forget about the frontend, there's only one module in the 
>> tools/javato at moment, (The frontend I mentioned previously 
>> was for the tools/wsdlto)
>>
>> My suggestion here is to have scripts for the java2js, and 
>> put the js stuff inside the java2ws.
>>
>> James
>>
>>     
>>> Jim and James,
>>>
>>> I agreed with James, and now I want to agree with Jim.
>>>
>>> The problem with calling Javascript a front end is that we 
>>>       
>> then need 
>>     
>>> two front ends at the same time.
>>>
>>> To generate JS from Java, we need to specify:
>>>
>>>  ... JAXWS or Simple (and their options)  ... JAXB or Aegis 
>>>       
>> (or one of 
>>     
>>> the more exotic others) (and their
>>> options)
>>>  ... the SEI
>>>  ... the classpath
>>>
>>> Given these items, we can construct a service model. Given 
>>>       
>> a service 
>>     
>>> model, we can generate a client in JavaScript.
>>>
>>> We can't make JS a third choice from JAXWS and Simple, 
>>>       
>> because we need 
>>     
>>> to use of of them.
>>>
>>> Sadly, I'm really exhausted. I'm going to go away, and look 
>>>       
>> forward to 
>>     
>>> reading the results of your further deliberations when I 
>>>       
>> get up in the 
>>     
>>> morning.
>>>
>>> Hiding in the background is the existing support for Javascript 
>>> \servers/. Hypothetically, we could even have js2js. I propose to 
>>> completely ignore this issue for the moment.
>>>
>>>
>>> --benson
>>>
>>>
>>>
>>>   
>>>       
>>>> -----Original Message-----
>>>> From: Jim Ma [mailto:ema@iona.com]
>>>> Sent: Monday, December 03, 2007 10:07 PM
>>>> To: cxf-dev@incubator.apache.org
>>>> Subject: Re: tools for javascript
>>>>
>>>>
>>>>  Benson Margulies wrote:
>>>>     
>>>>         
>>>>> Here is the XML for the java2js command.
>>>>>
>>>>> The basic idea is this: the code has to process a service. 
>>>>>       
>>>>>           
>>>> That means
>>>>     
>>>>         
>>>>> it needs an SEI, a front-end, and a data binding, just like
>>>>>       
>>>>>           
>>>> java2ws. 
>>>>     
>>>>         
>>>>> This is going to require some refactoring of code into 
>>>>>           
>> some common 
>>     
>>>>> place from java2ws. It can't be tools-common, without producing a 
>>>>> circular build-path problem. The whole idea of the
>>>>>       
>>>>>           
>>>> implementation of
>>>>     
>>>>         
>>>>> rt/javascript is that this tool is very nearly identical to
>>>>>       
>>>>>           
>>>> java2ws. 
>>>>     
>>>>         
>>>>> We want to cause the very same kind of ServiceInfo model to
>>>>>       
>>>>>           
>>>> get built,
>>>>     
>>>>         
>>>>> but then run a Javascript generator instead of a WSDL generator.
>>>>>   
>>>>>       
>>>>>           
>>>> Agreed !
>>>> I can split java2ws  into two modules : java2common and 
>>>>         
>> java2ws  then 
>>     
>>>> you can reuse the java2common to build this new tool .
>>>>
>>>>
>>>>     
>>>>         
>>>   
>>>       
>>     
>
>
>