cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <daniel.k...@iona.com>
Subject Re: Proposal to refactor CXF dependencies. WAS: RE: Tooling Proposal [was Re: tooling and service model]
Date Sat, 30 Sep 2006 13:30:19 GMT

Jervis,


On Saturday September 30 2006 6:59 am, Liu, Jervis wrote:
> Hi, can I presume there is no objection to this proposal? ;-) Obviously
> this is a big story, to move things forward, I would like to suggest we
> start from tools refactoring and anything needed for tools refactoring,
> such as jax-ws frontend and  serviceModel etc. To minimize the risk of
> breaking mainline and to allow others working on non-tools refactoring work
> in parallel(such as moving databinding, transport etc from core to rt), we
> will take an incremental step by step approach, at the end of each step, we
> need to make sure all changes are committed to mainline and everything
> should build and run ok.
>
> Below are action items we need to take related to tools refactoring, jax-ws
> and serviceModel.
>
> Step 1:
> 1. Rename rt to core.

No, just:
svn mv rt/core core

The only thing from rt that should be promoted up is the "core" module.   The 
rest should stay in rt.

From there, I would just add the tools2 dir (between core and rt) and start 
building that up.   I'd leave the current tools/common/testutils in place as 
they are for now.   Thus, nothing would change/break on the mainline. 

> 2. Create a new directory and module called "rt" (or plugins). Move jax-ws
> from core to rt.
>
> Cost: 1-2days

See above.   The only thing from rt that should be promoted it "core".   Thus, 
nothing other than core should need to change.

The rest looks pretty good.

Eventually, I think it might be good to then merge Common and API into one.   
A lot of stuff in Common SHOULD be javadoced and such (like the i18n 
exceptions, utils, etc...) and are thus API.   The reason they were separated 
out was so the tools could use it.  Since the tools will now have access to 
the API module, they could be combined.     That's something that can be done 
later though.   Not a huge issue.

Dan

