[jira] Updated: (CXF-223) Refactor CXF Dependencies

["Bozhong Lin (JIRA)" <ji...@apache.org>]

     [ http://issues.apache.org/jira/browse/CXF-223?page=all ]

Bozhong Lin updated CXF-223:
----------------------------

        Fix Version/s: 2.0-RC
    Affects Version/s: 2.0-RC
             Assignee: willem Jiang

> Refactor CXF Dependencies
> -------------------------
>
>                 Key: CXF-223
>                 URL: http://issues.apache.org/jira/browse/CXF-223
>             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 here http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200609.mbox/browser
> Subject: Proposal to refactor CXF dependencies. WAS: RE: Tooling Proposal [was Re: tooling and service model]
> From: "Liu, Jervis" <jl...@iona.com>
> Date: Thu, 28 Sep 2006 01:36:46 -0500
> To: <cx...@incubator.apache.org>
> 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: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira