Running plugin generated native-image.cmd fails if classpath is too long

[pexi]

What happened?

Running the nativeImage task generates native-image.cmd under build\tmp\com.palantir.graal.
It calls the actual native-image.cmd of Graal and adds the classpath as argument. If the classpath is long (total cmd argument can be 8191 chars) the command fails as only the max amount chars will be run as cmd.

What did you want to happen?

nativeImage task should succeed even if there are lot of jar's in the classpath

[Kynolin]

For reference: Command prompt (Cmd. exe) command-line string limitation (it doesn't list Windows 10, but it was still a problem)

I just ran into this as well. As a workaround, I was able to take build/tmp/native-image.cmd and point it directly to native-image.exe instead of the second native-image.cmd in the user cache directory. Running the updated script from PowerShell was successful.

Not ideal, but I was just trying to see if what I was compiling on Linux would also work on Windows. Short answer: Yes, with a lot of painful dependencies and workarounds.

[bhavikp19]

I have also hit this issue on windows. I was curious as to how the other tools are getting around this problem and found out that https://graalvm.github.io/native-build-tools/latest/gradle-plugin.html plugin supported by GraalVM team is using an uber jar strategy for native-image versions < 0.9.10 and argfile strategy for native-image versions > 0.9.10. Relevant documentation can be found here : https://graalvm.github.io/native-build-tools/latest/gradle-plugin.html#long_classpath_and_fat_jar_support

Can we look at implementing something with the same concepts? In my view ability to download and extract the GraalVM tooling is the usp of our plugin and it makes it very easy for the users to generate native images. Hence I am looking to fix this in our plugin. Happy to submit a PR if we decide the approach on this one. @fawind @carterkozak what do you guys think?