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 ?

[mrpiggi]

Providing the MRE would be impossible, and not just for security.

You weren't asked to share your project but rather a Minimal Reproducible Example, otherwise, as @laurentschoelens already said, it is not possible to help in any way.

There are many dependent components.

And you are the only one who would be able to reduce the problem to its core.

[davidmichaelkarr]

So can someone help me through getting my local environment set up so that I can debug this myself? I've been writing and debugging Java code for many years, but I've never worked on a Maven plugin.

[laurentschoelens]

What I could say for sure is that removing the xjc plugins should fix the issue.

Here we have a resolved artefact (by transitivity) that has a null file returned.

One thing that could be done is logging the error and ignore it but... I'd like to reproduce the error first in order to understand why you face this issue first.

The main branch can be build safely with jdk11 as minimal jdk version.

[davidmichaelkarr]

By "removing the xjc plugins", do you mean not using "jaxb-plugins" or "jaxb2-basics", or simply just removing the "plugins" block in the "configuration" section of the plugin? If so, I just tried that, and it had no effect.

Is your statement about "The main branch can be ..." addressing my question about setting up a local environment so I can debug it myself? If so, I would need more than that. I would need to be able to step through the code in Eclipse, while running the generation as specified in my build.

[laurentschoelens]

When I need to debug some configuration, I add it to the tests projectd and then run debug but I do it in IntelliJ, not tested in Eclipse.

Since you are using eclipse, could you send me your last tests output of mvn with -X -e flags and the effective pom view, with sensitive information removed (but marked when removed).

Thanks

[davidmichaelkarr]

stuff.zip

I just learned about the "mvnDebug" app, and inspecting it, I see how easy it is to set up mvn so I can debug this, so I might do this on Monday. I assumed it would be more complicated than this.

[laurentschoelens]

By "removing the xjc plugins", do you mean not using "jaxb-plugins" or "jaxb2-basics", or simply just removing the "plugins" block in the "configuration" section of the plugin? If so, I just tried that, and it had no effect.

Is your statement about "The main branch can be ..." addressing my question about setting up a local environment so I can debug it myself? If so, I would need more than that. I would need to be able to step through the code in Eclipse, while running the generation as specified in my build.

I've re-read your answer and looked at the effective pom, and could you please try again with removing of the following lines in the plugin configuration :

          <args>
            <arg>-Xsetters</arg>
            <arg>-Xsetters-mode=direct</arg>
          </args>
          <plugins />

Thanks

[davidmichaelkarr]

I assume you mean just the "args" block, and not the ending "plugins" marker. I tried that. No change.

[laurentschoelens]

I assume you mean just the "args" block, and not the ending "plugins" marker. I tried that. No change.

No I meant both blocks

[davidmichaelkarr]

Interesting. That got a result. When I had an empty plugins block:

        <configuration>
          <extension>true</extension>
<!--
          <args>
            <arg>-Xsetters</arg>
            <arg>-Xsetters-mode=direct</arg>
          </args>
-->
          <plugins>
<!--
            <plugin>
              <groupId>org.jvnet.jaxb2_commons</groupId>
              <artifactId>jaxb2-basics</artifactId>
              <version>0.11.1</version>
            </plugin>
            <plugin>
			  <groupId>org.jvnet.jaxb</groupId>
              <artifactId>jaxb-plugins</artifactId>
              <version>4.0.8</version>
            </plugin>
-->
          </plugins>
        </configuration>

it still gets the error.

When I commented out the plugins block entirely, it completes the generation and goes onto compiling the code:

        <configuration>
          <extension>true</extension>
<!--
          <args>
            <arg>-Xsetters</arg>
            <arg>-Xsetters-mode=direct</arg>
          </args>
-->
<!--
          <plugins>
            <plugin>
              <groupId>org.jvnet.jaxb2_commons</groupId>
              <artifactId>jaxb2-basics</artifactId>
              <version>0.11.1</version>
            </plugin>
            <plugin>
			  <groupId>org.jvnet.jaxb</groupId>
              <artifactId>jaxb-plugins</artifactId>
              <version>4.0.8</version>
            </plugin>
          </plugins>