> Step 2:
> 1. Move tools module and testutils module after core, before rt. So the
> dependency path will look like: Common <- API <- Core <- Tools <- testuitls
> <- rt(only contains jax-ws at this moment) <- Systests 2. Move any jax-ws
> related code from tools module to jax-ws module. Tools load jax-ws
> capabilities as plugins. 3. non-jaxws module should not contain any jax-ws
> related code. Currently we use jax-ws generated artifacts in a lot of
> places for testing. This needs to be fixed.
>
> Cost: about 1 week. I expect we will have to spend a lot of time on
> removing jax-ws generated artifacts from non-jaxws modules.
>
> In order to not break mainline for a week, I suggest we create a tools2 to
> hold the work of step2. Once everything is working all tests passed using
> tools2, we can replace tools with tools2.
>
> Step 3:
> 1. Refactor tools to use ServiceModel. ServiceModel lives in core, it
> provides a generic model to represent information from wsdl and classes.
> jax-ws specific info is loaded into serviceModel by
> JaxwsServiceModelBuilder through plugins. JaxwsServiceModelBuilder lives in
> jax-ws module. 2. Add soap1.2, wsdl20 supports into tools by leveraging
> ServiceModel.
>
> Cost: about 1 week
>
>
> Overall we expect we can finish tasks listed above in about 2 to 3 weeks.
> Both James and myself are interested in working on this. As guys in Beijing
> are taking 7 days off from 1st Oct to 7th Oct to celebrate National
> holidays, we can probably kick off from the second week Oct. As I
> personally take 2 weeks off from 1st Oct, I will join James from the third
> week Oct. If things going well, we can finish this by the end of October.
> Note, we do not plan this work for the coming cxf release.
>
> Of course, we also need more volunteers to own non-tooling part
> refactorings, such as transport, databindings etc.
>
> Does this sound good to everyone?
>
> Thanks,
> Jervis
>
> > -----Original Message-----
> > From: Liu, Jervis
> > Sent: Thursday, September 28, 2006 2:37 PM
> > To: cxf-dev@incubator.apache.org
> > Subject: Proposal to refactor CXF dependencies. WAS: RE: Tooling
> > Proposal [was Re: tooling and service model]
> >
> >
> > Hi, we have come out with some new ideas (hopefully better
> > ideas ;-)) on how to resolve dependency problems we have been
> > trying to resolve in this email thread. Below is a summary
> > from IRC chat and email discussions:
> >
> > 1. Promote core to top level. Remove these "extra
> > functionalities" from core, the core remain as small as
> > possible and only provide basic and absolute necessary
> > functionalities. Anything considered as "extra" are moved to
> > rt module (or rename it to plugins). The core acquires those
> > "extra functionalities" through loader plugin. The new
> > dependency path will be: Common <- API <- Core <- Tools <-
> > RT(frontend, databindings etc) <- Systests
> >
> > 2. Candidates that will be moved from core to rt include:
> > a). Frontend: jax-ws, js
> > b). Databindings: jaxb
> > c). Transports: HTTP, JMS
> > d). Protocol bindings: SOAP, XML
> > d). anything else?
> >
> > 3. ServiceModel lives in core, though this serviceModel only
> > provides basic model info. Extra things like jax-ws info is
> > loaded into serviceModel during runtime through plugin loaders.
> >
> > 4. "tools" module provides a basic "tojava" tool and a basic
> > "towsdl" tool that just takes a ServiceModel and does not do
> > specific things.   The other things (frontends, etc..) would
> > provide a plugin that would add a "-jaxws" or "-pojo"  or
> > "-wsdl11" or "-wsdl20" command line switches (or similar) to
> > those tools to enable processing those things.
> >
> > 5. tools module is after core. The good thing is, first we
> > wont have any problems to make tools depend on serviceModel
> > anymore, as the serviceModel is in the core. Secondly and
> > most importantly, tools can use a "Bus.init()" to have a bus
> > load all the available plugins etc. This way we reuse the
> > plugin configurations from bus, it is the Bus's
> > responbilities to search classpath etc to load plugins.
> >
> > How does this sound to everyone? We need to figure out an
> > exact list on what remains in core and what get moved to rt.
> >
> > Cheers,
> > Jervis
> >
> > > -----Original Message-----
> > > From: Kulp, John Daniel
> > > Sent: Thursday, September 28, 2006 1:45 AM
> > > To: cxf-dev@incubator.apache.org
> > > Cc: Mao, Maode (James); Liu, Jervis
> > > Subject: Re: Tooling Proposal [was Re: tooling and service model]
> > >
> > >
> > > James,
> > >
> > > > I think we should define the frontend now, and it also
> > >
> > > should reflect to
> > >
> > > > the code, do we need a frontend api,
> > > > How many frontend do we have , and will we have?
> > > > Currently i know the JAX-WS and javascript are frontends, i
> > >
> > > guess there
> > >
> > > > are more. maybe have a pojo frontend?
> > >
> > > Possibly and SCA frontend, SDO data model, others....
> > >
> > > > My feeling is that if the tools need to reuse the
> > >
> > > servicemodel (which
> > >
> > > > now is in api, the builders in rt), we have to move the
> > >
> > > tools under the
> > >
> > > > rt(which i think is not a good idea though), because we
> > >
> > > have to always
> > >
> > > > keep the frontend in front.
> > > > So why not move the frontend before the tools? let the
> > >
> > > frontend be in
> > >
> > > > front of all.
> > >
> > > Why would the frontends need to be in front of the tools?
> > > If the "frontends"
> > > and "databindings"  provide plugins into the tools, the tools
> > > wouldn't have
> > > to depend on them.
> > >
> > > It's exactly the same as something like the HTTP transport or
> > > SOAP binding.
> > > The HTTP transport or SOAP binding or similar provide extra
> > > functionality to
> > > the core via a plugin.   The core doesn't depend on those.
> > > That's silly.
> > >
> > > What I would envision is a "tools" module (after API, before
> > > RT.   Maybe be
> > > API -> Core -> Tools -> "Others") the provides a basic
> > > "tojava" tool and a
> > > basic "towsdl" tool that just takes a ServiceModel and does
> > > that specific
> > > thing.   The other things (frontends, etc..) would provide a
> > > plugin that
> > > would add a "-jaxws" or "-pojo"  or "-wsdl11" or "-wsdl20"
> > > command line
> > > switches (or similar) to those tools to enable processing
> > > those things.
> > >
> > > If the tools come after core, they could re-use a bunch of
> > > the config things
> > > for loading the plugins.   I'd prefer they just did a
> > > "Bus.init()" and get
> > > the available things from the Bus as the bus should already
> > > have the logic
> > > for searching the classpath, etc....
> > >
> > > Dan
> > >
> > > > Will have a lot of work though.
> > > >
> > > > Cheers,
> > > > James.
> > > >
> > > > Daniel Kulp 写道:
> > > > > I have to admit, I'm COMPLETELY on Dan's side on this argument.
> > > > >
> > > > > On Tuesday September 26 2006 2:58 pm, Liu, Jervis wrote:
> > > > >> a). testuitls will be a big headache. Using
> > >
> > > non-generated test artifacts
> > >
> > > > >> for testing is not only a Big work to do, but also a bad
> > >
> > > work to do.
> > >
> > > > > No, I think using JAX-WS specific generated code in any
> > >
> > > place other than
> > >
> > > > > the JAX-WS frontend and the system tests is bad.   The
> > >
> > > fact that we do it
> > >
> > > > > all over the place is very bad work that we have done.
> > >
> > > I would like to
> > >
> > > > > see this as an opportunity to fix the junk we've started
> > >
> > > and prevent it
> > >
> > > > > from spreading.
> > > > >
> > > > >> Those
> > > > >> pre-written java artifacts (actually in most cases, they
> > >
> > > still have to
> > >
> > > > >> be pre-generated using wsdltojava - do you really want
> > >
> > > to write a SEI
> > >
> > > > >> class manually?) can potentially be out of sync with their wsdl
> > > > >> counter-part, and we might lose the opportunity to catch newly
> > > > >> introduced bugs in this area.
> > > > >
> > > > > The point is that the unit tests (other than in the
> > >
> > > JAX-WS module) should
> > >
> > > > > NOT be using an SEI class at all.   If it needs that type
> > >
> > > of thing, it's
> > >
> > > > > definitely more of a system test and thus it shouldn't be
> > >
> > > in the unit
> > >
> > > > > tests. The unit tests should be unit tests and be able to
> > >
> > > mock anything
> > >
> > > > > specific that they need.
> > > > >
> > > > >> b). Tools, as it stands, should really be a top level
> > >
> > > module that has
> > >
> > > > >> minimal dependencies.
> > > > >
> > > > > Right.   That's fine.  But the plugins for the tools that
> > >
> > > actually do a
> > >
> > > > > lot of the work should live in the appropriate place.
> > >
> > > JAXB code goes in
> > >
> > > > > the JAXB databinding.   JAX-WS stuff goes into the JAX-WS
> > >
> > > frontend.   The
> > >
> > > > > "tools" module is the framework and plugin loader and
> > >
> > > such.   It could
> > >
> > > > > even work similar to the "core" in that it looks for all the
> > > > > META-INF/cxf-tools.xml files and loads tool plugins as found.
> > > > >
> > > > >> I suggest we look further for alternatives, and there is
> > >
> > > an alternative.
> > >
> > > > >> Dan D is right to say that we can not simply abstract
> > >
> > > serviceModel as a
> > >
> > > > >> top level module because its builder (e.g..
> > > > >> ReflectionServiceFactoryBean) is in frontend. But this
> > >
> > > can be fixed. The
> > >
> > > > >> whole idea of ServiceModel, as Dan D said, is having
> > >
> > > wsdl 1.1, wsdl 2,
> > >
> > > > >> or classes, they all get converted into the service
> > >
> > > model. Just think
> > >
> > > > >> about this in general, I do not see why rt is absolutely
> > >
> > > required in
> > >
> > > > >> order to build service model from wsdl or classes.
> > >
> > > Frontend might need
> > >
> > > > >> to decorate the serviceModel with frontend specific
> > >
> > > info, for example,
> > >
> > > > >> if the input is an Jax-ws SEI, the serviceModel needs to
> > >
> > > fill in extra
> > >
> > > > >> Jax-ws meta-data into model using Jax-ws annotations
> > >
> > > contained in SEI.
> > >
> > > > >> Having a Jax-ws ServiceModel extension is not that bad,
> > >
> > > this does make
> > >
> > > > >> serviceModel depends on Jax-ws, but not rt core.
> > > > >
> > > > > But if the core depends on the service model, then it
> > >
> > > also depends on
> > >
> > > > > JAX-WS. That is exactly what we don't want.    All the
> > >
> > > JAX-WS specific
> > >
> > > > > stuff NEEDS to stay in the JAX-WS frontend.
> > > > >
> > > > >
> > > > > Dan
> > > > >
> > > > >> I am not that familiar with this part of code, but based
> > >
> > > on my initial
> > >
> > > > >> look I think it is doable to move ServiceModel as a top
> > >
> > > level modul,
> > >
> > > > >> then make both tools and rt depends on serviceModel. Sth
> > >
> > > like below
> > >
> > > > >> should work:
> > > > >>
> > > > >> public class ServiceModelBuilder {
> > > > >>     public void setWsdlURL(URL wsdlURL) {
> > > > >>     }
> > > > >>
> > > > >>     public void setServiceClass(Class<?> serviceClass)
{
> > > > >>     }
> > > > >>
> > > > >>     public ServiceInfo getServiceInfo() {
> > > > >>     }
> > > > >>
> > > > >>     protected void initServiceModel() {
> > > > >>         //if wsdl is provided, build serviceModel from WSDL
> > > > >>             //if it is wsdl11
> > > > >>             //if it is wsdl20
> > > > >>
> > > > >>         //if no wsdl, but serviceClass, build model from class
> > > > >>
> > > > >>         //if both wsdl and class are provide, build model from
> > > > >>         //wsdl first, then retrieve extra meta-data from class
> > > > >>     }
> > > > >>
> > > > >>     //some other methods allow decorating serviceModel
> > >
> > > with extra info
> > >
> > > > >>     //after the model is created.
> > > > >> }
> > > > >>
> > > > >> public class JaxwsServiceModelBuilder {
> > > > >>
> > > > >>     protected void initServiceModel() {
> > > > >>             super.initServiceModel();
> > > > >>             //adding extra jaxws info
> > > > >>     }
> > > > >> }
> > > > >>
> > > > >> We will run into some problems, for example, when
> > >
> > > building model from
> > >
> > > > >> WSDL, we currently have WSDLManager and BindingFactory
> > >
> > > involved, which
> > >
> > > > >> are from rt. I hope those problems can be resolved case
> > >
> > > by case. But I
> > >
> > > > >> might miss sth completely, so please do shout out if
> > >
> > > anyone has any
> > >
> > > > >> insight that knows this approach is completely broken.
> > > > >>
> > > > >> Cheers,
> > > > >> Jervis
> > > > >>
> > > > >>> -----Original Message-----
> > > > >>> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > > > >>> Sent: 2006?9?26? 22:24
> > > > >>> To: cxf-dev@incubator.apache.org
> > > > >>> Subject: Re: Tooling Proposal [was Re: tooling and
> > >
> > > service model]
> > >
> > > > >>> Hiya,
> > > > >>>
> > > > >>> James Mao wrote:
> > > > >>>> 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.
> > >
> > > > >>> I really disagree. There is no way to make it a
> > >
> > > completely separate
> > >
> > > > >>> module unless we have duplicate code which does wsdl/jax-ws
> > > > >>> processing
> > > > >>> in the tools. This causes more maintenance and more
> > >
> > > bugs in the long
> > >
> > > > >>> run, so I'm pretty -1 against that. And, as I mentioned
> > >
> > > before, this
> > >
> > > > >>> isn't that much more code to include. We could even put
> > >
> > > together a
> > >
> > > > >>> bundled jar if people are really concerned about too many
> > > > >>> jars. I also
> > > > >>> don't like the current approach because the jax-ws
> > >
> > > generation isn't
> > >
> > > > >>> associated with the jax-ws module in any way, and it seems
to
> > > > >>> me thats
> > > > >>> where the generators should be.
> > > > >>>
> > > > >>>> 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.
> > >
> > > > >>> That misses the whole point of the service model. The
> > >
> > > point of the
> > >
> > > > >>> service model is that wsdl 1.1, wsdl 2, and classes all
> > >
> > > get converted
> > >
> > > > >>> into the service model and then artifacts are generated
> > >
> > > from that.
> > >
> > > > >>> - Dan
> > > > >>>
> > > > >>>> Cheers.
> > > > >>>> James.
> > > > >>>>
> > > > >>>> 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:    cxf-dev@incubator.apache.org
> > > > >>>>>>> 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:dan@envoisolutions.com]
> > > > >>>>>>> Sent:    9/23/2006 (???) 1:55 ??
> > > > >>>>>>> To:    cxf-dev@incubator.apache.org
> > > > >>>>>>> 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: cxf-dev@incubator.apache.org
> > >
> > > <cxf-dev@incubator.apache.org>
> > >
> > > > >>>>>>>> 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:dan@envoisolutions.com]
> > > > >>>>>>>>> Sent: Thursday, September 21, 2006
10:05 PM
> > > > >>>>>>>>> To: cxf-dev@incubator.apache.org
> > > > >>>>>>>>> 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
> > >
> > > --
> > > J. Daniel Kulp
> > > Principal Engineer
> > > IONA
> > > P: 781-902-8727    C: 508-380-7194   F:781-902-8001
> > > daniel.kulp@iona.com

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194   F:781-902-8001
daniel.kulp@iona.com

Mime
View raw message