Native tests fail when using Shade plugin for Long Classpath Support

[mstine]

On Windows machines, the long classpath passed to native-image.cmd causes execution to fail as described here. Needing to support a large population of Windows users, we applied the solution described by the GraalVM team in their documentation.

After applying the changes described in the docs, executing:

$ ./mvnw -Pnative integration-test

Results in this failure:

[INFO] Executing: /Users/mstine/workspace/graal-test/target/native-tests --xml-output-dir /Users/mstine/workspace/graal-test/target/native-test-reports
JUnit Platform on Native Image - report
----------------------------------------


Failures (1):
  JUnit Jupiter:GraalTestApplicationTests
    ClassSource [className = 'com.mattstine.graaltest.GraalTestApplicationTests', filePosition = null]
    => java.lang.ExceptionInInitializerError
       org.springframework.test.context.TestContextManager.<init>(TestContextManager.java:122)
       org.junit.jupiter.engine.execution.ExtensionValuesStore.lambda$getOrComputeIfAbsent$4(ExtensionValuesStore.java:86)
       org.junit.jupiter.engine.execution.ExtensionValuesStore$MemoizingSupplier.computeValue(ExtensionValuesStore.java:223)
       org.junit.jupiter.engine.execution.ExtensionValuesStore$MemoizingSupplier.get(ExtensionValuesStore.java:211)
       org.junit.jupiter.engine.execution.ExtensionValuesStore$StoredValue.evaluate(ExtensionValuesStore.java:191)
       [...]
       Suppressed: java.lang.NoClassDefFoundError: Could not initialize class org.springframework.test.context.BootstrapUtils
         org.springframework.test.context.TestContextManager.<init>(TestContextManager.java:122)
         org.junit.jupiter.engine.execution.ExtensionValuesStore.lambda$getOrComputeIfAbsent$4(ExtensionValuesStore.java:86)
         org.junit.jupiter.engine.execution.ExtensionValuesStore$MemoizingSupplier.computeValue(ExtensionValuesStore.java:223)
         org.junit.jupiter.engine.execution.ExtensionValuesStore$MemoizingSupplier.get(ExtensionValuesStore.java:211)
         org.junit.jupiter.engine.execution.ExtensionValuesStore$StoredValue.evaluate(ExtensionValuesStore.java:191)
         [...]
     Caused by: java.lang.IllegalStateException: Failed to load class for @org.springframework.test.context.web.WebAppConfiguration
       org.springframework.test.context.BootstrapUtils.loadWebAppConfigurationClass(BootstrapUtils.java:203)
       org.springframework.test.context.BootstrapUtils.<clinit>(BootstrapUtils.java:62)
       [...]
     Caused by: java.lang.ClassNotFoundException: org.springframework.test.context.web.WebAppConfiguration
       java.lang.Class.forName(DynamicHub.java:1347)
       org.springframework.util.ClassUtils.forName(ClassUtils.java:284)
       org.springframework.test.context.BootstrapUtils.loadWebAppConfigurationClass(BootstrapUtils.java:199)
       [...]

Reproducer Repo

• main branch, tests passing
• shade-fail branch, tests failing

This project was generated from start.spring.io on 2022-02-03, with web and native options applied. The main branch is unchanged from generation. The shade-fail branch has an additional commit that follows the instructions listed in the GraalVM Native Maven plugin docs under Long classpath and shading support.

[snicoll]

That doesn't sound like this should be reported here. The logs that you have shared comes from the native build tools plugin.

Have I missed something?

[sdeleuze]

@mstine Could you please test if a non-Spring test passes and let me know?

[mstine]

@snicoll - Oracle advised me to file an issue here after they consulted with a Spring Developer Advocate (not sure who). So that's why I filed here. At any rate, this is how they are advising Maven users on Windows to run tests in native mode, so I expect this is affecting anyone in the Spring community that is trying to do the same.

[mstine]

@sdeleuze Do you mean a non-Spring test within the reproducer project? Or a non-Spring test in a non-Spring project?

[sdeleuze]

A non-Spring test within the reproducer project.

[mstine]

Added two additional tests to the shade-fail beach @sdeleuze:

• NonSpringNoExternalDependencyTest - instantiates DummyClass and compares return value with expected value.
• NonSpringApacheCommonsTextDependencyTest - uses CaseUtils from Apache Commons Text. I wanted to see if a non-Spring external dependency would work.

Both of these tests pass.

[sdeleuze]

@mstine Thanks, could you please try with the just released Native Build Tools Tools 0.9.10 which brings long classpath support without having to use the super verbose shade configuration (so please remove the additional shade plugin configuration not needed anymore) on Windows?

[mstine]

Hi @sdeleuze - I've upgraded to 0.9.10 and removed all of the shade configuration. We are back to the original error ("The command line is too long.").

I checked the source code for the plugin to make sure I wasn't missing a configuration. I can see exactly where @arg file support is being used to build the image (this is working!): https://github.com/graalvm/native-build-tools/blob/0.9.10/native-maven-plugin/src/main/java/org/graalvm/buildtools/maven/NativeBuildMojo.java#L139-L141.

However, I cannot find a corresponding change in the test mojo. It seems like the code building the image for testing is still using the classpath as a string: https://github.com/graalvm/native-build-tools/blob/0.9.10/native-maven-plugin/src/main/java/org/graalvm/buildtools/maven/NativeTestMojo.java#L141-L147.

Am I missing something?

Thanks,
Matt

[sdeleuze]

I have asked and will let you know. In the mean time, could you please check it passes with -DskipNativeTests flag?

[sdeleuze]

Confirmed on NBT side, so please track graalvm/native-build-tools#209 and #1499 for the resolution of the underlying issue.