[
https://issues.apache.org/jira/browse/CXF-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
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: https://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" <[EMAIL PROTECTED]>
> Date: Thu, 28 Sep 2006 01:36:46 -0500
> To: <[email protected]>
> 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:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