-->
        </configuration>

I have no idea whether those plugins are really required. I see many of our developers include those blocks, but I've never bothered to analyze the result and difference.

[laurentschoelens]

I was pretty sure that'd help your case by removing plugins section (and corresponding args) in the maven-plugin configuration because the NPE is related with some resolved artefact related to the project itself with null file in it, but that code is only used when some xjcPlugins are declared.

I've tried to copy on a test project almost everything I could from your effective pom section but I didn't get it to fail as you did.
My guess is that one of your "proprietary" dependency is making the all thing to crash due to the system explained above.

One good advice I could give is try to split this code generation in a simple module, with plugins activated but with no extra and useless dependencies.

You can find the setters plugin documentation here

If you manage to debug your current config, please let me know what failed. We could for sure add extra failsafe to remove null files in the processing but that's a first in the issues I've already looked at.

[davidmichaelkarr]

I would not be at all surprised if one of those "proprietary" dependencies, which we have little control over in our "platform" team has some WTF in it that none of us expected. I hope hitting the breakpoint at that line that throws the exception will lead to that discovery. I have that in my tasks for tomorrow. I'll relate everything that I find.

[davidmichaelkarr]

Ok, I cloned jaxb-tools, checking out master, and started running some tests with the debugger. I noticed that some of the methods weren't "lining up", so I instead checked out the 4.0.8 tag, and that worked a little better.

It will be a little hard for me to tell when what I'm seeing is a true anomaly. I'll describe what I do and see.

I changed the pom.xml to restore everything we had in the configuration block before.

I first looked at what I get at "org.jvnet.jaxb.maven.RawXJCMojo.resolveXJCPluginArtifacts (RawXJCMojo.java:400)", which is this:

	protected void resolveXJCPluginArtifacts()
			throws ArtifactResolutionException, ArtifactNotFoundException, InvalidDependencyVersionException {

		this.xjcPluginArtifacts = ArtifactUtils.resolveTransitively(getArtifactFactory(), getRepositorySystem(),
				getMavenSession().getLocalRepository(), getArtifactMetadataSource(), getPlugins(), getProject());
		this.xjcPluginFiles = ArtifactUtils.getFiles(this.xjcPluginArtifacts);
		this.xjcPluginURLs = CollectionUtils.apply(this.xjcPluginFiles, IOUtils.GET_URL); // line 400
	}

I first note that the "plugins" list has two entries, with artifactIds "jaxb2-basics" and "jaxb-plugins". The xjcPluginFiles list is length 434, and every entry is null. The xjcPluginArtifacts list is also 434 entries, likely with no null entries. The 0th entry has artifactId "jaxb2-basics". However, the "file" property is null. The actual type of all of the entries of this list is DefaultArtifact. I see there are three subclasses of Artifact, but I also see that there are three subclasses of DefaultArtifact. All of these actual types are just DefaultArtifact, not any of the subclasses of DefaultArtifact, like PluginArtifact or ProjectArtifact.

I would step into "ArtifactUtils.getFiles()", but I think it's pointless with what I see here, as that just gets the "file" property from each one of these.

It's reasonable to consider setting a breakpoint on DefaultArtifact.setFile() , but of course that gets hit hundreds of times. So, I made it a conditional breakpoint for this.artifactId.equals("jaxb2-basics"). That did get hit, and the value was definitely null. I backed up the stacktrace for a while, but I couldn't tell what direction I should take from there.

[laurentschoelens]

Many thanks for the detailed explanation.

I first note that the "plugins" list has two entries, with artifactIds "jaxb2-basics" and "jaxb-plugins".

I'm a bit surprised about the two entries in "plugins" : you should only have the jaxb-plugins in it.

Could you send me more details about the jaxb2-basics artifactId ? (groupId, version, ...)

Thanks

[davidmichaelkarr]

