Won't that mess up the usage messages?
> -----Original Message----- > From: James Mao [mailto:[EMAIL PROTECTED] > Sent: Monday, December 03, 2007 10:31 PM > To: [email protected] > 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:[EMAIL PROTECTED] > >> Sent: Monday, December 03, 2007 10:07 PM > >> To: [email protected] > >> 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 . > >> > >> > >> > > > > > > > >
