Aqui está um pequeno exemplo do que eu gostaria de alcançar:

Artefato A do @Maven é um dos muitos serviços da Web e define um Esquema XSD com definições para Solicitações e Respostas. (src / main / recursos / xsd)

artefato A depende do artefato B, que é um projeto JAR simples e contém uma infinidade de XSDs principais com descrições de tipo de baixo nível. (src / main / recursos / xsd)

Os XSDs no Artefato A usam as definições de tipo (incluídas) especificadas uma vez no Artefato B.

Se possível, eu realmente gostaria de saber como incluir arquivos xsd localizados em um jar que é carregado como uma dependência independente e como resolver o serviço web xsd (e wsdl) em IDEs como Netbeans e Eclips

Se essa abordagem parecer exótica - existem práticas recomendadas para um design limpo?

atualiza

Primeiro, aqui está um exemplo simples de como eu esperaria que o esquema incluísse para funcionar ....

Artifact A (WAR Module)
POM:
...
<artifactId>A</artifactId>
...
<dependency>
  <artifactId>B</artifactId>
  ...
</dependency>

Schema:
....
<xs:include schemaLocation="classpath://net/elfwyn/xsd/schema.xsd"/>
....

Artifact B (JAR Module)

Schema Location:
src/main/resources/net/elfwyn/xsd/schema.xsd

Parece haver várias soluções para um problema como esse, mas não sei como implementá-las no meu ambiente:

Conheço resolvedores de catálogos incorporados no IDE (netbeans7.1) (para ambiente de desenvolvimento) e disponíveis como plug-ins Maven (para ambiente produtivo), que devem poder especificar um alias no local do arquivo de esquema. Esse alias deve ser usado como o local do esquem

No entanto, não sei como especificar um Catalog.xml que acessa esquemas dentro de um arquivo JAR. Para mim, parece ser o mesmo problema que especificá-lo diretamente no local do esquema. Também existe a sobrecarga de manter o catálogo para cada projeto WAR que eu preferiria não aceitar, se possíve

No que diz respeito ao plugin Maven, ainda não encontrei nada conclusiv

De outrosfonte estão implementando um resolvedor de catálogo personalizado no contexto de jax-b, mas ainda não vejo um possível gancho para implementar esse resolvedor em um ambiente Java-WS e como ele deve funcionar em conjunto com o maven-plugin mencionado acima ou o resolvedor do catálogo IDE ...