JAXB: génération de classes pour deux XSD partageant un XSD commun

J'ai 2 fichiers XSD Service.xsd et BService.xsd chacun avec différentes targetNamespace. Ces deux utiliser un commun XSD appelé commun.xsd. J'utilise le JAXB plugin Maven pour générer des classes. Voici comment,

<execution>
    <id>generate-package</id>
    <goals>
        <goal>generate</goal>
    </goals>
    <configuration>
        <extension>true</extension>
        <schemaIncludes>
            <include>schema/Aservice.xsd</include>
            <include>schema/Bservice.xsd</include>                             
        </schemaIncludes>
        <bindingIncludes>                                   
            <include>schema/*.xjb</include>
        </bindingIncludes>
        <generatePackage>com.schema</generatePackage>
        <generateDirectory>src/main/java</generateDirectory>
    </configuration>
</execution>

Lorsque j'essaie d'exécuter ce que j'obtiens l'erreur suivante. ValidationType est défini en commun.xsd

org.xml.sax.SAXParseException: A class/interface with the same name "com.schema.ValidationType" is already in use. Use a class customization to resolve this conflict.
..........
org.xml.sax.SAXParseException: (Relevant to above error) another "ValidationType" is generated from here.
......
com.sun.istack.SAXParseException2: Two declarations cause a collision in the ObjectFactory class.

Si je lance le 2 service xsds dans 2 différentes exécutions de génération en 2 paquets différents, j'ai le même ValidationType classe en 2 paquets différents.

Des idées sur comment faire de JAXB reconnaître partagé schémas?

source d'informationauteur Aravindan R

5

Vous êtes face à un soi-disant "caméléon schéma" qui est considéré comme une mauvaise pratique. Malheureusement, il n'y a pas de bonne solution en raison de la nature de JAXB. JAXB annotation lier des propriétés du bean à des éléments et attributs XML dans des espaces de noms spécifiques (définies dans le schéma de la compilation). Donc, une fois votre schéma est compilé, il n'existe pas de bonne façon de changer les espaces de noms des éléments et des attributs de vos propriétés sont liées à l'.

Cependant, c'est exactement ce que vous voulez atteindre avec "caméléon" schémas. Les Classes dérivées de "commun.xsd" devrait en quelque sorte comme par magie la carte de l'espace de noms d'Un si utilisé dans des classes et de l'espace de noms B si elle est utilisée en B classes. Je peux imaginer cette magie, mais jamais vu dans la vraie vie.

Puisque vous voulez Un/commun et B/commun d'être la "même chose", l'une des façons de le résoudre est de générer des A et B (avec commune) en deux exécutions et à faire des classes communes de mettre en œuvre un certain "commun" de l'interface. Ensuite, votre logiciel peut traiter Un/commun et B/commune dans la même faschion indépendamment du fait que ce sont en fait des classes de différents packages.

Mise à JOUR:

De commentaire je vois que vous n'avez pas de caméléon schéma, mais juste un type normal de l'importation. Il est facile ensuite, il suffit de compiler commune, A et B séparément. Voir la Schéma distinct de compilation pour maven-jaxb2-plugin.

Je l'ai adapté les paquets que décrit ici, http://jaxb.java.net/guide/Customizing_Java_packages.html. Donc common.xsd va dans com.common.schema et est partagé par AService.xsd et BService.xsd qui sont à la fois dans les différents paquets eux-mêmes, car ils sont dans des espaces de noms différents.

La generatePackage est retiré de l'maven configuration et ressemble à ceci,

<execution>
    <id>generate-package</id>
    <goals>
        <goal>generate</goal>
    </goals>
    <configuration>
        <extension>true</extension>
        <schemaIncludes>
            <include>schema/Aservice.xsd</include>
            <include>schema/Bservice.xsd</include>                            
        </schemaIncludes>
        <bindingIncludes>
            <include>schema/*.xjb</include>
        </bindingIncludes>                                
        <generateDirectory>src/main/java</generateDirectory>
    </configuration>
</execution>

Vous devez vous connecter pour publier un commentaire.