cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bozhong Lin (JIRA)" <j...@apache.org>
Subject [jira] Created: (CXF-223) Refactor CXF Dependencies
Date Mon, 13 Nov 2006 03:36:37 GMT
Refactor CXF Dependencies
-------------------------

                 Key: CXF-223
                 URL: http://issues.apache.org/jira/browse/CXF-223
             Project: CXF
          Issue Type: Improvement
            Reporter: Bozhong Lin


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" <jliu@iona.com>
Date: Thu, 28 Sep 2006 01:36:46 -0500
To: <cxf-dev@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

        

Mime
View raw message