且构网

分享程序员开发的那些事...
且构网 - 分享程序员编程开发的那些事

防止在没有名称空间的情况下从XSD生成重复的类

更新时间:2022-10-14 22:56:59

这是对为什么剧集失败的解释,遗憾的是,这不是你问题的答案。 / p>

您可以使用 jaxb:class / @ ref 绑定将您的架构类型映射到某个现有类。请参阅Blaise的这篇文章



简而言之,你可以这样做:

 < jaxb:binding node = ......指向你的类型> 
< jaxb:class ref =ExistingClass/>
< jaxb:binding>

在这种情况下, ExistingClass 将被重复使用你的类型。



你正试图让它适用于剧集。第一集,实质上就是一组这样的映射。但是剧集使用SCD(架构组件指示符)指向带有XPath-Expressions的类型,而不是节点。 SCD是名称空间驱动的。如果你没有命名空间 - 或者更好的说 - 你有 chameleon命名空间设计,那么你没有正确的命名空间。因此剧集失败。



问题是你的普通类应该使用主机模式的命名空间(这就是变色龙设计的意义)。实际上,注释中提供了命名空间和本地名称。如果您只有一组类和一组注释 - 那么您只有一个名称空间。所以目前我还没有看到只有一套普通类的简单方法。



如果你能使用 A B 分开,也就是说,同时不在同一个上下文中,然后可以欺骗注释阅读器使用指定的常用的命名空间。



但如果你想同时使用A和B,我真的不喜欢我知道怎么做。也许您可以为 common 创建一个命名空间,然后应用一些预处理来替换此命名空间中A和B中的公共元素的命名空间......



所以这不是答案,而是对背景的详细说明。


I am currently implementing functionally for our Netbeans Platform application using classes generated by JAXB using the Mojo Maven plugin 'jaxb2-maven-plugin'. Unfortunately the creation of the XSD files is not in my hands and they are confidential. I am trying to provide a minimal running example to further demonstrate this but for now I hope that somebody can push me in the right direction solely from my description.

We have many XSD files and got a few additions in the last weeks. Two of these XSDs (lets call them A.xsd and B.xsd) include another XSD (lets call it common.xsd) which contains common types used by both of the other XSDs. This common.xsd has no namespace and this should stay this way.

This creates the following problem: For types defined in this common.xsd there are three duplicates generated by xjc. One residing in a package named 'generated' (exactly the classes I want to use) and two others residing in the packages of A.xsd and B.xsd which are mostly the same as the classes in 'generated' except a few namespaces which are not needed by me.

I understand from reading a few other questions on *** that Episodes would resolve this but I am not getting this to work with a XSD without a namespace.

My plugin configuration in my POM is pretty simple:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>jaxb2-maven-plugin</artifactId>
    <configuration>
        <npa>true</npa>
    </configuration>
    <executions>
       <execution>
            <goals>
                <goal>xjc</goal>
            </goals>
       </execution>
    </executions>
</plugin>

Is there a resolution for this problem using episodes with a special configuration or maybe some kind of binding that I can use to resolve this?

This is an explanation of why episodes fail, unfortunately, not an answer to your question.

You can use jaxb:class/@ref binding to map your schema type onto some existing class. See this post by Blaise.

In short, you can do something like:

<jaxb:binding node="...point to your type here">
    <jaxb:class ref="ExistingClass"/>
<jaxb:binding>

In this case ExistingClass will be reused for your type.

You are trying to make it work with episodes. Episode, in essence is exactly a set of such mappings. BUT episodes use SCD (schema component designator) to point to types, NOT node with XPath-Expressions. And SCD is namespace-driven. If you have no namespace - or, better to say - you have chameleon namespace design, then you don't have a correct namespace. Therefore episodes fail.

The problem is that your "common" classes should use the namespace of the "host" schema (this is what chameleon design is about). Namespace and local names are actually provided in annotations. If you have just one set of classes and one set of annotations - then you have just one namespace. So at the moment I don't see an easy way to have just one set of "common" classes.

If you can to use A and B separately, that is, not in the same context at the same time then it would be possible to trick the annotation reader to use the specified namespace for common.

But if you want to use A and B at the same time, I really don't know how to do it. Maybe you could invent a namespace for common and then apply some preprocessing to replace the namespaces for common elements in A and B by this namespace...

So this is not an answer, more an elaboration on the backgrounds.