Re: Tooling Proposal [was Re: tooling and service model]

Fri, 22 Sep 2006 10:56:34 -0700

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























					Reply via email to