[
https://issues.apache.org/jira/browse/CXF-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
maomaode resolved CXF-658.
--------------------------
Resolution: Fixed
Fix Version/s: 2.0
> 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
> Assignee: maomaode
> Fix For: 2.0
>
>
> 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.
