[jira] Commented: (CXF-658) Tool dependecies on runtime components

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

    [ https://issues.apache.org/jira/browse/CXF-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498086 ] 

maomaode commented on CXF-658:
------------------------------

This is done in http://svn.apache.org/viewvc?view=rev&rev=520805, 
previous the xsds are in common/schemas and  xsd2java them in rt/transports
This is not ok since tools remove it's own wsdl extensions and want to reuse the wsdldefinitionbuilder in rt/core

Then we moved the xsds into tools/common, and xsd2java them in tools/common, so we don't need to depends on the specific transports/bindings in tools, if there's a new transports/bindings, we don't need to add dependencies in tools, because rt/core will load them automatically. 

So IMO the xsds should be in a common place which can be loaded by rt/core and tools.

I also feel xsds in tools/common is not quite a good place.  I was trying to put them in API module, because i believe the wsdl extensions should also be API doc-ed. I can not remember the exact reason why it can not be placed in API, maybe some xsd2java plugin problems, then i decided to place some into tools/common. and make the jms depend on tools/common.

If we can place them in API, everything will be just fine.

I'm trying to move to API again, is that ok?

> Tool dependecies on runtime components
> --------------------------------------
>
>                 Key: CXF-658
>                 URL: https://issues.apache.org/jira/browse/CXF-658
>             Project: CXF
>          Issue Type: Bug
>          Components: Tooling
>    Affects Versions: 2.0-RC
>            Reporter: Andrea Smyth
>         Assigned To: maomaode
>
> In order to get schema validation working for all of our Spring XML extensions I wanted to make some changes to jms.xsd.
> I was a bit surprised to find this schema not in the jms module itself but in cxf- tools-common instead (and jms-context.xsd in cxf-common-schemas). 
> An attempt to move it into xf-rt-transports-jms revealed a dependency of cxf-tools-wsdlto on this schema. This dependency is wrong and violates the principle of extensibility.
> If tools want to support generation of code/wsdl that involves details of a specific binding or transport they should do so via an interface instead of hardcoding that dependency into the generators.
> The concept of customising xjc with plugins is an example of how this can be done: the generator/tool checks on its path for components that are able to generate address elements for a particular address type "jms". If the jms module is on the path that is should implement the bit that is needed by the tool,  fine, the tool embeds the result into whatever else it generates.  Otherwise the tool fails with: "No processor found for adddress type "jms" or similar.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.