Generation fails with "compiler was unable to honor this enum customization"

[rguillens]

I have a project with a module containing common schemas and other independent modules that use that common dependency.

The plugin is unable to generate the classes correctly using the common dependency as an episode correctly included in a catalog.

If the common dependency content is included as part of one of the independent module, discarding the usage of episode and catalog features, the generation works correctly; however I need the modular approach because I have more than one independent module.

Plugin usage:

<plugin>
    <groupId>org.jvnet.jaxb</groupId>
    <artifactId>jaxb-maven-plugin</artifactId>
    <version>4.0.8</version>
    <executions>
                    <execution>
                        <goals>
                            <goal>generate</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <extension>true</extension>
                    <strict>false</strict>
                    <episodes>
                        <episode>
                            <groupId>my.project</groupId>
                            <artifactId>common-schemas</artifactId>
                        </episode>
                    </episodes>
                    <catalog>src/main/resources/catalog.cat</catalog>
                    <verbose>true</verbose>
                </configuration>
</plugin>

The dependency my.project:common-schemas contains an schema that uses jaxb:typesafeEnumClass declarations.

The plugin throws the folloging exception:

com.sun.istack.SAXParseException2: compiler was unable to honor this enum customization. It is attached to a wrong place, or its inconsistent with other bindings.
    at com.sun.tools.xjc.ErrorReceiver.error (ErrorReceiver.java:60)
    at com.sun.tools.xjc.reader.xmlschema.ErrorReporter.error (ErrorReporter.java:58)
    at com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.check (UnusedCustomizationChecker.java:120)
    at com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.check (UnusedCustomizationChecker.java:98)
    at com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.simpleType (UnusedCustomizationChecker.java:224)
    at com.sun.xml.xsom.impl.SimpleTypeImpl.visit (SimpleTypeImpl.java:134)
    at com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.elementDecl (UnusedCustomizationChecker.java:216)
    at com.sun.xml.xsom.impl.ElementDecl.visit (ElementDecl.java:223)
    at com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.run (UnusedCustomizationChecker.java:84)
    at com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.run (UnusedCustomizationChecker.java:75)
    at com.sun.tools.xjc.reader.xmlschema.BGMBuilder._build (BGMBuilder.java:152)
    at com.sun.tools.xjc.reader.xmlschema.BGMBuilder.build (BGMBuilder.java:90)
    at com.sun.tools.xjc.ModelLoader.annotateXMLSchema (ModelLoader.java:398)
    at com.sun.tools.xjc.ModelLoader.load (ModelLoader.java:142)
    at com.sun.tools.xjc.ModelLoader.load (ModelLoader.java:88)
    at org.jvnet.jaxb.maven.XJCMojo.loadModel (XJCMojo.java:59)
    at org.jvnet.jaxb.maven.XJCMojo.doExecute (XJCMojo.java:49)
    at org.jvnet.jaxb.maven.XJCMojo.doExecute (XJCMojo.java:29)
    at org.jvnet.jaxb.maven.RawXJCMojo.doExecute (RawXJCMojo.java:491)
    at org.jvnet.jaxb.maven.RawXJCMojo.execute (RawXJCMojo.java:330)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:126)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:328)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:316)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:212)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:174)
    at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:75)
    at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:162)
    at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:159)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:73)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:53)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:118)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
    at jdk.internal.reflect.DirectMethodHandleAccessor.invoke (DirectMethodHandleAccessor.java:103)
    at java.lang.reflect.Method.invoke (Method.java:580)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:255)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:201)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:361)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:314)
    at org.codehaus.classworlds.Launcher.main (Launcher.java:41)

[laurentschoelens]

Hi @rguillens

Did you try to split the jaxb-bindings of the submodule in a separate binding file ?

It's a best practice to avoid that kind of weird issue when generating java from xsd. It also allows you having one xsd file which is compliant against javax and jakarta code generation since each needs different jaxb:version and namespace declaration

[rguillens]

Hello @laurentschoelens and thank you for your response

I tried splitting the enumeration definition into a separate binding file as you suggested and I discovered a few things in the process:

Simple type declaration:

<xs:element name="CommonNumber" type="tns:CommonNumberType"/>
<xs:simpleType name="CommonNumberType">
<xs:annotation>
    <!--<xs:appinfo>
        <jaxb:typesafeEnumClass name="CommonNumberType">
            <jaxb:typesafeEnumMember name="ONE" value="1"/>
            <jaxb:typesafeEnumMember name="TWO" value="2"/>
            <jaxb:typesafeEnumMember name="THREE" value="3"/>
        </jaxb:typesafeEnumClass>
    </xs:appinfo>-->
    <xs:documentation>
          Common number example
    </xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
    <xs:enumeration value="1">
        <xs:annotation>
            <xs:documentation>
                Number 1
            </xs:documentation>
        </xs:annotation>
    </xs:enumeration>
    <xs:enumeration value="2">
        <xs:annotation>
            <xs:documentation>
                Number 2
            </xs:documentation>
        </xs:annotation>
    </xs:enumeration>
    <xs:enumeration value="3">
        <xs:annotation>
            <xs:documentation>
                Number 3
            </xs:documentation>
        </xs:annotation>
    </xs:enumeration>
</xs:restriction>
</xs:simpleType>

Custom binding file:

<jaxb:bindings schemaLocation="common-types.xsd" node="/xs:schema">
<jaxb:bindings node="xs:simpleType[@name='CommonNumberType']">
    <jaxb:typesafeEnumClass>
        <jaxb:typesafeEnumMember name="ONE" value="1"/>
        <jaxb:typesafeEnumMember name="TWO" value="2"/>
        <jaxb:typesafeEnumMember name="THREE" value="3"/>
    </jaxb:typesafeEnumClass>
</jaxb:bindings>
</jaxb:bindings>

The code generation works in the independent modules, however, ObjectFactory classes related to the common dependency with partial duplicated content are also generated in the independent modules. For now, and to prevent code duplication, I decided to exclude the duplicated common code from the resulting JAR file:

Dependent module plugin usage:

<plugins>
    <plugin>
        <groupId>org.jvnet.jaxb</groupId>
        <artifactId>jaxb-maven-plugin</artifactId>
        <executions>
            <execution>
                <goals>
                    <goal>generate</goal>
                </goals>
            </execution>
        </executions>
        <configuration>
            <extension>true</extension>
            <strict>false</strict>
            <episodes>
                <episode>
                    <groupId>my.project</groupId>
                    <artifactId>common-schemas</artifactId>
                </episode>
            </episodes>
            <catalog>src/main/resources/catalog.cat</catalog>
            <verbose>true</verbose>
        </configuration>
    </plugin>
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-jar-plugin</artifactId>
        <configuration>
            <excludes>
                <exclude>my/project/common/**</exclude>
            </excludes>
        </configuration>
    </plugin>
</plugins>

Do you know if is possible to prevent this code generation duplication?

[laurentschoelens]

In episodes tests projects (here : https://github.com/highsource/jaxb-tools/tree/master/maven-plugin/tests/episodes/b), I don't have that kind of duplicate code generation like yours

Could you provide MRE so I can investigate further ?