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:[EMAIL PROTECTED] > Sent: Tuesday, December 04, 2007 9:17 PM > To: [email protected] > 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:[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 . > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >> > > > > > > > >
