cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Mao <>
Subject Re: Tooling Proposal [was Re: tooling and service model]
Date Tue, 26 Sep 2006 03:56:20 GMT
I still think that Tools should be an independent module, it should not 
after rt, the benefit of independence is that you can use tools any time 
you want.
And ideally the tools can be split as an outside project, so when 
someone want to use just tools, what they need is just include the 
cxf-tools.jar and cxf-common.jar in their classpath,
there will no cxf-rt.jar or others will be needed, one thing i can 
imagine is that if you want to use tools in a WebService GUI, i think 
STP project already did so, is you include just two jars not a lot.

About ServiceModel, I think it should also be an independent module, and 
for tools or rt, i think it'll be great if we have an plug-able api, so 
the tools and rt are not directly reference ServiceModel, and if you 
want to replace the ServiceModel with other Model(Wooden) will be possible.
For the builder which build servicemodel should stay in servicemodel, 
just like Wsdl4j, they provider a model and also provide a builder.


Daniel Kulp 写道:
> The BIGGEST change, and probably the one requiring the most work, is regarding 
> the testutils module.   
> We currently build the testutils modules before the API and RT modules so that 
> tests in those modules can access the stuff that is generated "once" in the 
> testutils.    If the code generators are not available until after rt, ALL 
> the tests in the rt and api packages will need to be updated to use 
> non-generated stuff.    That will be a lot of work, although not a bad idea 
> to completely remove the jax-ws dependencies....
> That's something that DEFINITELY needs to be thought about and addressed in 
> the proposal.
> Dan
> On Monday September 25 2006 3:29 pm, Dan Diephouse wrote:
>> The current dependency path will change as part of the proposal. The
>> path will then be API <- RT <- Tools. The JAX-WS module would then
>> contain a default plugin profile for the tools to generate JAX-WS
>> artifacts. This is why I said we should copy tools to tools2: that way
>> we can change the dependency path without breaking the build for a week :-)
>> - Dan
>> Liu, Jervis wrote:
>>> 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:
>>> 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 []
>>> Sent:	9/23/2006 (???) 1:55 ??
>>> To:
>>> 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: <>
>>>> 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]
>>>>> -----Original Message-----
>>>>> From: Dan Diephouse []
>>>>> Sent: Thursday, September 21, 2006 10:05 PM
>>>>> To:
>>>>> 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

View raw message