Why would we get 'Cannot invoke "java.io.File.toURI()" because "file" is null' from Maven plugin?

[davidmichaelkarr]

We've been using "jaxb-maven-plugin" for a long time to generate JAXB classes from wsdls and xsds. There are occasional unusual issues we have to deal with, but we've always gotten it to work. We maintain a large number of SpringBoot services, many of which use this to generate JAXB classes from many different schemas.

Today I started looking at one build that is failing with an odd error:

14:26:52 [ERROR] Failed to execute goal org.jvnet.jaxb:jaxb-maven-plugin:4.0.8:generate (ivsad) on project UnifiedAccountMs: Execution ivsad of goal org.jvnet.jaxb:jaxb-maven-plugin:4.0.8:generate failed: Cannot invoke "java.io.File.toURI()" because "file" is null -> [Help 1]

This pom.xml has several "execution" blocks, but I've tried commenting all but one, and other variations, but all of those experiments fail with the same error (with a different execution name).

I've verified that the "sourceDirectory" refers to an existing directory that has a wsdl in it, with several xsd files. Each execution block looks something like this:

  <execution>
	<id>unifiedServices</id>
	<goals>
	  <goal>generate</goal>
	</goals>
	<configuration>
	  <specVersion>2.2</specVersion>
	  <schemaDirectory>${project.basedir}/src/main/resources/schemas/csi_UnifiedServices_240.0_schema</schemaDirectory>
	  <schemaIncludes>
		<include>*.wsdl</include>
	  </schemaIncludes>
	  <generateDirectory>${project.build.directory}/generated-sources/xjc/unifiedServices/</generateDirectory>
	  <forceRegenerate>false</forceRegenerate>
	</configuration>
  </execution>

What are possible causes of this?

[laurentschoelens]

Hi @davidmichaelkarr

I think one cause could be the specVersion which is defined to 2.2.
You should try 3.0 to have jakarta based generated sources (or remove the specVersion tag).

You could also safely remove <forceRegenerate>false</forceRegenerate> as forceRegenerate defaults to false

Regards
Laurent

[laurentschoelens]

See issue #443 for change regarding specVersion in this plugin

[davidmichaelkarr]

Changing the specVersion to 3.0 made no difference. Same error.

[laurentschoelens]

Could you then send the output with mvn -X -e flags ?

[davidmichaelkarr]

mvn.zip

Looking at this output, it might confirm a thought I was having. The source directory has a wsdl, and a bunch of xsd files, which I assume are referenced directly or indirectly from the wsdl. If the developer had left one or more required schema files out of this, would it produce that error? I have no idea whether this is what happened, I'm just looking at hypotheses.

[laurentschoelens]

The NPE is quite specific in some location.

I've seen this output in your mvn run :

08:04:21 [DEBUG] While downloading org.apache.commons:commons-io:1.3.2
  This artifact has been relocated to commons-io:commons-io:1.3.2.
  https://issues.sonatype.org/browse/MVNCENTRAL-244

Could you please try to fix this relocation to see if this fixes your issue ?

[davidmichaelkarr]

That is not an error. That has been like that for a long time. It is still downloading the relocated artifact. And none of our poms are even referencing that old path, so I don't know where that is coming from. The effective pom doesn't show that.

[laurentschoelens]

Sorry but without MRE, it's try-and-error guessing.

Analysis pointed out the usage of org.jvnet.jaxb2_commons:jaxb2-basics:0.11.1

08:04:19 [DEBUG]   (s) groupId = org.jvnet.jaxb2_commons
08:04:19 [DEBUG]   (s) artifactId = jaxb2-basics
08:04:19 [DEBUG]   (s) version = 0.11.1

You should use latest version of jaxb-plugins regarding migration guide

<groupId>org.jvnet.jaxb</groupId>
<artifactId>jaxb-plugins</artifactId>
<version>4.0.8</version> <!-- same version as jaxb-maven-plugin -->

If using jaxb2-basics-runtime, there is also a new "relocated" artifact :

<groupId>org.jvnet.jaxb</groupId>
<artifactId>jaxb-plugins-runtime</artifactId>
<version>4.0.8</version> <!-- same version as jaxb-maven-plugin -->

[davidmichaelkarr]

I'm not certain exactly what changes are implied, but I just tried the following:

      <plugin>
        <groupId>org.jvnet.jaxb</groupId>
        <artifactId>jaxb-maven-plugin</artifactId>
		<version>4.0.8</version>
        <executions>
          <execution>
            <id>ivsad</id>
            <goals>
              <goal>generate</goal>
            </goals>
            <configuration>
              <specVersion>3.0</specVersion>
              <schemaDirectory>${project.basedir}/src/main/resources/schemas/csi_UnifiedDataAccessServices_224.0_schema</schemaDirectory>
              <schemaIncludes>
                <include>*.wsdl</include>
              </schemaIncludes>
              <generateDirectory>${project.build.directory}/generated-sources/xjc/ivsad/</generateDirectory>
              <forceRegenerate>false</forceRegenerate>
            </configuration>
          </execution>
        </executions>
        <configuration>
          <extension>true</extension>
          <args>
            <arg>-Xsetters</arg>
            <arg>-Xsetters-mode=direct</arg>
          </args>
          <plugins>
            <plugin>
			  <groupId>org.jvnet.jaxb</groupId>
              <artifactId>jaxb-plugins</artifactId>
              <version>4.0.8</version>
            </plugin>
          </plugins>
        </configuration>
      </plugin>

It had no effect. Same error.

[davidmichaelkarr]

On the hypothesis that the developer somehow left off one or more schema files, I tried searching for ":include" in all the existing wsdl and xsd files in that directory and verifying each one, and each referenced file does exist in that directory.

[laurentschoelens]

Could you please share MRE so that I can debug it ? Thanks

[laurentschoelens]

And also could you share the last working configuration you had ? Thanks

[davidmichaelkarr]

Providing the MRE would be impossible, and not just for security. There are many dependent components.

[laurentschoelens]

Providing the MRE would be impossible, and not just for security. There are many dependent components.

Could you then share the latest working config you had please ?