Hi Dan, one more question, I am not sure how its going to work if
tools
depened on core. Based on our current dependency path, tools <- API <-
rt, if we make tools depending on rt, isnt it a circular dependency?
-----Original Message-----
From: Liu, Jervis
Sent: Sat 9/23/2006 3:57 PM
To: [email protected]
Cc:
Subject: RE: Tooling Proposal [was Re: tooling and service model]
Hi Dan, The plan looks good to me. I had a chat with Jim, we
estimate the
item 1 to 5 should be no more than a week's work (or sth around
that). In
a previous thread, James and Jim already mentioned that they are
interested in working on this, I may also want to pick up some
taskes in
the area once I get the JAW-WS handler stories done. Regarding item 6,
the replacement of code model, the work itself should be
straightforward,
just a lot of changes involved, so its a bit hard to give an
estimate at
this moment, but we shall know once we are starting working on this.
BTW, are we still planing anything for next month's Apache-con? I
am not
sure how this can be done without being able to publish CXF
snapshot to
public repository.
Cheers,
Jervis
-----Original Message-----
From: Dan Diephouse [mailto:[EMAIL PROTECTED]
Sent: 9/23/2006 (???) 1:55 ??
To: [email protected]
Cc:
Subject: Re: Tooling Proposal [was Re: tooling and service model]
I don't know why it would be considered taboo to bring up reasons for
not refactoring the tools like that. There are perfectly valid reasons
to want to avoid doing this - like having limited resources or just
not
caring about the feature or having a schedule the project is trying to
adhere to. I think its best to bring them up and discuss them.
With that said, I do think there are significant benefits from a
longer
term point of view to refactor the tooling like I've proposed - like
reduction of code[1] and extensibility. I also don't think it would be
that hard for someone to do. I am even willing to work on it myself...
Cheers,
- Dan
1. While XFire tooling doesn't have quite as many features as the
Celtix
tooling, it does come in at 2K lines of code, compared to 20K with
Celtix. Thats a significant difference that I dont' think can be
accounted for by features alone.
Bacon, Stephanos wrote:
So I'm guessing that by bringing iona's rationale for not
refactoring the
tools, you probably broke some kind of apache taboo.
I get the impression that in Apache the normal kind of "why waste
time
rewriting something that works" kind of argument doeant hold water
because there is no concept of schedule. If the result is cleaner
code,
then there is a good arument for doing it.
I suspect you'll get flamed :-)
-steph
-----Original Message-----
From: Lin, Bozhong
To: [email protected] <[email protected]>
Sent: Fri Sep 22 02:22:39 2006
Subject: RE: Tooling Proposal [was Re: tooling and service model]
I also agree that it makes a lot of sense to leverage current Celtix
tooling implementation and to do any refactoring only for meeting new
requirements. These tools are fundamental to application users and
IONA
has spent tremendous effort in the past year to maintain and tune the
Celtix tools, making sure that it passes all kinds of complex WSDL
and
Schema, including many issues reported by Celtix users. [1].
Cheers,
Bo
[1]
http://forge.objectweb.org/tracker/index.php?group_id=192&atid=350241
-----Original Message-----
From: Dan Diephouse [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 21, 2006 10:05 PM
To: [email protected]
Subject: Tooling Proposal [was Re: tooling and service model]
2. If we are to write a new tool from scratch, what are the
feature list we have in mind, and how long do we expect to
reach this feature list.
This is not what I'm proposing at all. I too feel this would be
silly.
Here is what I'm proposing:
1. Rewrite the generation part of the tooling to use the Service
model instead of the wsdl. This would involve using the
ServiceFactory to build a ServiceModel and then writing
out class
files from there.
2. Have tools depend on the core for the service model and put each
frontend's generation plugins in the frontend themselves. Moving
the service model to a separate module or common
doesn't make any
sense whatsoever because we still need to depend on the
ServiceFactorys which are in the frontend, so there will be a
dependency on core.
3. Add SOAP 1.2 support to the SoapBindingFactory
4. Add WSDL 2 support to the core (WSDL2ServiceBuilder, etc)
5. Do this refactoring in a tools2 module. While I don't anticipate
that this is a lot of work, this will help us get around the
circular dependency issues and allow us to temporarily
break a few
things.
6. Extra credit: use the CodeModel from Sun instead of our own.
Having our own creates unnecessary work and it is also
too tied to
JAX-WS to be useful outside of it. If you look at JAXB, a whole
host of plugins have arose partly because they use this
code model
that anyone can plug into. As its really not a lot of
work to use
it instead of our, I think we should.
I think we can do this relatively easily and its not as big a
deal as
people are making it out to be. The Celtix tooling is good,
and I don't
want to rewrite it all, I merely want to evolve it.
Cheers,
- Dan
--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com
