cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benson Margulies" <bim2...@basistech.com>
Subject RE: tools for javascript
Date Thu, 06 Dec 2007 13:09:30 GMT
The only option so far, other than the common inputs and outputs, is
-jsutil, a boolean.  

> -----Original Message-----
> From: James Mao [mailto:james.mao@iona.com] 
> Sent: Thursday, December 06, 2007 6:46 AM
> To: cxf-dev@incubator.apache.org
> Subject: Re: tools for javascript
> 
> 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