[0] Dependency (id=1761) Dependency
artifactId "jaxb2-basics" (id=1764) String
artifactIdLocation null null
classifier null null
classifierLocation null null
exclusions null null
exclusionsLocation null null
groupId "org.jvnet.jaxb2_commons" (id=1765) String
groupIdLocation null null
location null null
locations null null
managementKey "org.jvnet.jaxb2_commons:jaxb2-basics:jar" (id=1766) String
optional null null
optionalLocation null null
scope "runtime" (id=1767) String
scopeLocation null null
systemPath null null
systemPathLocation null null
type "jar" (id=1768) String
typeLocation null null
version "0.11.1" (id=1769) String
versionLocation null null

[laurentschoelens]

Do you have any org.jvnet.jaxb2_commons:jaxb2-basics defined somewhere in your project ?

[davidmichaelkarr]

The only place it is referenced is in that plugins block in the configuration for the jaxb-maven-plugin. Frankly, every time I've ever built something using jaxb-maven-plugin, I never used these plugins. I see this being done in numerous poms maintained by other developers here. I assumed they had a good reason to do it, but I've never examined them.

[laurentschoelens]

OK but you said earlier that

I first note that the "plugins" list has two entries, with artifactIds "jaxb2-basics" and "jaxb-plugins".

So at some point, you should have both plugins in jaxb-maven-plugin defined. Maybe cleaning the extra-ref to the jaxb2-basics plugin will help fix the issue...

The setters plugin documentation is here : https://github.com/highsource/jaxb-tools/wiki/JAXB2-Setters-Plugin
It adds to the generated classes the setters for collections type.
It might be useful in some situation.

[davidmichaelkarr]

OK but you said earlier that

I first note that the "plugins" list has two entries, with artifactIds "jaxb2-basics" and "jaxb-plugins".

So at some point, you should have both plugins in jaxb-maven-plugin defined. Maybe cleaning the extra-ref to the jaxb2-basics plugin will help fix the issue...

I'm not certain what you're suggesting. Are you saying that the jaxb2-basics plugin is pointless and could be removed? Note that these configurations have been like this for a long time. We recently did a big upgrade from Java 11, SpringBoot 2, and Spring 5 to Java 17, SpringBoot 3, and Spring 6. This plugin was also upgraded. In fact, I believe we were even using a different plugin, one with a similar name.

The setters plugin documentation is here : https://github.com/highsource/jaxb-tools/wiki/JAXB2-Setters-Plugin It adds to the generated classes the setters for collections type. It might be useful in some situation.

[laurentschoelens]

In order to move to SB3, you needed to go with the latest version (main branch, 4.x version) of jaxb-maven-plugin, and more generaly jaxb-tools.

Starting with v2 (based on javaee8, jaxb2.3) of the maven-plugin, we did some reorganisation about others highsource's repositories and merged them here in order to have a complete set of tools, with same groupId (org.jvnet.jaxb), at the same github repository and simplify maintenance and migration in jakarta's world, first with v3 (jakartaee9, jaxb3) and then with v4 (jakartaee10, jaxb4).

Users of legacies artifacts (0.x, 1.x) moving to the new ones (any versions) or users moving from javax to jakarta (below 2.x to 3.x and upper) are really encouraged to read the migration guide pointed above.

Back to your issue : I didnt manage to add the old artifact jaxb2-basics:0.11.1 in my test project without adding back jaxb-api / jaxb-runtime 2.x as project's / plugin's dependency.
If you have both artifacts (this one and the new jaxb-plugins one with 4.x version), you can safely remove the first from any location.

Maybe your issue occurs because of some transformer process (like javax to jakarta eclipse transformer thing) ?

[davidmichaelkarr]

Remember, we were still getting this error when I had an empty plugins block. It was only removing the entire plugins block that made the error go away. Actually, I'm going to test that again, and this time in the debugger.

We are using the transformer, but that doesn't happen until compile stage.

[davidmichaelkarr]

I ran another test with this as the configuration block:

     <configuration>
          <extension>true</extension>
          <args>
            <arg>-Xsetters</arg>
            <arg>-Xsetters-mode=direct</arg>
          </args>
          <plugins>
          </plugins>
        </configuration>

In "org.jvnet.jaxb.maven.RawXJCMojo.resolveXJCPluginArtifacts()", the plugins list is a zero-length list. The "xjcPluginFiles" list is length 426 (434 before), but still has all null entries. The plugins issue seems to be a red herring.

In the xjcPluginArtifacts list, all of the "file" properties are null, so something is happening in "ArtifactUtils.resolveTransitively()" that causes this.

Oh, but our plugins list is empty. Why do we have a list of xjcPluginFiles with 426 entries (all null) if we're not using any plugins?

[laurentschoelens]

That is somehow strange that all files are null entries.
I'll dig into that tomorrow, thanks for your feedback

[davidmichaelkarr]

I tried stepping into more code, which gets into maven-core and maven-compat. It appears these 426 artifacts somehow correspond to all of the dependencies in the pom. It's a little hard to tell what it is doing, but that's the impression I got. I have no idea whether it makes sense for those to be considered the "xjcArtifacts".

[laurentschoelens]

Could you tell me which version of mvn you're using please ?

[laurentschoelens]

Since you managed to run debug mode, could you see if the artifactresolver enter in this condition :

https://github.com/apache/maven/blob/master/compat%2Fmaven-compat%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fmaven%2Fartifact%2Fresolver%2FDefaultArtifactResolver.java#L483

[davidmichaelkarr]

We're using Maven 3.9.6.

The line number for that block of code is slightly different in 3.9.6 (line 489). When I hit that check, metadataResolutionExceptions and CircularDependencyExceptions were both null, but versionRangeViolations had 35 entries.

The first one of 35 was this:

org.apache.maven.artifact.versioning.OverConstrainedVersionException: The artifact has no valid ranges
  com.att.idp:idp-spring-boot-autoconfigure:jar:3.6.2

Path to dependency: 
	1) com.att.idp:UnifiedAccountMs:jar:0.0.1-SNAPSHOT
	2) com.att.idp:idp-services-commons:jar:1.4
	3) com.att.idp:rest-api-client:jar:2.8.0

I don't know what this means.

[laurentschoelens]

From what I understand in your stacktrace, you got exception in version range selection in some of your dependencies like this one com.att.idp:idp-spring-boot-autoconfigure:jar which is actually resolved to 3.6.2 by maven process.

In your project, I can see this

      <dependency>
        <groupId>com.att.idp</groupId>  <!-- com.att.idp:idp-bom:2.9.0, line 56 -->
        <artifactId>idp-spring-boot-autoconfigure</artifactId>  <!-- com.att.idp:idp-bom:2.9.0, line 57 -->
        <version>[3.7.0, 3.7.100)</version>  <!-- com.att.idp:idp-bom:2.9.0, line 58 -->
      </dependency>

So you're expecting to have 3.7.x version in your project, but either in com.att.idp:idp-services-commons:jar:1.4 or in com.att.idp:rest-api-client:jar:2.8.0 you're getting the same artefact with 3.6.x version. This leads to an error in maven dependency resolution management and fails the resolution process of dependencies behind.

The file property in artefacts is set after the if-line I pointed yesterday, so if you got trapped in this, all the files will be null. You must fix this first in order to solve the problem I guess.

[davidmichaelkarr]

This is a familiar problem to us. My "platform" team maintains the BOM and some common libraries like rest-api-client and idp-spring-boot-autoconfigure, and the parent pom. We tell developers that they cannot override versions of the artifacts we provide, but it happens all the time in artifacts like that "idp-services-common" thing, which we do not maintain.

However, these mistakes usually manifest in more obvious symptoms, like MethodNotFound, ClassDefNotFound, et cetera. It's really odd for that to produce a symptom like this. I wonder if there's some way we can get these "metadataResolutionExceptions" to be more visible? Is this something I should take to the Maven list?

[laurentschoelens]

Could you first confirm that fixing this will solve your problem ?

I'll check if we get this information in the xjcPlugin resolution process in order to fail with a-non-odd exception (like here : NPE)

[laurentschoelens]

I'll check if we get this information in the xjcPlugin resolution process in order to fail with a-non-odd exception (like here : NPE)

