Skip to content
This repository has been archived by the owner on Feb 5, 2019. It is now read-only.

Jaxb xjc generation is not 100% consistent for xs:choice #1190

Open
dcabasson opened this issue Apr 26, 2018 · 1 comment
Open

Jaxb xjc generation is not 100% consistent for xs:choice #1190

dcabasson opened this issue Apr 26, 2018 · 1 comment

Comments

@dcabasson
Copy link

dcabasson commented Apr 26, 2018

Xjc generation of a xs:choice produce code that is not always the same. The difference is in the ordering of the @XmlElementRefs in the generated Java class.
This is causing some pain with the cache and change detection. The generated code should always be the same for the same Xml Schema.

When generating from :

   <xsd:complexType name="randomImportType">
        <xsd:choice maxOccurs="unbounded">
            <xsd:element name="aaa" nillable="true" type="xsd:int" />
            <xsd:element name="bbb" nillable="true" type="xsd:int" />
            <xsd:element name="ccc" nillable="true" type="xsd:int" />
            <xsd:element name="ddd" nillable="true" type="xsd:int" />
            <xsd:element name="eee" nillable="true" type="xsd:int" />
            <xsd:element name="fff" nillable="true" type="xsd:int" />
        </xsd:choice>
    </xsd:complexType>

I have had :

   @XmlElementRefs({
        @XmlElementRef(name = "aaa", namespace = "urn:helloWorld/sample/ibm/TestImport", type = JAXBElement.class, required = false),
        @XmlElementRef(name = "ccc", namespace = "urn:helloWorld/sample/ibm/TestImport", type = JAXBElement.class, required = false),
        @XmlElementRef(name = "ddd", namespace = "urn:helloWorld/sample/ibm/TestImport", type = JAXBElement.class, required = false),
        @XmlElementRef(name = "fff", namespace = "urn:helloWorld/sample/ibm/TestImport", type = JAXBElement.class, required = false),
        @XmlElementRef(name = "eee", namespace = "urn:helloWorld/sample/ibm/TestImport", type = JAXBElement.class, required = false),
        @XmlElementRef(name = "bbb", namespace = "urn:helloWorld/sample/ibm/TestImport", type = JAXBElement.class, required = false)
    })
    protected List<JAXBElement<Integer>> aaaOrBbbOrCcc;

or :

    @XmlElementRefs({
        @XmlElementRef(name = "bbb", namespace = "urn:helloWorld/sample/ibm/TestImport", type = JAXBElement.class, required = false),
        @XmlElementRef(name = "fff", namespace = "urn:helloWorld/sample/ibm/TestImport", type = JAXBElement.class, required = false),
        @XmlElementRef(name = "aaa", namespace = "urn:helloWorld/sample/ibm/TestImport", type = JAXBElement.class, required = false),
        @XmlElementRef(name = "ddd", namespace = "urn:helloWorld/sample/ibm/TestImport", type = JAXBElement.class, required = false),
        @XmlElementRef(name = "ccc", namespace = "urn:helloWorld/sample/ibm/TestImport", type = JAXBElement.class, required = false),
        @XmlElementRef(name = "eee", namespace = "urn:helloWorld/sample/ibm/TestImport", type = JAXBElement.class, required = false)
    })
    protected List<JAXBElement<Integer>> aaaOrBbbOrCcc;

generated. Gradle cache considers (correctly) that those 2 are not the same and retrigger all the downstream tasks.

Expected behaviour :
The generated code should always be the same, probably in the order of the original document.

Sample gradle project exposing the issue :
xjc-choice-order.zip

run gradlew xjc at the root and the 2 files :

  • module-1/src/main/java/helloworld/sample/ibm/testimport/RandomImportType.java
  • module-2/src/main/java/helloworld/sample/ibm/testimport/RandomImportType.java

Are not the same.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant