cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Mao <james....@iona.com>
Subject Re: tools for javascript
Date Thu, 06 Dec 2007 11:46:14 GMT
Hi Benson,

I saw what you did, I'm OK with it.

But since you said it maybe mess up the usage messages, so I think 
java2js better has it's own scripts(.bat|.sh) and it's own toolspec.

I'm not sure how much options/arguements you want, if you can give me a 
list, I think I can do it for you.
Won't change a lot.

Regards,
James

> Gentlemen,
>
> Following what I thought was your advice, I added two options to the
> existing java2ws xml toolspec. Please advise as to how to fork off the
> main and the toolspec without getting buried in a giant refactoring.
>
> --benson
>  
>
>   
>> -----Original Message-----
>> From: James Mao [mailto:james.mao@iona.com] 
>> Sent: Tuesday, December 04, 2007 9:17 PM
>> To: cxf-dev@incubator.apache.org
>> Subject: Re: tools for javascript
>>
>> 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 .
>>>>>>
>>>>>>
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>   
>>>>>       
>>>>>           
>>>>     
>>>>         
>>>   
>>>       
>>     
>
>
>   


Mime
View raw message