xjc: Deux déclarations de causer une collision dans le ObjectFactory classe

Exécutant la commande suivante xjc de commande génère une erreur :

$ xjc "ftp://ftp.ncbi.nih.gov/bioproject/Schema/Core.xsd"
parsing a schema...
compiling a schema...
[ERROR] Two declarations cause a collision in the ObjectFactory class.
  line 340 of ftp://ftp.ncbi.nih.gov/bioproject/Schema/Core.xsd

[ERROR] (Related to above error) This is the other declaration.   
  line 475 of ftp://ftp.ncbi.nih.gov/bioproject/Schema/Core.xsd

Même si je comprends la JAXB liaisons et quels sont les conflits dans XJC, je ne comprends pas où est le conflit dans le schéma actuel.

comment dois-je résoudre ce problème ?

Merci,

Pierre

mise à jour: voici le contexte de l'erreur:

$ curl -s "ftp://ftp.ncbi.nih.gov/bioproject/Schema/Core.xsd" | sed 's/^[ \t]*//' | cat -n | egrep -w -A 10 -B 10 '(340|475)' 
330  <xs:element maxOccurs="1" name="Description"
331  type="xs:string" minOccurs="0">
332  <xs:annotation>
333  <xs:documentation>
334  Optionally provide description especially when "eOther" is selected
335  </xs:documentation>
336  </xs:annotation>
337  </xs:element>
338  <xs:element name="BioSampleSet" minOccurs="0" maxOccurs="1"><xs:annotation><xs:documentation>Identifier of the BioSample when known</xs:documentation>
339  </xs:annotation>
340  <xs:complexType><xs:sequence><xs:element name="ID" maxOccurs="unbounded" type="xs:token"></xs:element>
341  </xs:sequence>
342  </xs:complexType>
343  </xs:element>
344  </xs:sequence>
345  <xs:attribute name="sample_scope" use="required">
346  <xs:annotation>
347  <xs:documentation>
348  The scope and purity of the biological sample used for the study
349  </xs:documentation>
350  </xs:annotation>
--
465  <xs:documentation>Please,  fill Description element when choose "eOther"</xs:documentation>
466  </xs:annotation>
467  </xs:enumeration>
468  </xs:restriction>
469  </xs:simpleType>
470  </xs:attribute>
471  </xs:complexType>
472  </xs:element>
473  <xs:element name="TargetBioSampleSet">
474  <xs:annotation><xs:documentation>Set of Targets references to BioSamples</xs:documentation></xs:annotation>
475  <xs:complexType>
476  <xs:sequence>
477  <xs:element name="ID" type="xs:token" minOccurs="1" maxOccurs="unbounded"></xs:element>                                                 
478  </xs:sequence>
479  </xs:complexType>
480  </xs:element>                        
481  </xs:choice>
482  <xs:element name="Method" minOccurs="1">
483  <xs:annotation>
484  <xs:documentation>
485  The core experimental approach used to obtain the data that is submitted to archival databases
  • je ne pense pas que n'importe qui peut vous aider si vous ne fournissez pas les parties pertinentes de Base.xsd
  • Également essayer d'utiliser la plus récente de Java JDK de les générer. J'ai eu beaucoup de dupliquer les erreurs à l'aide du JDK 1.7 jusqu'à ce que j'ai utilisé xjc dans le JDK 1.8. Aussi dans le cas où quelqu'un essaie de générer par clic droit > Générer dans Eclipse, assurez-vous de l'essayer à partir de la ligne de commande trop. Ce faisant résolu erreur pour moi.
InformationsquelleAutor Pierre | 2012-11-16
  1. 26

    Je vais citer la plupart des officiels guide non officiel sur JAXB sur le net.

    Lorsque des schémas contiennent les mêmes à la recherche de l'élément/type de noms, ils peuvent
    suite "Deux déclarations de causer une collision dans le ObjectFactory
    la classe des" erreurs. Pour être plus précis, pour chacun de tous types et de nombreux
    éléments (exactement quels éléments sont d'une usine et ce qui ne l'est pas, c'est peu
    difficile à expliquer), XJC produit une méthode de la classe ObjectFactory
    dans le même package. Le ObjectFactory classe est créée pour chaque
    package XJC génère des fichiers. Le nom de la méthode est
    dérivé de XML de l'élément/type de noms, et l'erreur est signalée si deux
    éléments/types d'essayer de générer le même nom de méthode.

    Cela dit, vous avez deux options.

    La première est de définir un externe de liaison XML comme ceci

    <jaxb:bindings xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
version="1.0">
<jaxb:bindings schemaLocation="Core.xsd">
<jaxb:bindings node="//xs:element[@name='BioSampleSet']/xs:complexType">
<jaxb:factoryMethod name="TypeBioSampleSet"/>
</jaxb:bindings>
<jaxb:bindings node="//xs:element[@name='TargetBioSampleSet']/xs:complexType">
<jaxb:factoryMethod name="TypeTargetBioSampleSet"/>
</jaxb:bindings>
</jaxb:bindings>
</jaxb:bindings>

    Dans le générés ObjectFactory classe, cela va créer deux méthodes appelées createTypeBioSampleSet et createTypeTargetBioSampleSet (JAXB ajouter le nom que vous spécifiez pour le mot create) qui peut être utilisé pour produire de l' BioSampleSet et TargetBioSampleSet objets.

    (Il n'est pas nécessaire de définir une liaison pour les deux types.)

    Je ne suis pas exactement pourquoi, JAXB refuse de générer des classes du schéma donné, mais quand j'ai spécifié une seule liaison (pour BioSampleSet par exemple), alors que l'autre type de méthode de fabrique, a été nommé comme createTypeProjectProjectTypeSubmissionWhateverThisAndThatTargetTargetSampleBioCatDogWoofTypeIDoNotKnowWhatElse donc je pense que JAXB étouffé sur cette longue identificateur de méthode, parce qu'il a réussi à créer le même pour les deux types. Je pense que c'est de l'implémentation en détail dans JAXB.

    L'autre solution est de créer un type de base pour un BioSampleSet et de l'utiliser à la fois des endroits comme ce

    <xs:element name="ProjectTypeSubmission">
...
<xs:element name="Target">
...
<xs:element name="BioSampleSet" type="typeBioSampleSet" minOccurs="0" maxOccurs="1"/>
...
</xs:element>
...
<xs:element name="TargetBioSampleSet" type="typeBioSampleSet"/>
...
<xs:element/>
...
<xs:complexType name="typeBioSampleSet">
<xs:sequence>
<xs:element name="ID" maxOccurs="unbounded" type="xs:token"></xs:element>
</xs:sequence>
</xs:complexType>

    La meilleure solution serait de supprimer chaque type anonyme déclarations de votre schéma. Si vous pouvez le faire, le faire, parce que ce schéma ressemble à un gâchis (du moins pour moi).

    InformationsquelleAutor Kohányi Róbert