cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jervis Liu (JIRA)" <>
Subject [jira] Resolved: (CXF-223) Refactor CXF Dependencies
Date Tue, 16 Jan 2007 10:43:27 GMT


Jervis Liu resolved CXF-223.

    Resolution: Fixed

This is done (and will be done) as part of tooling refactoring (tools2), all related stories
can be found under tooling component.

> Refactor CXF Dependencies
> -------------------------
>                 Key: CXF-223
>                 URL:
>             Project: CXF
>          Issue Type: Improvement
>    Affects Versions: 2.0-RC
>            Reporter: Bozhong Lin
>         Assigned To: willem Jiang
>             Fix For: 2.0-RC
> The problem of CXF dependencies came up when team was discussing tooling refactoring
to reuse service model and support multiple databiding, a proposal was presented in mailing
discussion as following, for the origial proposal, you can also following mail archive link
> Subject: Proposal to refactor CXF dependencies. WAS: RE: Tooling Proposal [was Re: tooling
and service model]
> From: "Liu, Jervis" <>
> Date: Thu, 28 Sep 2006 01:36:46 -0500
> To: <>
> 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

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message