[
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.
