JlinkPlugin: find a workaround for the jdeps command line length limit

[nigredo-tori]

Expected behaviour

JlinkPlugin properly handles large classpaths.

Actual behaviour

[error] (distrib-win64 / jlinkModules) java.io.IOException: Cannot run program "C:\dev\jvm\jdk-11.0.3-x64\bin\jdeps": CreateProcess error=206, Имя  файла или его расширение имеет слишком большую длину

("The filename or extension is too long")

Information

• sbt-native-packager 1.4.0
• sbt 1.3.2
• Windows 10

As a short-time workaround, directly setting jlinkModules works, assuming you can get the module list elsewhere (e.g. by building on Linux).

This issue is mostly for documentation, and as a reminder - I expect to get to fixing this soon-ish.

[nigredo-tori]

This is trickier than I expected... Classpath jars can't be jdeps analysis roots (they have no classes, so they can't reference anything), and jdeps doesn't support the @argfile pattern. So I see two sane ways do deal with this:

1. Change jdeps usage to limit the number of analysis roots. For an average Scala app we can probably start with its main classes, and end up with all the required modules. However, this leaves out anything that makes use of reflection for class discovery (which, sadly, includes one of the projects I have to support). So in case we go this route, we should leave an escape hatch - e.g. a setting to add custom analysis roots.
2. We can make a tiny launcher library that will augment jdeps (and, possibly, arbitrary main classes/ToolProviders) with support for @argfiles. This way we can keep the behavior intact, and this will give us a workaround for similar issues in the future. The catch here is that, since this project targets Java 8, we can't build such a library as a part of this project without a massive CI overhaul - so I'm gonna have to set up a separate project for that, and publish it to Sonatype.

The second solution sounds more annoying for me personally, but it's more robust in the long run. I'll try to get on that tomorrow.