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 >> >> >> >> > > > -- Dan Diephouse (616) 971-2053 Envoi Solutions LLC http://netzooid.com
