Lin, Bozhong wrote:
[don't know why my previous "send" did not make it, here send it again]
Hi,
Right now, various resources (configuration metadata, configurations,
schemas) used by CXF are dispersed in different modules, and these
resources are eventually packaged in different jars. This causes a
couple issues:
1. Some schemas are duplicated in several modules and packages, such as
wsdl.xsd and addressing.xsd. This could become difficult to maintain in
the long run.
Hi Bo,
IMO the schemata should appear in the module that first uses them (in
case of the addressing.wsdl that may actually be shifted to
cxf-rt-ws-addr, but then the addressing part in the api module should
also be moved into the addressing module, which could perhaps be
substructured into api and impl packages). This avoids duplication and
ensures extensibility.
Tests in cxf-tools-validator and cxf-tools-wsdl2java and source in
cxf-rt-databinding should use the resources in cxf-common-metacode
instead of their own copies.
2. End users need access to some of resources, such as configuration
metadata and runtime configurations. In current distribution, these
resources are packaged in jar and they are hard for users to access and change.
These resources are not meant to be changed - and leaving them in their
resp. jars provides some protection against that.
I agree however that in a binary distribution it would be easier for
users to e.g. provide overrides for default bean definitions in their
user cfg files if they could find the default cfg file fragments in some
directory instead of having to extract them from a jar.
The downside of making these resources available on disk in binary
distributions is that users may change them and then wonder why their
changes do not have any effect.
Andrea.
I see two options to resolve the issues:
1. consolidate all resources to location
common/common/src/main/resources, and distribution can easily copy all
resources in this location to an installation directory accessible to
end users.
2. modify current distribution to pick up resource in various modules
and put them under an installation location accessible to end users.
Maintenance is still an issue with this option.
What do you guys think about this?
Thanks,
Bo
