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 Tue, 04 Dec 2007 13:09:15 GMT
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