DONE,
Please review the code, and remove the redundant options from the toolspec.
If my change is OK, then we can change the java2ws back,
then we have two tools in their own package
Cheers,
James
The only option so far, other than the common inputs and outputs, is
-jsutil, a boolean.
-----Original Message-----
From: James Mao [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 06, 2007 6:46 AM
To: [email protected]
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:[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 .
