This thing generates javascript clients. It works with the existing
frontends. All the generation code exists already in rt/javascript. We
could, I suppose, have a different generator for the pre-existing
javascript front end, to assist people in writting JavaScript \servers/.
My brain hurts in terms of how we name these things distinctly, since
they have pretty nearly nothing to do with each other.
I know, I just saw your another mail.
But I'm still thinking the whole layout of the package, I'm thinking of
a new frontend for tools (e.g tools-js-frontend)
All the code gen related to the js, should go into the js frontend. and
the frontend can call the rt/js which you already done.
The wsdlto/core has a spec as well, which allows to load the frontend,
in verbose mode, it will print
"Loading JaxWs frontend"
Which in JS case, should load the
"Loading JS frontend"
Make sense?
Right now, if you have a service running against the trunk code, you can
push in a URL like:
http://host:port/Service?js
and get back a JavaScript client. The momentary goal is to have the
ability to do the same thing from command-line (or maven).
Right, I understand that
So, it really is like wsdl generation except that it generates a
different artifact.
It also makes sense to have a wsdl2js command, by the same logic.
Exactly, make no sense to re-invent the wheel :)
James
-----Original Message-----
From: James Mao [mailto:[EMAIL PROTECTED]
Sent: Monday, December 03, 2007 9:42 PM
To: [email protected]
Subject: Re: tools for javascript
WsdlTo actually is a framework, we have frontend plugin and
databinding plugin, we only have jaxws and jaxb for each,
The wsdl2js, I guess it's a js frontend, right?, so we can
make it as a plugin as well, and which databinding are you
using? jaxb, or aegis?
The artifacts that you are going to generate can be defined
as a Velocity template
All in all, wsdl2java will load wsdl file -> build wsdl4j
definition model -> [validation] -> [customization] -> build
service model -> validation -> cxf java model -> generators
-> artifacts, That's how it works
JavaTo is a little bit different,
We support both simple frontend and jaxws frontend, we will
try to detect the frontend from the class you provide, then
we reused the rt/core, to build the service from the java
class, then we use the Service2Wsdl builder to build the
wsdl, of course, now we not just generate the wsdl, we
generate other stuff as well, like the wrapper bean classes etc.
For the CLI, we used the code donated from IONA, which called
xsume, it use the xml file to define the arguments/options etc.
I would like to hear from you, about the plan, is it target
to cxf 2.1?
or later
I'm working on jaxws 2.1 stuff at moment, so probably will
not involve that much before 2.1, but i would like someone
can try the tools framework, That would very helpful to make
the api more flexible
Regards,
James
It is time to create wsdl2js and java2js. I confess that I
am daunted
by the task of starting this from zero. Is there any
possibilies that
the tool-experts would be willing to create some shells for me?