In fact yes, it's available, so we could enforce there's no error in order to carry on the generation process.

[laurentschoelens]

@davidmichaelkarr : could you provide me the pom.xml declaration of com.att.idp:idp-spring-boot-autoconfigure:jar in the corresponding dependencies :
1) com.att.idp:UnifiedAccountMs:jar:0.0.1-SNAPSHOT
2) com.att.idp:idp-services-commons:jar:1.4
3) com.att.idp:rest-api-client:jar:2.8.0

I'm still trying to reproduce the issue

Thanks :)

[davidmichaelkarr]

Ok, well, some of those are just the "top-level" pom that leads to that dependency spec. I'll map out the path along the way. Note that several of these blocks actually reference variables for the version strings. I'm hardcoding those values to avoid that additional level of indirection here.

In "com.att.idp:UnifiedAccountMs:jar:0.0.1-SNAPSHOT", the top-level pom.xml for the service I'm debugging, it just has this:

    <dependency>
      <groupId>com.att.idp</groupId>
      <artifactId>idp-spring-boot-autoconfigure</artifactId>
    </dependency>

It has no version because we wire versions in the parent poms.

This pom also has this parent declaration:

  <parent>
    <groupId>com.att.idp</groupId>
    <artifactId>sdk-java-parent</artifactId>
    <version>2.9.0</version>
  </parent>

The "sdk-java-parent:2.9.0" artifact then references our BOM in dependencyManagement:

			<dependency>
				<groupId>com.att.idp</groupId>
				<artifactId>idp-bom</artifactId>
				<version>2.9.0</version>
				<scope>import</scope>
				<type>pom</type>
			</dependency>

Then in "idp-bom:2.9.0" we have this in dependencyManagement:

			<dependency>
				<groupId>com.att.idp</groupId>
				<artifactId>idp-spring-boot-autoconfigure</artifactId>
				<version>[3.7.0, 3.7.100)</version>
			</dependency>

In "com.att.idp:idp-services-commons:jar:1.4, it doesn't have an explicit reference to that dependency, but it has this:

  <parent>
    <groupId>com.att.idp</groupId>
    <artifactId>sdk-java-library-parent</artifactId>
    <version>2.8.0</version>
  </parent>

In "sdk-java-library-parent:2.8.0" it has this BOM dependency:

			<dependency>
				<groupId>com.att.idp</groupId>
				<artifactId>idp-bom</artifactId>
				<version>2.8.0</version>
				<scope>import</scope>
				<type>pom</type>
			</dependency>

And "idp-bom:2.8.0" has this:

			<dependency>
				<groupId>com.att.idp</groupId>
				<artifactId>idp-spring-boot-autoconfigure</artifactId>
				<version>[3.6.0, 3.6.100)</version>
			</dependency>

Now in "rest-api-client:2.8.0", it has an unversioned spec for it:

		<dependency>
			<groupId>com.att.idp</groupId>
			<artifactId>idp-spring-boot-autoconfigure</artifactId>
		</dependency>

Along with this:

	<parent>
		<groupId>com.att.idp</groupId>
		<artifactId>sdk-java-library-parent</artifactId>
		<version>2.8.0</version>
	</parent>

That is the identical subpath to the reference from idp-services-commons:1.4.

[cfoushee]

Found solution for a similar issue.

We have two gitlab pipelines. One is air-gabbed so we have to manually transfer files from one to the other. It would pass in the first and fail in the second.

I was getting the same error "[ERROR] Failed to execute goal org.jvnet.jaxb:jaxb-maven-plugin:4.0.8:generate (generate) on project topproject: Execution generate of goal org.jvnet.jaxb:jaxb-maven-plugin:4.0.8:generate failed: Cannot invoke "java.io.File.toURI()" because "file" is null "

I tried enabling verbose and debug but it didn't help me figure it out. If I removed the jaxb-plugins extension and not generate the equals/hashcode then it succeeded.

I added the jaxb-plugins as a explicit not just a and then it showed the other dependencies that were missing. Once I added that the file is null went away.