maven-jaxb2-plugin fails with JAXB version attribute must be present

Question

I have the following configuration for maven-jaxb2-plugin:

            <!-- https://mvnrepository.com/artifact/org.jvnet.jaxb2.maven2/maven-jaxb2-plugin -->
            <plugin>
                <groupId>org.jvnet.jaxb2.maven2</groupId>
                <artifactId>maven-jaxb2-plugin</artifactId>
                <version>0.13.2</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>generate</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <strict>false</strict>
                    <schemaLanguage>WSDL</schemaLanguage>
                    <generatePackage>com.mycompany.project.domain.wsdl</generatePackage>
                    <schemas>
                        <schema>
                            <url>url or file</url>
                        </schema>
                    </schemas>
                </configuration>
            </plugin>

and it is failing with:

[ERROR] Error while parsing schema(s).Location [ file:/home/hasancansaral/workspace/company/domain/src/main/xsd/delivery.wsdl{2,366}].

org.xml.sax.SAXParseException; systemId: file:/home/hasancansaral/workspace/company/domain/src/main/xsd/delivery.wsdl; lineNumber: 2; columnNumber: 366; JAXB version attribute must be present

It doesn't make a difference if I run the plugin through IntelliJ IDEA or do a simple mvn clean jax2b:generate. However, the action is successful with the schema that can be found here, so I am suspecting of my wsdl schema being actually malformed, which I cannot make public for the moment, but can provide via messages (I know that it is not much help to public as is, but if the problem is in the schema I will post the related problematic part of it here).

Note: SOAP UI validates the schema as well.

Note2: Same error is present with both jax2b-maven-plugin and maven-jax2b-plugin.

Frontpage

First I would suggest to use jaxb2-maven-plugin...and using an uptodate version...If you checked against another schema means you schema must be the culprit... – Jeanejeanelle

@Jeanejeanelle Thanks for the comment. I have tried both plugins, and up-to-date versions of both of them. I too suspect from a malformed schema, and appreciate if you could look at it. Do you mind if I send you the schema over chat? – Frontpage

@Jeanejeanelle And I can successfully consume the webservice with SoapUI. – Frontpage

@Jeanejeanelle "First I would suggest to use jaxb2-maven-plugin..." - why? – Longcloth

@HasanCanSaral Show your WSDL. Could you put a reproducing example? PR here: github.com/highsource/maven-jaxb2-plugin-support, I'll take a look. – Longcloth

@Longcloth Done, Appreciate your help. Please see here for PR, didn't open an issue for the plugin itself, as I am not sure if it's a plugin issue or simply a bad schema. – Frontpage

@HasanCanSaral Thank you, I've seen it. The problem is that you have inline jaxb:class customizations. Therefore XJC expects jaxb:version on schema. I'll take a look on the weekend. – Longcloth

@Longcloth Thank you, I appreciate it very much. The problem is that the schema is provided by some 3rd party and it's not a file but an actual URL. So I have downloaded it and am trying to resolve the issue by editing the file, as I have no control over wsdl provided from the URL. Looking forward for your answer then. Thanks! – Frontpage

I have the exact same issue. Have you found a solution? – Raddatz

@OgnjenMišić Yes, the accepted answer actually solved my issue. – Frontpage

@HasanCanSaral how exactly? How did you "patch the wsdl"? The WSDL I'm supposed to consume I have access to locally only (but I think that would suffice?), the soapui can read it properly while my wsimport / xjc still throw these errors.. – Raddatz

You save it to your resources folder/filesytem and point it to the file you saved in your configuration, then you can update it. The actual owner doesn’t have to do anything. – Frontpage

Yes, I did save it, the thing I want to ask is how exactly do I update it? I'm not that experienced in dealing with broken WSDLs and have no clue where to start :( – Raddatz

To be clear, I did add the jxb namespace and the jxb:version to the root element (wsdl:definitions), but then when I do the wsimport / mvn goal I get a message saying that jaxb version is required – Raddatz

@OgnjenMišić I have just added xmlns:jxb="http://java.sun.com/xml/ns/jaxb" jxb:version="2.1" to the root element as in the answer and it resolved my issue. That was the only thing I did. – Frontpage

What is your root element? <wsdl:definitions> or something else? – Raddatz

No the root element of the XML/WSDL file itself. The outmost element. – Frontpage

In my case, my outermost element is <wsdl:definitions>. What should I wrap it with so i can have the jxb bindings? Could you show me your two or three top elements please? – Raddatz

I have updated .xjb file. It's root element is as follows: <jaxb:bindings version="2.1" xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"> – Frontpage

Let us continue this discussion in chat. – Raddatz

Answer 1

TL;DR Your WSDL is not correct/suitable for XJC. You'll need strup JAXB customizations or add xmlns:jxb="http://java.sun.com/xml/ns/jaxb" jxb:version="2.1" to the root element.

The problem is that your WSDL contains a lot of JAXB customizations in the included schema. This is a bad idea. JAXB customization are vendor-specific stuff, whoever put those in a WSDL (which is supposed to be vendor-neutral spec) did not do the right thing.

Now the thing is that XJC, the JAXB schema compile expects certain bells and whistles when you have inline JAXB customizations. Like jaxb:version attribute on the root element. Which is, in this case, missing. It is present on the schema element but not on the root wsdl:definitions element. If you add it, compilation succeeds.

This has nothing to do with JAXB plugins whatsoever. If you try xjc -wsdl delivery.wsdl, you'll get the same error.

There might be some magic option to suppress this problem, but it's hard to figure out. So I'd suggest to patch the WSDL. Create a patch and apply it to the WSDL in a pre-code-generation step. I personally would strip all JAXB customizations from the WSDL as they have forgotten literally nothing there.

Longcloth